java - pattern - property logback xml

¿Alguna razón para usar la estática final privada en lugar de la privada en el LogBack Logger?

Question

Al crear una instancia de Logger en un controlador Spring, ¿hay alguna razón para declararlo como una final estática ? El registrador no se utiliza fuera de MyController.class. He visto ambos ejemplos en uso, pero no veo por qué debería usar uno u otro.

private Logger logger = LoggerFactory.getLogger(MyController.class);

vs

private static final Logger logger = LoggerFactory.getLogger(MyController.class);

Answer 1

Personalmente, yo uso

private final Logger logger = LoggerFactory.getLogger(this.getClass());

La principal ventaja de esto es que puedo cortar y pegar esto en nuevas clases sin tener que cambiar el nombre de la clase.

En cuanto a si deben o no ser estáticos, consulte ¿Se deben declarar los miembros del registrador de una clase como estáticos? , desde el sitio web slf4j, que dice:

Solíamos recomendar que los miembros de los registradores se declararan como variables de instancia en lugar de estáticas. Después de un análisis adicional, ya no recomendamos un enfoque sobre el otro.

Tomado de esa página:

Ventajas para declarar los loggers como estáticos

1. idioma común y bien establecido
2. menos sobrecarga de CPU: los registradores se recuperan y asignan solo una vez, en la inicialización de la clase de alojamiento
3. menos sobrecarga de memoria: la declaración del registrador consumirá una referencia por clase

Desventajas de declarar los loggers como estáticos

1. Para bibliotecas compartidas entre aplicaciones, no es posible aprovechar los selectores de repositorio. Se debe tener en cuenta que si el enlace SLF4J y la API subyacente se envían con cada aplicación (no compartida entre aplicaciones), entonces cada aplicación tendrá su propio entorno de registro.
2. no es amigable con el COI

Ventajas para declarar loggers como variables de instancia

1. Posibilidad de aprovechar los selectores de repositorio incluso para bibliotecas compartidas entre aplicaciones. Sin embargo, los selectores de repositorio solo funcionan si el sistema de registro subyacente es logback-classic. Los selectores de repositorio no funcionan para la combinación SLF4J + log4j.
2. Amigable con el COI

Desventajas para declarar loggers como variables de instancia

1. Idioma menos común que declarar loggers como variables estáticas
2. mayor sobrecarga de la CPU: los registradores se recuperan y asignan para cada instancia de la clase de alojamiento
3. mayor sobrecarga de memoria: la declaración del registrador consumirá una referencia por instancia de la clase de alojamiento

Explicación

Los miembros del registrador estático cuestan una única referencia de variable para todas las instancias de la clase, mientras que un miembro del registrador de la instancia costará una referencia variable para cada instancia de la clase. Para las clases simples creadas miles de veces, puede haber una diferencia notable.

Sin embargo, los sistemas de registro más recientes, por ejemplo, log4j o logback, admiten un contexto de registrador distinto para cada aplicación que se ejecuta en el servidor de aplicaciones. Por lo tanto, incluso si se implementa una única copia de log4j.jar o logback-classic.jar en el servidor, el sistema de registro podrá diferenciar entre aplicaciones y ofrecer un entorno de registro distinto para cada aplicación.

Más específicamente, cada vez que se recupera un registrador invocando el método LoggerFactory.getLogger (), el sistema de registro subyacente devolverá una instancia apropiada para la aplicación actual. Tenga en cuenta que dentro de la misma aplicación, recuperar un registrador con un nombre dado siempre devolverá el mismo registrador. Para un nombre dado, se devolverá un registrador diferente solo para diferentes aplicaciones.

Si el registrador es estático, solo se recuperará una vez cuando la clase de alojamiento se cargue en la memoria. Si la clase de hosting se usa solo en una aplicación, no hay mucho de qué preocuparse. Sin embargo, si la clase de alojamiento se comparte entre varias aplicaciones, todas las instancias de la clase compartida iniciarán sesión en el contexto de la aplicación en la que primero se cargó la clase compartida en la memoria, difícilmente el comportamiento esperado por el usuario.

Para más información, vea esa página.

Answer 2

Sí; así que solo hay un registrador para la clase, en lugar de uno por instancia.

De cualquier manera es privado, por lo que usarlo fuera de la clase no tiene nada que ver con eso, no es lo que hace static final .

Answer 3

Solo se inicializará el campo private para cada instancia de su clase. Sin embargo, private static campo private static se inicializará una vez por clase.

En el caso de que el registrador sea más probable (depende de la implementación del registro), en ambos casos obtendrá la misma instancia de registrador y no utilizará una cantidad de memoria notablemente mayor. Pero aún se LoggerFactory.getLogger a LoggerFactory.getLogger con cada objeto que cree.

Answer 4

Solo tengo curiosidad por esta línea:

private Logger logger = LoggerFactory.getLogger(MyController.class);

Lo es:

LoggerFactory.getLogger(MyController.class) 

o:

LoggerFactory.getLogger(MyController.class.getName());

Porque el primero devolverá "clase" antes del nombre real:

class com.example.MyController (instead of com.example.MyController)