Может ли JVisualVM кнопка «Сброс кучи» освободить память?

Question

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

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

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

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

Может ли операция "Сброс кучи" освободить почти 200 МБ?Если да, то ПОЧЕМУ?

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

спасибо

Answer 1

Может ли операция "Сброс кучи" освободить почти 200 МБ? Если да, то ПОЧЕМУ?

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

Answer 2

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