¿Cuál es la sobrecarga de crear un registrador SLF4J en contextos estáticos y no estáticos?

Question

Siempre he usado el siguiente patrón para construir (SLF4J) madereros:

private static final Logger log = LoggerFactory.getLogger(MyClass.class); 

Esto ha funcionado hasta ahora, pero me preguntaba sobre el contexto static en algún momento y la necesidad de pasar de la clase concreta literal todo el tiempo en lugar de usar un registrador no estático como

private final Logger log = LoggerFactory.getLogger(getClass()); 

Esto se ha preguntado básicamente (y respondió) antes aquí para LOG4J

Should logger be private static or not

y aquí

Should be logger always final and static?

realizo final es básicamente obligatorio, así que me quedo preguntando qué tan alto la sobrecarga de uso de SLF4J en contexto no es estática realidad.

Q:

¿Hay alguna significativa práctica sobrecarga de uso de

private final Logger log = LoggerFactory.getLogger(getClass()); 

sobre

private static final Logger log = LoggerFactory.getLogger(MyClass.class); 

en la aplicación promedio (web)? (Sin necesidad de "discutir" de gama alta, de carga pesada webapps aquí)

---

Nota, en última instancia, estoy planeando utilizar un enfoque aún más agradable el uso de CDI para obtener un registrador SLF4J como

@Inject private final Logger log; 

como se describe aquí http://www.seamframework.org/Weld/PortableExtensionsPackage#H-TtLoggerttInjection, pero primero necesito saber sobre el almacenamiento en caché del registrador.

Sub pregunta: ¿Es incluso posible utilizar ?:

@Inject private static final Logger log; 

(empezando con CDI para ser honesto)

Answer 1

La sobrecarga para las variables de registrador no estáticas (instancia) debe ser insignificante a menos que ocurran muchas, digamos 10000 o más instancias. La palabra clave aquí es insignificante. Si se crean instancias de muchos objetos (> 10000), es probable que el impacto sea mensurable pero aún bajo.

Más específicamente, un registrador de instancias aumenta la huella de memoria en una referencia (64 bits) por instancia de objeto. En el lado de la CPU, el costo es una búsqueda de hash por instancia, es decir, el costo de buscar el registrador apropiado en una tabla hash (pequeña). De nuevo, ambos costos deberían ser insignificantes a menos que se creen muchos objetos.

Esta pregunta también se trata en el SLF4J FAQ.

Answer 2

No estoy seguro acerca de la sobrecarga exacta cuando se utiliza LoggerFactory pero lo dudo afectará el rendimiento de su aplicación. Así que simplemente use estático o no estático como mejor le parezca.

Cuál debería ser el beneficio de usar @Inject. LoggerFactory ya proporciona y abstracción de la impl concreta. En cualquier caso, será mucho más lento que LoggerFactory.

La sintaxis es más concisa cuando se usa @Inject que es verdadero. Pero imagine que usa la clase en una prueba. Luego debe configurar la inyección para iniciar sesión. Con el LoggerFactory normal también funciona bien en las pruebas. Si Java tuviera un mecanismo genérico para @Inject, funcionaría muy bien, pero como es la configuración es más difícil.