Возможная утечка памяти?
У меня есть рабочее веб-приложение Java, которое я контролирую с visualVM.
Вот график "кучи":
Протестировал с двумя наборами запросов, один в 3:20 и другой в 4:40 приблизительный (они представлены в графике как только два пика).
Мой вопрос: это означает, что у меня есть утечка памяти? Я волнуюсь по поводу средней части, где, хотя GC работает, "куча" остается в 250 МБ все время.
Большое спасибо за Ваше понимание.
5 ответов
Первый запрос в 3:20 вызвал проведение некоторой памяти, но обратите внимание, что GCS после второго запроса утомил большую часть этого. Также я думаю, что основной GC был выполнен только после второго запроса в 4:40.
Похоже, нет утечки. Моя теория состоит в том, что запрос в 3:20 вызвал заполнение молодого поколения, и в результате незначительный ГК продвигал некоторые объекты старшему поколению. Следующий крупный GC, вызванный запросом в 4:40, убрал большинство из них.
Вы можете проверить это, используя профилировщик, чтобы пометить кучу перед выпуском того же просьбы, что и один в 3:20, принуждение полного GC, а затем проверяя, какие объекты задерживаются. Я не уверен, что VisualVM позволяет вам (1) пометить кучу и (2) принудить полный GC, но оптимизировать использование для этого.
]JvisualVM позволяет принудительно собирать мусор.[
] []Попробуйте использовать это, чтобы посмотреть, что произойдет.[
]Вы говорите, что до 3:20 не было никаких запросов? Если да, то я бы сказал, что не вижу никаких признаков утечки.
Я не знаю ваше приложение, но это типично (на основе архитектуры/дизайна) для некоторых объектов, которые зависают в течение жизни JVM, чтобы инициализироваться при первом использовании приложения.
Что вы имеете в виду под утечкой памяти? Я не думаю, что любая хорошая реализация JVM, как SUN, будет иметь такую сумасшедшую ошибку. Слово "утечка памяти" идеально используется, когда у вас нет ссылки на ячейку памяти (зомби) или у вас нет возможности ее восстановить. Если у вас неправильная практика программирования, при которой вы держите ссылку на объекты, которые больше не используются, и они имеют больший объем памяти (срок службы), то вы съедаете больше памяти, не давая ГХ возможности ее пересобрать.
Какую JRE вы используете? Какие параметры, относящиеся к куче / сборке мусора, передаются приложению?
Пик неплохой (если для сервера было больше задач, имеет смысл увеличить пик). Но что выглядит не очень хорошо, так это то, что уровень после 4:40 (когда нагрузка снова низкая) выше, чем уровень до повышения нагрузки. Но это не обязательно ...
Теперь вы должны более подробно изучить, какие объекты или графы объектов хранятся в куче. Так что сделайте тот же тестовый прогон еще раз, включая (с профилировщиком):
- сделайте снимок кучи перед увеличением нагрузки
- сделайте снимок кучи после того, как нагрузка снизится (обязательно выполните запуск сборщика мусора вручную)
Теперь вам следует проанализировать различия и увидеть, видите ли вы странные объекты, которые должны были быть испорчены.