¿Es class.getName() caro?

Question

En muchas clases de un proyecto que estoy trabajando, veo los miembros privados estáticas finales nombrados CLASS_NAME, que se definen como esto:

public class MyClass { 
    private static final String CLASS_NAME = MyClass.class.getName(); 
    //... 
} 

Cuáles son los beneficios, en su caso, de hacer esto para conseguir la clase nombre, en lugar de hacer la llamada MyClass.class.getName() directamente donde se necesita el nombre?

Answer 1

Aquí es la implementación de Class.getName()

public String getName() { 
if (name == null) 
    name = getName0(); 
return name; 
} 

Como se puede ver el valor del nombre se almacena en caché, por lo que la llamada no es demasiado caro. Es solo como una llamada de getter regular. De todos modos, si lo llamas muy a menudo, es probable que sea un buen estilo para definir constante.

Answer 2

No, no es caro en absoluto. Los únicos beneficios que se me ocurren es que un IDE puede mostrarle rápidamente dónde se está utilizando esta constante en particular, y que para los nombres de clase largos, la constante sería más corta, haciendo que el código sea un poco más limpio.

Answer 3

Tendríamos que ver todo el código para ver cómo se está usando CLASS_NAME. Sin embargo, es probable utiliza en otros lugares, por ejemplo, se podría utilizar con Log4J así:

// Log4j . Logger --- Get class name in static context by creating an anonymous Throwable and 
// getting the top of its stack-trace. 
// NOTE you must use: getClassName() because getClass() just returns StackTraceElement.class 
static final Logger logger = Logger.getLogger(new Throwable() .getStackTrace()[0].getClassName()); 

No es una operación costosa y es probable que almacena en caché.

Answer 4

Almacenar el nombre de la clase llevará la sobrecarga de otra referencia. Eso cambia el costo de los códigos de operación JVM (complejidad de la CPU) para la huella de memoria.

En la actualidad, las CPU son tan rápidas que básicamente esperan memoria, por lo que si tuviera que elegir entre los códigos de operación y la memoria, es mejor optar por ejecutar más códigos de operación a través de la JVM.

Al principio esto no parece intuitivo; pero, considere la JVM y el hardware circundante. Las huellas de memoria más grandes significan menos elementos accedidos recientemente en la memoria caché, y el costo de recuperar un elemento que se cae de la memoria caché es entre 1.000 y 10.000 veces el costo de ejecutar un solo código de operación JVM. Si unimos esto con el motor de jit de la JVM, la complejidad de la CPU para fragmentos de código con gran acceso se optimiza de forma gratuita (además de todo lo demás).

Por lo tanto, en general, recortaría su objeto al no almacenar en caché la referencia, ya que permitiría que más de ellos se introduzcan en la memoria caché de nivel 1. Sin embargo, como todos los ajustes del rendimiento en el mundo real, debe probar para ver si los resultados coinciden con la hipótesis, y hacer sus pruebas de tal manera que no se confunda con el resto del funcionamiento interno de la JVM.

Answer 5

No es caro. Parece ser una convención para fines de registro.

comparar

logger.entering(CLASS_NAME, ...) 

a

logger.entering(MyClass.class.getName() ,...) 

además de eso, la tala código no se rompería (registrando la clase equivocada) cuando se copia a otra fuente.