¿Cuál es el sentido de tener aquí la instrucción if? El nivel de gravedad se puede cambiar en el archivo de configuración log4j.xml. Si el nivel de gravedad es la depuración, se registrará el mensaje de depuración, de lo contrario no lo hará.verificación de depuración habilitada check in java
¿Cuál es el significado de la instrucción if a continuación?
if (log.isDebugEnabled())
{
log.debug("I am logging something");
}
En su ejemplo no hay necesidad de una sentencia 'if' (entre 'si' no es un bucle)
Pero si se toma el ejemplo de abajo a continuación, se puede ver que hacemos una concatenación y si el el nivel de registro es información, entonces innecesariamente se realizará esta operación de concatenación. Para un mejor rendimiento comprobamos esta condición.
if (log.isDebugEnabled())
{
log.debug("I am logging " + 1234 + ".");
}
Información adicional:
Uso slf4j para evitar tales si las condiciones. La instrucción anterior se puede reescribir en slf4j como sigue,
log.debug("I am logging {} .", 1234);
Esto se considera una buena práctica. Por ejemplo, si hay alguna concatenación de cadenas, no se evalúa y se comprueba en log4j, pero se verifica primero.
Ejemplo:
if (log.isDebugEnabled()) {
log.debug("N=" + N + ", a=" + Arrays.toString(a));
}
método Arrays.toString() y también concatenación no se realiza si depuración no está habilitado. Si no hay if se invoca primero y se verifica más tarde, eso es todo ;-)
Mi opinión es que cuando hay una cadena simple como en su ejemplo, si no es necesario el registro, si hay algo más complicado (incluso más complicado que en mi ejemplo) esto puede ahorrar algo de tiempo de CPU en modo de producción (sin modo de depuración habilitado).
Tiene que darse cuenta también que cuando en el caso de concatenación hay String.valuOf() llamada que (para objetos no nulos) llama toString() método, que puede ser realmente un problema de rendimiento para los objetos de datos grandes (frijoles con muchas propiedades) si se considera que no invoca ninguna lógica comercial (por lo tanto, es "inútil").
Sin concatenación implica menos objetos creados, implica menos basura para recolectar. En lo profundo de los bucles internos, etc., los ahorros pueden ser bastante significativos. – djna
No entiendo bien tu primera sesión. En mi ejemplo, incluso si la depuración está desactivada, se crean los objetos '" N = "', '", a = "' (como constantes en tiempo de compilación), por lo que no se guarda la memoria. Tal vez puedas describir más ;-) – Betlista
Generalmente las personas no solo registran algunas cadenas constantes, sino que registran "X =" + x + ", y =" + y etc. mostrando valores. En muchos casos, puede llamar a String() en algún objeto, que a su vez puede concatenar valores. Es mejor utilizar una expresión segura en todos los casos ... – djna
Es una optimización del rendimiento. Se hace para evitar evaluar los argumentos a log.debug. Solo vale la pena hacerlo si la construcción del mensaje de registro es particularmente costosa (por ejemplo, la serialización de un documento XML).
Esto está cubierto en detalle en el Short introduction to log4j.
El artículo de referencia dice "Este costo de construcción de parámetros puede ser bastante alto y depende del tamaño de los parámetros involucrados."El artículo no dice que la prueba solo vale la pena si el costo de construcción es" particularmente caro ", esa es su interpretación o experiencia. En mi opinión, es mejor acostumbrarse a hacer la prueba. – djna
No, creo que es Es innecesario a menos que la construcción de los parámetros sea demostrablemente costosa. A menos que esté registrando, por ejemplo, dentro de un circuito cerrado (que probablemente no sería, ya que generaría una gran cantidad de ruido de registro), concatenando un par de cadenas ganadas 'notoriamente afecta el rendimiento. – harto
en cualquier caso específico, acepto que es probable que sea excesivo. Para mí los problemas son: a). Los programadores tienden a adoptar hábitos y usarlos sin considerar cada caso b). Cambios de código: utilizados para ser que "X =" + X era barato, entonces alguien cambió X's toString(), ahora no lo es. Es demasiado difícil realizar repetidamente el análisis de rendimiento. No es tan costoso en términos de esfuerzo o tamaño de programa agregar los tes t. – djna
+1 para SLF4J. No muchos estresan una característica tan genial. – adarshr
por otro lado, podemos analizar qué tiene un mejor rendimiento: un 'if' (+1 captador) o varias llamadas a métodos para determinar si la depuración está habilitada o deshabilitada ... – Betlista