Может ли кнопка JVisualVM Heap Dump освободить память?

у меня очень странная проблема. Я работаю над приложением OSGi на основе Eclipse Equinox; он был разработан с использованием службы журналов OSGi (реализация Equinox), и теперь я тестирую его с реализацией службы журналов Apache Felix OSGi.

Со стороны API/кода все работает нормально: служба журнала OSGi является стандартной, поэтому я могу без проблем переключиться с Equinox на Felix.

Однако я заметил это странное поведение: я запустил приложение как консольную программу, чтобы увидеть вывод журнала на консоль, и я подключил его к JVisualVM для анализа использования памяти; график JVisualVM показал используемую кучу размером 80 МБ.

Через 13 часов средний размер кучи достиг 220 МБ, поэтому я решил проанализировать дамп кучи и нажал кнопку «Дамп кучи»: после этой операции график JVisualVM показал используемую кучу 20(мин)-35 (max)MBs (?!?!), и это значение было постоянным.

Может ли операция "Heap Dump" освободить почти 200 мб? Если да, то ПОЧЕМУ?

Я никогда не видел такого поведения с реализацией Equinox OSGi Log Service, поэтому я подозреваю, что Felix Log связан с этой проблемой...

Спасибо


java memory heap-dump jvisualvm
person elDarioz    schedule 23.03.2011    source источник

Ответы (2)


arrow_upward
10
arrow_downward

Может ли операция "Heap Dump" освободить почти 200 мб? Если да, то ПОЧЕМУ?

Да, оно может. Я не изучал код, но уверен, что он вызывает HotSpotDiagnosticMXBean.dumpHeap со вторым аргументом, установленным в true (это значение по умолчанию, если вы вызываете его из jconsole или MBeans расширение для JVisualVM). По моему опыту, это вызовет явный сборщик мусора до того, как он сбросит кучу, и это, вероятно, ответ на вопрос «Почему?».

person Fredrik    schedule 23.03.2011
comment
Почему? Потому что, когда вы хотите найти утечку памяти, вы не хотите получать те объекты, на которые нет ссылок, но которые еще не были удалены сборщиком мусора. Поэтому VisualVM запускает полную сборку мусора перед созданием дампа кучи. - person Tomas Hurka; 24.03.2011
comment
@Томас Хурка Да? Конечно, именно поэтому у вас есть этот вариант (хотя есть и другие варианты). Я интерпретировал ПОЧЕМУ? больше похоже на то, почему он освобождает память? и ответ на это в том, что VisualVM запрашивает это перед дампом кучи. - person Fredrik; 24.03.2011
comment
Понимаю. Можете ли вы сказать мне, каковы эти действительно хорошие варианты использования другой альтернативы? - person Tomas Hurka; 24.03.2011
comment
@Thomas Hurka В большинстве случаев я использую его, когда хочу обнаружить непреднамеренные потери. Обычно при использовании чего-то вроде MAT для определения причины плохой производительности GC и тому подобного. - person Fredrik; 24.03.2011
comment
Если вы подозреваете, что ваша программа размещает много временных объектов во внутреннем цикле где-то, вы можете захотеть просмотреть кучу перед сборкой, чтобы увидеть, что они из себя представляют. В основном вы хотите, чтобы GC выполнял свою работу, но иногда это помогает производительности избежать выделения / gc в коде, интенсивно использующем ЦП. - person Christopher Barber; 18.03.2015

arrow_upward
2
arrow_downward

Почему вас вообще беспокоит GC? Если память правильно освобождена, беспокоиться не о чем. Но если вы хотите узнать, что вызывает рост кучи (даже если это не утечка), посмотрите на это: Как я могу получить дамп кучи на Java 5 без предварительного сбора мусора?.

person Tomasz Nurkiewicz    schedule 23.03.2011
comment
В реальном мире, особенно в области финансов и других областей с низкой задержкой, вы действительно хотите свести к минимуму работу, которую должен выполнять сборщик мусора, а также проанализировать кучу и выяснить возможные потери. Просто позволить сборщику мусора делать свою работу — хорошая стратегия для большинства Java-приложений, но не тогда, когда полная остановка в 25 мс может стоить вам столько же, сколько хороший разработчик стоит в год. - person Fredrik; 09.06.2016