JAVAEE - Используемая память кучи просто продолжает расти, пока все не сломается

Question

Я управляю веб-приложением среднего размера под tomcat. Я обнаружил, что приложение продолжает сбой после определенного количества времени выполнения (пару дней) из-за проблемы с памятью, я уже увеличил размер кучи, но это не проблема, поскольку я где-то сталкиваюсь с утечкой памяти.

Я искал способы отладить это безрезультатно. Я использую инструмент под названием YouKit Java, чтобы помочь мне в этом, и я понял, что используемая память кучи продолжает расти неопределенно, пока она не сломается. Коллекция мусора, похоже, не работает в любой момент.

heap memory usage afer 16h Я запустить приложение отладки для всей ночи и даже с минимальными для не использовать это происходит: используется куча растет от нескольких мегабайт до XXX МБ (> 1 Гб в прод) без нагрузки на нем все , После принудительного сбора мусора, использование памяти возвращается к норме.

On the left the sudden decrease after I force GC. On the right, the memory couple of minutes after GC

Следующая картинка показывает используемую память растет снова после моего вынужденного GC с основным использованием приложения: перезагрузки страницы, некоторые получают запросы, которые возвращают данные из БДА (SQLite) и некоторые почтовый запрос, написать в db и откройте некоторые сокеты. Обратите внимание, что для всего, что я тестировал, я также запускаю противоположную команду, которая должна отменить мои изменения. но память просто продолжает расти.

Я сделал снимок памяти, чтобы просмотреть, что такое instanciated. Крупнейшие Доминаторы показывают объектно огромные древовидный объект java.lang.ref.Finalizer, зная, что я всегда не вызывать любой метод Finalize (не то, что я знаю, по крайней мере)

Так что я очень потерял в этом, Java это не моя самая большая сила, и у меня много трудностей, отлаживая это. Мне интересно, есть ли что-то, что может помешать работе GC и вызвать это? (Как я вижу, после принудительного выполнения GC вещи возвращаются в более нормальное состояние). Может ли это быть вызвано самим TOMCAT или джерси?

Боковые заметки о приложении: это API, который позволяет создавать туннель tcp в фоновом режиме (серверные и клиентские сокеты). Каждый туннель порождается в потоке. Кроме того, некоторые данные извлекаются и записываются в sqlite db. Я старался быть уверенным, что все закрыто должным образом (соединения db, запросы, сокеты и неопровержимость ...), когда работа выполнена. Для туннелей, я опираясь на слегка отредактированный вариант библиотеки под названием javatunnel (это может быть также BEW виновника, но не смог найти что-нибудь доказать это)

Answer 1

Возможно, розетка неправильно закрыта, чтобы сборщик мусора не мог освободить их и связанные объекты? Я думаю, вы должны попытаться исследовать глубже таким образом.

Вы можете активировать журналы сборщиков мусора, чтобы определить, когда они работают. Вы должны добавить флаги -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps при запуске JVM.

Answer 2

я понял, что используется куча памяти продолжает расти indefinitly до это ломается. Коллекция мусора, похоже, не работает в любой момент.

В этом случае вы должны ознакомиться с параметрами GC в аргументах запуска JVM. Каково отношение вашего максимального старого размера и максимального размера. Если максимальный старый размер слишком высок по сравнению с максимальным новым размером, ваши объекты будут продолжать переходить от оставшегося в прежнее поколение и не будут собирать мусор до тех пор, пока размер старого поколения не достигнет порога, который, по моему мнению, превышает 75%.

Итак, проверьте настройки GC. Это может помочь.