Почему Java Garbage Collector, кажется, делает агрессивный запуск вскоре после менее агрессивного?

Question

Наблюдая за Java-программой с помощью VisualVM, я заметил интересную закономерность в поведении сборщика мусора. Кажется, что очень часто, сразу после выполнения "нормального" запуска сборки мусора, GC выполняет второй, намного более интенсивный запуск процессора, который, похоже, не дает никакого дополнительного эффекта (Используемая куча после более агрессивного запуска примерно такая же, как это после легкого бега).

Я указал на выводе VisualVM, где вы можете увидеть запуск сборщика мусора и соответствующие изменения использования кучи.

Мой вопрос в основном, что здесь делает сборщик мусора и почему? Что заставляет его делать эти действительно интенсивные процессоры, когда имеется много свободной памяти и нет заметных преимуществ по сравнению с более легкими прогонами? Или я неправильно истолковываю график?

На производительность программы это не сильно влияет, мне просто любопытно.

Answer 1

Глядя на графики - это хорошая вещь, чтобы получить обзор прогонов GC, но если вы хотите изучить, почему GC работает в определенный момент, вам нужно углубиться в журналы GC.

Включите полное ведение журнала GC, также начните собирать jstat. Сосредоточьтесь на тех случаях, когда вы видите неожиданные циклы GC и отслеживайте их в журналах. Что ты там видишь? Попробуйте увидеть:

• Это полный или второстепенный сборщик мусора?
• Какие профессии в Эдеме, Перми, ОлдДжене, местах для выживших и т. д.?
• каковы показатели распределения, размер набора данных в реальном времени, коэффициенты продвижения в эти интервалы?
• и т.п.

Ответ на эти вопросы может привести к проблеме того, почему GC работает.

ОБНОВЛЕНИЕ: вы можете найти технические подробности о том, как настроить GC, например, в: Есть ли руководство по поваренной книге для проблем GC?