Факты собраны:
log4j 2.6 обеспечивает ведение журнала без мусора, где вместо создания новых строк каждый раз он использует построитель строк, сохраненный в локальном потоке.
Режим log4j без мусора по умолчанию отключен в webApps, поскольку webApps повторно использует потоки, а сохранение журналов в потоках может привести к созданию stringBuilder в течение нескольких дней.
Я использую log4j в веб-приложении и проверил, что поле ENABLE_THREADLOCALS имеет значение false.
Когда я регистрируюсь следующими способами:
log.info("log statement with parameter {}", someString);log.info(""log statement with concatenation " + someString");
Понятно, что первый оператор остается в памяти кучи даже после полного GC.Где, поскольку второе утверждение не выполняется.
Я просмотрел код для log.info и обнаружил, что первый использует «ParameterizedMessage», а второй - «SimpleMessage».
ParametrizedMessage создание выполняется с использованием ThreadLocal s, даже для WebApp, и имеет комментарий:
"// storing JDK classes in ThreadLocals does not cause memory leaks in web apps, so this is okay"
Мой вопрос, является ли приведенный выше комментарий верным, потому что я сталкиваюсьпроблемы утечки памяти при входе в систему с помощью {} в веб-приложении.
PS: при перезапуске веб-приложения проблем не возникает.Все очищается при перезагрузке.Но это проблема, когда webApp работает непрерывно в течение нескольких дней, а размер ThreadLocals продолжает увеличиваться.