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

Question

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

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

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

Edit: Я приложил компонент report, полученный из кучи сваливать

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

Answer 1

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

Answer 2

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

Memory Analyzer Tool

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

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

Answer 3

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