Как проверить утечку памяти?

Question

Можно ли проверить утечку памяти, не заходя в код. У меня есть приложение, и я хочу проверить, есть ли утечка памяти или нет.

В моей нынешней организации я проверяю использование процессора до и после запуска приложения, а также использование процессора процессом приложения. Но я не думаю, что это правильный метод.

Пожалуйста, сообщите мне об этом.

Answer 1

Если вы запускаете ваше Java-приложение со следующим флагом:

-Dcom.sun.management.jmxremote

Вы сможете подключиться к нему с помощью jconsole. jconsole - это инструмент, который поставляется с Java и находится в каталоге bin, где находится программа java. Вы можете запустить его и наблюдать за использованием памяти с течением времени (это не очень хорошо, но может помочь в выявлении утечек). В самых последних версиях Java (поздние сборки 1.6) вы также можете запустить jvisualvm, что похоже на jconsole, но также сообщит вам, сколько экземпляров каждого класса создано, что более полезно.

Answer 2

Я думаю, вам нужен профилировщик памяти для этого.

Вы можете найти список профилировщиков здесь

Профилировщики с открытым исходным кодом для Java

также читайте эту статью на

Поиск утечек памяти в приложениях Java

Answer 3

Анализ потребления памяти приложением Java не должен выполняться с использованием инструментов ОС, ИМХО. Работающая JVM выделит объем памяти и вряд ли освободит его, даже если JVM на самом деле не нужен в данный момент времени. Инструмент ОС сообщит только объем памяти, выделенный JVM, а не объем памяти, фактически выделенный в JVM.

Инструменты, поставляемые с JDK (jstat, jconsole, jvisualvm), гораздо более надежны. При интерпретации использования памяти самым важным является размер фактической кучи. Java-приложение обычно отображает пилообразный шаблон. Количество используемой кучи будет постепенно увеличиваться со временем и резко уменьшаться, когда GC освобождает пространство кучи, удаляя все ненужные объекты.

Определенным предупреждающим сигналом является медленно поднимающийся пилообразный сигнал: резкое падение, вызванное ГХ, каждый раз заканчивается немного выше. Если приложение выполняется в течение длительного времени (обычно для серверного приложения), это, скорее всего, приведет к ошибке OutOfMemory в долгосрочной перспективе.

Еще одна вещь, которую нужно искать, это пилообразная пила, в которой «зубы» становятся острее и выше. Это также указывает на то, что приложению со временем потребуется все больше и больше памяти.

Если вы хотите проанализировать основную причину обнаруженной проблемы, вам нужно проанализировать количество созданных объектов и посмотреть, как долго они живут. Это не тривиальные вещи.

Answer 4

Вы правы в том, что наблюдать только за памятью не так-то просто с Java, так как он использует сборщик мусора и будет иметь своего рода схему распиливания. Тем не менее, может быть полезна запись потребления памяти всего приложения в течение длительного времени.

Если у вас есть какое-то автоматическое средство для «удаленного управления» приложением (например, SendKeys под окнами), вы могли бы сделать хорошие диаграммы потребления времени. Используйте вашу любимую программу расчета таблиц, чтобы нарисовать линейную интерполяцию данных. Если это показывает регулярный восходящий тренд, вы могли бы сказать, что произошла утечка. Делайте это только в состоянии, когда приложение не должно расти в памяти, что также может быть сделано со здоровым человеческим мышлением о том, какую информацию приложение должно хранить для отображения / обработки данных.

Конечно, другие инструменты необходимы для детализации до потоков или классов (см. Другие ответы).

Answer 5

если его код Unix c, тогда используйте valgrind