Поиск утечки памяти Java, когда не вся используемая куча достижима из потоков

Я изучаю потенциальную утечку памяти (или, по крайней мере, отходы памяти) в довольно большой системе на основе Java. JVM работает с максимальным размером кучи 5 ГБ, а использование кучи на 2-3 ГБ является ожидаемой базовой линией для приложения. (Там могут быть пики, которые выше)

В сценарии перегрузки, который я изучаю, куча заполняется. Анализ кучи-дампа с помощью инструмента "Eclipse MemoryAnalyzer" показывает (неудивительно), что куча полностью израсходована.

MAT показывает 2 потенциальных кандидата на утечку, которые примерно сохраняют 2,5 ГБ: java.lang.Thread и объект домена из системы, который широко используется при обработке транзакций в системе. Однако все эти объекты домена (не удивительно) доступны из экземпляров Thread. В конце концов, эти потоки обрабатывают транзакции. Таким образом, 2,5 ГБ приписывается java.lang.Thread почти полностью вызван этими объектами домена. Здесь нет ничего удивительного.

Листинг дерева объектов для всех экземпляров java.lang.Thread и суммирования сохраненной кучи всех потоков приводит к 2,5 ГБ сохраненной кучи.

Где я должен искать другие 2,5 ГБ, которые необходимы для заполнения кучи, если они недоступны из экземпляра java.lang.Thread? - В очереди финализатора ничего нет - В ожидании GC

отсутствует значительное количество недостижимых объектов.

Я думаю, что еще один способ поставить этот вопрос: "Как найти все объекты, недоступные из экземпляра java.lang.Thread? Возможно, запрос OQL?" и другой вопрос: "Какие объекты есть ли недоступные из экземпляра java.lang.Thread, а затем объекты в очереди Finalizer и объекты без ссылок в ожидании GC?"

Ответ 1

Я тоже столкнулся с проблемой утечки памяти на нашем сайте,
Используйте yourkit java profiler, которые предоставляют много информации и с его возможностями вы можете иметь более широкое изображение, где используется вся память.
Вы можете найти отличный учебник Найти утечку памяти Java с помощью вышеуказанного инструмента.

Ваш вопрос,

"Какие объекты существуют, которые недоступны из экземпляра java.lang.Thread, а затем объекты в очереди Finalizer и объекты без ссылок в ожидании GC?"

Существует четыре типа объектов,

Сильные достижимые объекты, которые могут быть достигнуты непосредственно через ссылки из живых объектов
Слабые/Мягкие достижимые объекты, которые имеют слабую/мягкую ссылку, связанную с ними
Ожидание завершения, объекты, ожидающие завершения, и ссылка на которые может быть достигнута через очередь финализатора
Недостижимыми являются объекты, недоступные из корней GC, но еще не собранные

Кроме того, JVM также использует Native memory, информацию о которой вы можете найти в IBM Использование кучи и собственной памяти JVM и Спасибо за память и в соответствии с вашимKit Структура памяти JVM имеет память без кучи чье определение по ним

Кроме того, JVM имеет память, отличную от кучи, называемую памятью без кучи. Он создается при запуске JVM и хранит структуры каждого класса, такие как постоянный пул времени выполнения, данные полей и методов, а также код для методов и конструкторов, а также интернированные строки.

Ответ 2

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

FindBugs

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

Дамп вручную

Вы можете попытаться использовать что-то вроде jmap или visualvm, чтобы вручную взять дамп кучи для анализа и посмотреть, не получится ли от него другое затмение:

http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jmap.html

http://java.dzone.com/articles/java-heap-dump-are-you-task

Анализатор Quirks

Часто задаваемые вопросы анализатора памяти:

http://wiki.eclipse.org/MemoryAnalyzer/FAQ

говорит:

Признак: при мониторинге использования памяти в интерактивном режиме используемый размер кучи намного больше, чем сообщает MAT.

Во время создания индекса анализатор памяти удаляет недоступные объекты, потому что различные алгоритмы сбора мусора, как правило, оставляют некоторый мусор (если объект слишком мал, перемещение и переназначение адресов является дорогостоящим). Это, однако, должно составлять не более 3 - 4 процентов. Если вы хотите узнать, какие объекты удалены, включите вывод отладки, как описано здесь: MemoryAnalyzer/FAQ # Enable_Debug_Output

Другая причина может заключаться в том, что свалка кучи не была написана правильно. Особенно старые VM (1.4, 1.5) могут иметь проблемы, если дамп кучи написан через jmap.

Включение вывода отладки позволит вам увидеть, что там происходит, и подтвердить, что в этой области нет ничего странного.

Некоторые из этих советов могут быть релевантными

http://eclipsesource.com/blogs/2013/01/21/10-tips-for-using-the-eclipse-memory-analyzer/

Ответ 3

Использовать JProfiler и разбить объект кучи на число вниз по классу - найти, в каком классе есть много экземпляров, и начать свою охоту там.

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

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

FYI: У меня нет связи с JProfiler.

Ответ 4

Возможно, вам стоит искать утечки памяти в коде соединителя базы данных или, возможно, ORM. Потому что, если вы используете библиотеку необработанных подключений, когда вы не закрываете курсор, вы можете получить потенциальную утечку памяти. Также моя вторая мысль также связана с соединителем базы данных. Поскольку некоторые из них (возможно, не ваши) используют собственный код внизу, и это источник этой утечки. Из-за большого одновременного использования, которое делает меня чувствительным. Вы можете проверить это, если хотите.

Ответ 5

Since the extra memory is not showing in MAT it hard to know what to suggest. Это неправда. MAT показывают недостижимые объекты. Просто перейдите в раздел "Настройки" и установите флажок "Включить эти параметры". После перезапуска MAT вы увидите эти объекты с деталями. Конечно, корни в GC будут недоступны.