Поколенческий сборщик мусора

Поколенческий сборщик мусора (generational garbage collector) — это разновидность автоматического управления памятью (сборщика мусора), основанная на гипотезе о том, что большинство объектов в программе имеют короткое время жизни. Данный подход разделяет объекты на несколько поколений по возрасту и обрабатывает их с разной частотой, что позволяет повысить производительность сборки мусора за счёт сокращения времени анализа долгоживущих данных.

История

Концепция поколенческой сборки мусора была впервые предложена в 1984 году Дэвидом Унгером в рамках проекта Smalltalk-80. Унгер заметил, что в типичных программах около 80–90 % созданных объектов освобождаются вскоре после создания. Это наблюдение, известное как «гипотеза поколений» (generational hypothesis), легло в основу алгоритма.

В 1990-е годы поколенческие сборщики начали активно внедряться в коммерческие реализации виртуальных машин: Java Virtual Machine (JVM) компании Sun Microsystems, среда выполнения .NET Framework от Microsoft, а также в интерпретаторы языков Python и Ruby. В 2000-е годы алгоритм стал стандартом для большинства современных сред исполнения, включая V8 (JavaScript), Go и Rust (в виде библиотек).

Гипотеза поколений

Гипотеза поколений утверждает два эмпирических наблюдения:

• Большинство объектов умирают молодыми — значительная часть выделенной памяти освобождается вскоре после создания (например, временные переменные, строки, промежуточные результаты).
• Старые объекты редко ссылаются на новые — долгоживущие объекты (например, глобальные конфигурации, кэши) обычно не указывают на только что созданные, что упрощает анализ связей между поколениями.

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

Устройство и принцип работы

Деление на поколения

Память делится на несколько областей (поколений), обычно от двух до трёх:

• Молодое поколение (young generation) — область для недавно созданных объектов. Обрабатывается чаще всего. Внутри может делиться на Eden-пространство (для первичного выделения) и Survivor-пространства (для перемещения выживших объектов).
• Старое поколение (old generation) — область для объектов, переживших несколько циклов сборки в молодом поколении. Обрабатывается реже, но каждая сборка занимает больше времени.
• Постоянное поколение (permanent generation / metaspace) — в некоторых реализациях (например, в JVM до Java 8) выделялось для метаданных классов и методов. В современных версиях заменено на Metaspace, не являющееся частью кучи.

Циклы сборки

Сборка мусора в поколенческой системе включает два типа циклов:

• Minor GC (малая сборка) — обрабатывает только молодое поколение. Выжившие объекты перемещаются в Survivor-пространство или, после нескольких циклов, в старое поколение. Выполняется быстро, так как анализируется лишь небольшая часть кучи.
• Major GC (полная сборка) — обрабатывает все поколения, включая старое. Запускается реже, но может вызывать длительные паузы («stop-the-world»). В современных сборщиках (например, G1 в Java) полная сборка может быть частичной.

Алгоритмы внутри поколений

Внутри поколений могут применяться различные алгоритмы:

• Mark-Sweep (пометка-очистка) — отмечает живые объекты, затем освобождает мёртвые.
• Mark-Compact (пометка-уплотнение) — дополнительно сдвигает живые объекты для устранения фрагментации.
• Copying (копирование) — используется в молодом поколении: живые объекты копируются в другую область, а исходная полностью очищается. Это эффективно при высокой смертности объектов.

Классификация поколенческих сборщиков

По количеству поколений

• Двухпоколенческие — молодое и старое поколения. Распространены в .NET и Python.
• Трёхпоколенческие — молодое, среднее и старое поколения. Используются в Ruby (MRI) и некоторых реализациях JVM (например, G1).

По типу сборки

• Инкрементальные — сборка выполняется частями, снижая паузы. Пример: G1 (Garbage-First) в Java.
• Параллельные — несколько потоков одновременно обрабатывают поколения. Пример: Parallel GC в JVM.
• Конкурентные — сборка выполняется одновременно с работой программы. Пример: CMS (Concurrent Mark-Sweep) в Java (устарел), ZGC в Java 11+.

Применение

Поколенческие сборщики мусора применяются в большинстве современных сред выполнения, где требуется автоматическое управление памятью:

• Java Virtual Machine (JVM) — стандартный сборщик Serial GC, Parallel GC, G1, ZGC, Shenandoah. Все они основаны на поколенческой модели.
• .NET CLR — сборщик мусора с двумя поколениями (Gen0 и Gen1) и большим объектным кучей (Large Object Heap, LOH).
• Python (CPython) — с версии 2.1 использует поколенческий сборщик для циклических ссылок, дополняющий подсчёт ссылок.
• Ruby (MRI) — трёхпоколенческий сборщик (RGenGC) с версии 2.1.
• JavaScript (V8) — сборщик Orinoco с поколениями young и old.
• Go — с версии 1.5 использует конкурентный поколенческий сборщик.
• Erlang/OTP — поколенческий сборщик для каждого процесса.

Преимущества и недостатки

Преимущества

• Высокая производительность — большинство объектов освобождаются быстро, без полного сканирования кучи.
• Снижение пауз — малые сборки выполняются за миллисекунды, что критично для интерактивных приложений.
• Эффективное использование кэша — молодое поколение компактно, что улучшает локальность данных.

Недостатки

• Накладные расходы на перемещение — копирование выживших объектов в старое поколение требует времени и памяти.
• Сложность реализации — требуется точное отслеживание ссылок между поколениями (remembered sets или card tables).
• Риск длительных пауз — полная сборка старого поколения может занимать секунды, особенно в больших кучах.
• Неравномерная нагрузка — в приложениях с долгоживущими объектами (например, серверы с кэшами) эффективность снижается.

Критика и альтернативы

Поколенческая сборка мусора критикуется за то, что гипотеза поколений не всегда выполняется. В некоторых приложениях (например, базы данных с длительными транзакциями, научные расчёты) объекты могут жить долго, и сборка старого поколения становится узким местом. В таких случаях применяются:

• Сборщики без поколений (non-generational) — например, Boehm GC для C/C++, который обрабатывает всю кучу целиком.
• Региональные сборщики (region-based) — делят память на регионы разного размера и обрабатывают их независимо (G1, ZGC).
• Сборщики с отслеживанием времени жизни (age-based) — используют не только возраст, но и частоту доступа.

Интересные факты

• В Java 8 было удалено постоянное поколение (PermGen), заменённое на Metaspace, которое не является частью кучи и не участвует в поколенческой сборке.
• В .NET Core (начиная с версии 3.0) появилась поддержка сборщика мусора с режимом «серверный» (Server GC), который оптимизирует поколенческую сборку для многопроцессорных систем.
• В среде выполнения Go (с версии 1.5) сборщик мусора не использует поколения в классическом смысле, а применяет конкурентный алгоритм с триколорной маркировкой, хотя гипотеза поколений частично учитывается через эвристики.

Источники

• Jones, R., & Lins, R. (1996). Garbage Collection: Algorithms for Automatic Dynamic Memory Management. Wiley.
• Ungar, D. (1984). Generation Scavenging: A Non-disruptive High Performance Storage Reclamation Algorithm. ACM SIGPLAN Notices.
• Oracle. Java Virtual Machine Garbage Collection Tuning Guide.
• Microsoft. Garbage Collection Fundamentals in .NET.
• Python Software Foundation. Garbage Collector Design (PEP 442).