Возможная утечка памяти?

Question

У меня запущено Java-приложение, которое я отслеживаю с помощью visualVM .

Вот график кучи:

Был протестирован с двумя наборами запросов, один в 3:20 и другой в 4:40 примерно (они представлены на графике только двумя пиками).

Мой вопрос: означает ли это, что у меня утечка памяти? Я беспокоюсь о средней части, где, хотя GC работает, куча остается в 250 МБ все время.

Большое спасибо за ваши идеи.

Answer 1

Первый запрос в 3:20 вызвал задержку некоторой памяти, но обратите внимание, что GC после второго запроса вернули большую часть. Также я думаю, что основной сбор был выполнен только после второго запроса в 4:40.

Похоже, утечки нет. Моя теория состоит в том, что запрос в 3:20 заставил молодое поколение заполниться, и в результате незначительный сборщик мусора продвинул некоторые объекты старшему поколению. Следующий крупный сборщик мусора, вызванный запросом в 4:40, очистил большинство из них.

Вы можете проверить это, используя профилировщик, чтобы пометить кучу, прежде чем выполнить тот же запрос, что и в 3:20, принудительно выполнить полный сборщик мусора и затем проверить, какие объекты задерживаются. Я не уверен, позволяет ли VisualVM (1) пометить кучу и (2) принудительно заполнить полный сборщик мусора, но OptimizeIt использовал это для этого.

Answer 2

Что вы подразумеваете под утечкой памяти здесь? Я не думаю, что у любой хорошей реализации JVM, такой как SUN, была бы такая сумасшедшая ошибка. Слово утечки памяти идеально используется, когда у вас нет ссылки на ячейку памяти (зомби) или у вас нет возможности восстановить ее. Если у вас неправильная практика программирования, когда вы держите ссылку на объекты, которые больше не используются, и они имеют больший объем (срок службы), тогда вы израсходуете больше памяти, не давая ГХ возможность повторно собрать ее.

Answer 3

JvisualVM позволяет форсировать сборку мусора.

Попробуйте использовать это, чтобы увидеть, что происходит.

Answer 4

Какой JRE вы используете? Какие параметры кучи / GC передаются приложению?

Пик неплохой (если для сервера было больше задач, имеет смысл увеличить его). Но что выглядит не так хорошо, что уровень после 4:40 (когда нагрузка снова низкая) выше, чем уровень до того, как нагрузка поднялась. Но это не должно быть ...

Теперь вы должны рассмотреть более подробно, какие объекты или графы объектов хранятся в куче. Так что сделайте тот же тест снова, включая (с профилировщиком):

• сделать снимок кучи до того, как нагрузка увеличится
• сделать снимок кучи после того, как нагрузка снизится (обязательно запустите ручной триггер GC)

Теперь вы должны проанализировать различия и увидеть ли вы странные объекты, которые должны были быть одеты.

Answer 5

Вы говорите, что до 3:20 не было запросов? Если так, то я бы сказал, что не вижу никаких признаков утечки.

Я не знаю вашего приложения, но это типично (на основе архитектуры / дизайна), когда некоторые объекты, которые находятся вокруг JVM, инициализируются при первом использовании приложения.