В реальном мире, особенно в области финансов и других областях с малым временем ожидания, вы действительно хотите свести к минимуму работу, которую должен выполнять GC, проанализировать кучу и выяснить возможные потери. «Просто позвольте GC выполнять свою работу» - хорошая стратегия для большинства Java-приложений, но не тогда, когда полная остановка 25 мс может стоить вам того, что хороший разработчик стоит в год.
я очень странная проблема. Я работаю над приложением OSGi, основанным на Eclipse Equinox; он был разработан с использованием OSGi Log Service (реализация Equinox), и сейчас я тестирую его с реализацией Apache Felix OSGi Log Service.
На стороне API / кода все работает отлично: служба журналов OSGi является стандартной, поэтому я могу без проблем переключаться с Equinox на Felix.
Однако я наблюдал это странное поведение: я запустил приложение как консольную программу, чтобы увидеть вывод журнала на консоли, и прикрепил его к JVisualVM для анализа использования памяти; график JVisualVM показывает используемую кучу 80 МБ.
Через 13 часов средний размер кучи достиг 220 МБ, поэтому я решил проанализировать дамп кучи и нажал кнопку «Дамп кучи»: после этой операции график JVisualVM показал использованную кучу 20 (мин) -35 (max) МБ (?!?!), и это значение было постоянным.
Может ли операция "Кучи дамп" освободить почти 200 МБ? Если да, то ПОЧЕМУ?
Я никогда не видел такого поведения с реализацией Equinox OSGi Log Service, поэтому я подозреваю, что Felix Log участвует в этой проблеме ...
Спасибо