Как анализировать данные кучи.hprof-файл и использовать его для уменьшения утечек памяти?

в последнее время я столкнулся java.lang.OutOfMemoryError исключение при запуске приложения.

во время одного такого экземпляра я смог получить дамп кучи, используя jvisualvm.

Я могу открыть .hprof файл дампа кучи, полученный из дампа кучи с помощью NetBeans 8.1 IDE, но я не знаю как анализировать дамп данных. Я хотел бы знать, как читать файл дампа и предпринимать корректирующие действия, чтобы уменьшить исключение из памяти с точки зрения приложения.

изменить: Я прикрепил компонент отчет получено из кучи свалки

и вот подозреваемые утечки отчет

6
heap-dump java memory-leaks out-of-memory

3 ответов

существует много способов найти первопричину утечки памяти, например, с помощью профилировщика, такого как JProfiler и просто применять то, что описано в классное видео. Вы также можете посмотреть Анализатор Памяти Eclipse также известно как мат это сможет проанализировать ваш дамп кучи и предложить потенциальные причины утечки вашей памяти, как вы можете видеть в видео (вы можете найти больше информации о Подозреваемый Отчета здесь). Другим способом может быть использование Java Flight Recorder С применением этот подход. Или используя JVisualVM используя подход, описанный в видео.

10

инструмент, который вам нужен для этого случая это приложение:

Анализатор Памяти

просто скачайте и запустите, затем загрузите файл hprof. Это может занять минуту или две в зависимости от размера вашего hprof, но тогда вам будет представлен хороший анализ использования памяти. Он очень прост в использовании и автоматически высвечивает потенциальные утечки памяти, выполняет анализ данных под разными углами.

Я использую мат только когда Я имею дело с нестандартными проблемами памяти, и я решил все эти проблемы, насколько я помню.

1

В общем, в основном, что вы делаете, это анализ "что использует больше всего ОЗУ"? затем, когда вы это выяснили (и "это, вероятно, проблема того, что у меня заканчивается ОЗУ?") затем вы пытаетесь выяснить, почему вокруг так много этих объектов. На них ссылается что-то, что держится за объекты, но не нужно? Или то, что случайно держится за ссылки на thigns, это не должно? Вы используете слишком большую архикультуру / парадигму (например: хранение " все в одном большом array")? Является ли ваш клиент базы данных "буферизацией" больших наборов результатов в ОЗУ перед их возвратом? Так далее...

0