Обнаружение утечки памяти По JProfiler

Question

Мой вопрос отличается от этого Я выполнил профилирование своего приложения, оно слишком медленное.После завершения одного процесса я видел некоторые живые объекты в программе просмотра кучи.

Хотя мы кэшируем некоторые данные из базы данных в HashMap, но программа просмотра кучи показывает мне некоторые живые объекты, такие как Resultset.getString и * 1007.* которого там не должно быть.

HashMap.put() занимает меньше памяти, чем при использовании двух методов.

Я все сделал правильно, и этот анализ прав?ИЛИ Я что-то упускаю, и память занята самой HashMap, а HeapWalker просто показывает мне методы JDBC (getString и executeQuery).

Answer 1

Поскольку вы говорите о методах, я полагаю, что вы смотрите на представление "Распределения" для обходчика кучи.Это представление показывает, где объекты были созданы , а не где объекты ссылаются .Есть скриншот, который объясняет запись выделения в JProfiler .

HashMap.put не будет выделять много памяти, он просто создает небольшие объекты «Entry», которые используются для хранения ключей.пары значений.Объекты, которые занимают много памяти, создаются перед тем, как поместить их в хэш-карту.

Resultset.getString и Statement.getString создают объекты String, которые вы читаете из своей базы данных.Поэтому разумно предположить, что некоторые из этих объектов являются более долгоживущими.

Чтобы выяснить , почему объекты все еще находятся в куче, вы должны перейти в справочный вид, выбрать входящие ссылки иискать "путь к корню GC".Представление «самые большие объекты» также очень полезно для отслеживания чрезмерного использования памяти.

Answer 2

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

Это может быть из-за того, что соединение не закрывается, оператор или результирующий набор, или это может быть связано с пулом соединений. Если вы посмотрите на профиль памяти, вы сможете увидеть «путь к корню GC» (путь к корню объекта), и это будет указывать на то, что содержит ваши ResultSet строки. Вы должны увидеть, находится ли он в вашем коде, кешируется внутри чего-то, что вы сохраняете, или в пуле.

N.B. Я не использовал JProfiler, но так я бы отслеживал его с помощью YourKit .