java - que - Declaración de variable final y estática.
static final java (2)
Este comentario se realizó en una revisión del código y la persona que lo hizo ya no está en nuestro equipo.
Cualquier tipo que deba ser resuelto por el cargador de clases en tiempo de ejecución nunca debe tener instancias que sean retenidas por referencias declaradas como finales y estáticas.
Aquí está la línea de código:
private final static Logger log = LoggerFactory.getLogger(MyClass.class);
Estoy familiarizado con el debate sobre la declaración de registradores estáticos o no estáticos, pero este comentario parece ser más general. No puedo encontrar ninguna explicación de por qué estática y final son malas. ¿Alguien puede elaborar?
La línea de código está perfectamente bien, y no hay ningún problema real porque la variable es final y static .
Tal vez la persona que hizo ese comentario estaba confundida por lo siguiente.
En Java, cuando crea una variable public final static de tipo int (por ejemplo; también funciona con algunos otros tipos), entonces el compilador podría, en lugares donde use esa variable, sustituir el valor constante real en lugar de una referencia a La variable. Por ejemplo, supongamos que tiene lo siguiente:
class A {
public final static int VALUE = 3;
}
public class B {
public static void main(String[] args) {
System.out.println(A.VALUE);
}
}
Cuando compile y ejecute esto, obviamente se imprimirá 3.
Ahora suponga que cambia la clase A y establece VALUE = 4 . Usted esperaría que si recompilara la clase A y luego ejecutara la clase B (sin recompilar la clase B ), vería 4 . Pero lo que pasa es que todavía verás 3 . Esto se debe a que A.VALUE en la clase B se reemplazó por el valor constante real 3 cuando compiló la clase B
Esta es una optimización que el compilador de Java hace para las constantes.
Como puede ver, esto puede causar problemas, si tiene tales constantes en la API pública de sus clases. Los usuarios de su código tendrán que volver a compilar su código si cambia el valor de tales constantes.
Pero en el código que publicó en su pregunta, esto no es un problema, porque la variable es private .
Más detalles:
Lo más probable es que el comentario esté relacionado con un problema de Classloader Leaking ( aquí hay un buen artículo ).
En pocas palabras, este problema ocurre en entornos donde es necesario volver a cargar el cargador de clases. Si carga una clase dinámicamente a través de un cargador de clases y luego intenta volver a cargar el cargador de clases, mantener los campos finales estáticos con los objetos de las clases creadas a través de este cargador de clases evitará la descarga del propio cargador de clases. Una vez que esto sucede, obtienes un OutOfMemoryError .
El artículo vinculado anteriormente enumera las bibliotecas de registro entre los principales culpables que podrían producir este comportamiento, junto con las medidas que puede tomar para solucionar las fugas (como liberar cargadores de clases explícitamente).