В прошлой статье мы рассмотрели утечки памяти, которые возникают при остановках и переустановках веб-приложений, написанных на Java. Речь шла о выводе логов Spring через log4j2. Я показывал, каким образом нужно настроить веб-приложение так, чтобы контекст логгера уничтожался в последнюю очередь, после контекста Spring.

К сожалению «весенний» фреймворк не единственная технология, с которой могут возникнуть подобные проблемы. Сейчас я покажу, как можно легко и просто получить утечки памяти, используя log4j2 в веб-службах и на этот раз конец истории будет не таким радужным.

Если ты в курсе о чём речь и тебе знакома эта тема, то устраивайся поудобнее и читай дальше. Если же нет, то советую сначала прочитать первую статью: она введёт тебя в курс дела. Далее я буду исходить из того, что ты так и поступил.

Если ты когда-нибудь разрабатывал веб-приложения на Java, то сталкивался с проблемой утечек памяти при остановках и переустановках своих программ. Если же об этой проблеме ты слышишь впервые, то могу заверить тебя: с очень большой вероятностью твои творения текут. Причин этому может быть огромное множество, и одной из них я хотел бы поделиться с тобой в этой статье.

Даже если ты никогда не пользовался ни Spring, ни log4j2, то всё равно получишь довольно чёткое представление о том, почему такого рода утечки могут возникать и как с ними бороться.

Хотя эта статья и создана для разработчиков, в ней почти отсутствует программный код: всё, что нас будет интересовать – это конфигурационные файлы. Мы будем наблюдать, как простое подключение новой библиотеки в нашу программу будет приводить к утечкам памяти, а небольшие правки в конфигурации – исправлять их. Впрочем, давай всё по порядку.