Как понять этот сеанс профиля памяти NetBeans в java (видимая утечка памяти)?

Я новичок в Java и мне интересно, как анализировать этот сеанс профиля памяти в NetBeans и как следить за ним, чтобы получить помощь в поиске утечки памяти?

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

Это приложение с большим количеством одновременных потоков и http-соединений. Я проверил потоки, и они работают нормально - я имею в виду, что одновременно не более 20 потоков. Я использовал JBOSS Netty для http-соединения и jSoup для разбора HTML.

профилировщик netbeans

Эта утечка памяти вызвана слишком большим количеством выделенных объектов ParseError? или я должен искать причину утечки памяти с трассировкой стека создания байтов?

Дополнительные ресурсы:

профилировщик netbeans

профилировщик netbeans

ИЗМЕНИТЬ:

Я добавил в свой проект HTML Cleaner. Это причина того, что я больше не вижу ошибок парсера. Рост утечек памяти теперь примерно в 3-4 раза медленнее. После достижения 800 МБ использования памяти приложение вышло из строя, и я мог наблюдать за кучей в NetBeans. Полученные результаты:

куча

Примечание. Я не создавал LinkedHashMap в своем приложении, поэтому он должен быть создан другой библиотекой. TagNode — это объект, который содержит очищенный html после очистки «HTML Cleaner». У меня есть только один объект TagNode в моем приложении, и это локальная переменная в обработчике ответа netty http (вызываемом messageReceived).


java netbeans memory-leaks memory-profiling profiler
person Piotr Müller    schedule 12.08.2011    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я всегда предпочитал инструмент Eclipse MAT встроенным средствам диагностики Netbeans. MAT также может работать с большими дампами кучи, чем Netbeans.

Самый простой способ — сделать так, чтобы jvm выдал дамп кучи на OOM, передал его в MAT и, основываясь на списке подозреваемых в утечке, отследил возможную причину утечки памяти.

-XX:+HeapDumpOnOutOfMemoryError

это опция JVM, которая вам понадобится. Другой подход заключается в создании нескольких дампов кучи через равные промежутки времени перед OOM приложений и сравнении их в MAT — у него есть средство для сравнения дампов. См. здесь, чтобы узнать, как создавать дампы. Иногда необходимо проверить содержимое элементов кучи, чтобы выяснить, откуда они берутся.

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

person fvu    schedule 12.08.2011
comment
+1 совсем недавно обнаружил небольшую утечку памяти, только после переключения на Eclipse для анализа дампа кучи (обычно используется Netbeans) - person Paul Bellora; 14.08.2011

arrow_upward
0
arrow_downward

Кажется, у вас много объектов char[]. Я обнаружил, что большинство моих утечек памяти происходят из-за неправильно сконструированных циклов, где они повторяются больше раз, чем должны. Что создает огромное количество объектов, что приводит к утечке памяти.

Живые байты — это просто общее количество байтов, которые занимают живые объекты.

Используется много char[] активных байтов. Я бы с подозрением отнесся к этому, так как, вероятно, происходит утечка памяти.

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

Хорошим местом для чтения будет Введение в профилирование приложений Java в среде IDE NetBeans Должен быть в состоянии помочь вам с отладкой в ​​​​NetBeans.

Надеюсь это поможет.

person adamjmarkham    schedule 12.08.2011