Как устроены поколения (generations) и когда срабатывает сборщик мусора?

Поколения (generations) и условия запуска сборщика мусора

• Поколения — это подход к управлению памятью, при котором объекты распределяются по продолжительности жизни: на молодое (new), старое (old) и, в некоторых реализациях, постоянное (perm) поколения.
• Молодое поколение хранит недавно созданные объекты и регулярно очищается в рамках minor GC, удаляющего короткоживущие объекты.
• Старое поколение включает объекты, пережившие несколько сборок молодого поколения. Оно очищается реже с помощью major/full GC, поскольку такая сборка обходится дороже и длится дольше.
• Сборщик мусора запускается в следующих случаях:
• молодое поколение заполняется (minor GC);
• старое поколение достигает предела заполнения (major/full GC);
• возникает нехватка памяти или наступает заданный момент времени.
• В основе лежит принцип поколений: поскольку большинство объектов существует недолго, такой подход повышает производительность и уменьшает накладные расходы.
• Современные GC, включая G1, CMS и ZGC, разбивают сборку на небольшие фазы, чтобы сократить длительность пауз.
• Конкретное условие запуска определяется алгоритмом GC. Например, сборка может начинаться при:
• достижении установленного порога заполнения;
• необходимости освободить память для размещения новых объектов.
• Практическая польза заключается в более эффективном управлении временем отклика приложения за счет настройки частоты и объема сборки.

При необходимости могу также привести примеры для распространенных платформ, включая JVM и .NET, и подробнее разобрать используемые алгоритмы.

Развернутый ответ

Основной ответ

Современные сборщики мусора (Garbage Collector, GC) часто используют стратегию поколений (generations), чтобы эффективнее освобождать память. Она основана на наблюдении: объекты с большим сроком жизни обычно реже становятся мусором, тогда как недавно созданные объекты чаще быстро устаревают. Поэтому память разделяют на молодое поколение (Young Generation) и старое поколение (Old Generation).

В молодом поколении размещаются новые объекты. Minor GC запускается часто, но обычно проходит быстро, поскольку значительная часть объектов здесь живет недолго. Объекты, которые сохраняются достаточно долго, «переживают» сборки (promoted) и переводятся в старое поколение.

Старое поколение предназначено для объектов с длительным жизненным циклом. Его очистка, называемая Major GC или Full GC, выполняется реже, однако занимает существенно больше времени: объем памяти и число живых объектов в нем обычно выше.

Когда запускается сборщик мусора

• Minor GC запускается при заполнении молодого поколения, например при переполнении Eden space. Он быстро удаляет объекты, не дожившие до следующей сборки, и возвращает занятую ими память.
• Major GC начинается при заполнении старого поколения либо тогда, когда системе требуется освободить значительный объем памяти. Такая операция требует больше времени и способна приостановить работу приложения.
• В некоторых JVM, например в HotSpot от Oracle, предусмотрен также Full GC. Он очищает все поколения, включая PermGen/Metaspace, где хранятся метаданные классов.
• Современные GC, такие как G1, ZGC и Shenandoah, стараются сократить паузы за счет инкрементальных и параллельных алгоритмов.

Главные выводы

• Разделение по поколениям делает сборку мусора эффективнее, сокращает среднюю длительность пауз и повышает throughput.
• Minor GC выполняются часто, длятся недолго и затрагивают только молодое поколение.
• Major/Full GC запускаются реже, но требуют больше ресурсов и включают старое поколение.
• Если объект сохраняется достаточно долго, он «переживает» несколько Minor GC и перемещается в старшее поколение. Благодаря этому долгоживущие объекты не приходится многократно обрабатывать в рамках сборок молодого поколения.

Практическое применение

В JVM HotSpot, например в Java 11, по умолчанию применяется Generational GC с явным разделением на Eden, Survivor spaces и Old Generation. В production-сценариях следует отслеживать частоту и продолжительность Major и Minor GC с помощью JVisualVM либо Prometheus с Exporter для JVM-метрик, чтобы предотвращать длительные паузы и состояния «стоп-миров». В системах, где критична задержка, используют G1 или ZGC: они оптимизируют работу с поколениям и помогают минимизировать паузы.