java - over - Diferencia entre slf4j y log4j en base a la creación de String
slf4j-log4j12 (6)
En log4j si escribimos
**logger.debug("Processing trade with id: " + id + " symbol: " + symbol);**
creará una cadena en el grupo de cadenas pero cuando usamos slf4j usamos parámetros basados en esto
**logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);**
Entonces, ¿cuál es la diferencia entre estas dos afirmaciones, slf4j creará String en el tiempo de ejecución o no?
Entonces, ¿cuál es la diferencia entre estas dos afirmaciones, slf4j creará String a la hora del ron o no?
Las cadenas se crearán de todos modos independientemente de si usas log4j o sl4j. sl4j está ofreciendo una conveniencia de titular de lugar.
Con Log4j2 API, podemos tener logger.info ("String: {} int: {}.", "Hello, World", 10);
La diferencia es el aumento del rendimiento, en log4j la cadena se concatena cada vez que se evalúa la línea, incluso si el nivel de registro es más bajo que la depuración, por lo que la cadena nunca se usará.
slf4j, la cadena y los parámetros se pasan al registrador, que solo los sustituye si el mensaje de registro se va a utilizar realmente.
Imagine el código con sentencias de depuración cada pocas líneas, cuando la producción y la depuración están deshabilitadas, es una gran cantidad de manipulación de cadenas que nunca se utilizará.
SLF4J es básicamente una capa de abstracción. No es una implementación de registro. Significa que si está escribiendo una biblioteca y usa SLF4J, puede darle esa biblioteca a otra persona para que la use y ellos pueden elegir qué implementación de registro usar con SLF4J, por ejemplo, log4j o la API de registro de Java. Ayuda a evitar que los proyectos dependan de muchas API de registro solo porque usan bibliotecas que dependen de ellos.
Se trata de concatenación de cuerdas. La primera línea siempre hace que String concat que la operación costosa, la segunda línea no concat si el nivel de registro no coincide con la depuración. No estoy seguro de presumir que la segunda opción de nivel de registro coincidente puede ser un mejor rendimiento debido al uso interno de StringBuilder.
Yo diría que para aumentar el rendimiento mediante la reducción de las concatenations cadenas.
Cuando escribas esto
"Processing trade with id: " + id + " symbol: " + symbol
Estás creando la cadena de impresión manualmente.
Cuando escribes
"Processing trade with id: {} and symbol : {} ", id, symbol
-------^id------------^symbol---------
En la segunda forma, antes de imprimir internamente slf4j maintaind y generar una nueva cadena de nuevo con concatenación (No he comprobado el código fuente, puede ser un StringBuilder ).
El {} llamado como marcadores de posición y reemplazado por los argumentos pasados por usted.
Esta forma evita la concatenación de cadenas superfluas cuando el registrador está deshabilitado para el nivel DEBUG. Sin embargo, esta variante incurre en el costo oculto (y relativamente pequeño) de crear un Objeto [] antes de invocar el método, incluso si este registrador está deshabilitado para DEBUG. Las variantes que toman uno y dos argumentos existen únicamente para evitar este costo oculto.
Lea cómo usar el formato: ¿Cómo usar java.String.format en Scala?