Всем привет!

Я уже писал, как логирование может влиять на производительность: https://t.me/javaKotlinDevOps/15
Соберу в одном посте несколько важных опций, касающихся быстродействия log4j. Казалось бы логгер, что там может быть сложного, но...

1) Пару слов про то, почему лучше объявлять логгер статической переменной https://logging.apache.org/log4j/2.x/manual/usage.html

2) Две оптимизации касающиеся шаблонов сообщений: строка с параметрами в виде {} вычисляется лениво если включен нужный уровень логирования. Плюс поддержка передачи параметров в виде лямбд позволяет лениво вычислить значение параметра. https://logging.apache.org/log4j/2.x/manual/api.html
Итого конструкции вида if (logger.isTraceEnabled()) становятся не нужны.

3) логирование может быть синхронным и асинхронным. Последнее очевидно быстрее, но у него есть минусы: в случае ошибок сообщения могут терятся без уведомления прикладного кода, под асинхронное логирование нужен отдельный поток. Детали https://logging.apache.org/log4j/2.x/manual/async.html Там же есть сравнение по производительности, и оно впечатляет.

4) Начиная с версии 2.6 log4j переиспользует временные объекты и т.об. уменьшает нагрузку на сборщик мусора: https://logging.apache.org/log4j/2.x/manual/garbagefree.html
По ссылке говорится об ограничениях garbage free режима и есть графики производительности.

5) Логирование в memory-mapped файлы - по сути это область в памяти, за синхронизацию которой на диск отвечает ОС. https://logging.apache.org/log4j/2.x/manual/appenders.html#MemoryMappedFileAppender

Ну и сравнение производительности с logback и разных Appenders https://logging.apache.org/log4j/2.x/performance.html

P.S. Бросается в глаза, что авторы библиотеки начиная с версии 2 заморочились с производительностью. Куча графиков, статей

#logging #log4j