Что такое поколения в GC (young, old, metaspace)

Виртуальная машина Java (JVM) разделяет управляемую память на поколения (Generations). В основе этого разделения лежит слабая гипотеза о поколениях (Weak Generational Hypothesis):

🟢 Junior Level

Виртуальная машина Java (JVM) разделяет управляемую память на поколения (Generations). В основе этого разделения лежит слабая гипотеза о поколениях (Weak Generational Hypothesis):

Подавляющее большинство создаваемых объектов (до 95–98%) являются временными и «умирают» почти мгновенно после создания.
Объекты, пережившие несколько циклов сборки мусора, с высокой вероятностью продолжат жить очень долго.

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

Три ключевые области:

Область	Где физически находится?	Что хранится?	Частота сборки GC
Young Generation (Молодое)	Внутри Java Heap	Все новые объекты приложения, локальные DTO, временные буферы	Очень часто (Minor GC, единицы миллисекунд)
Old Generation (Старшее / Tenured)	Внутри Java Heap	Объекты-долгожители, пулы соединений, синглтоны Spring, кэши	Редко (Major / Full GC, десятки и сотни мс)
Metaspace (Метаданные)	Вне кучи (в Native Memory ОС)	Описания классов (`Klass`), байткод методов, Runtime Constant Pool	Редко (только при выгрузке ClassLoader)

Бытовая аналогия

Young Generation: Мусорная корзина под рабочим столом. Очищается уборщиком по несколько раз в день за пару секунд (смятые черновики).
Old Generation: Домашний шкаф для одежды. Вещи лежат годами, генеральная уборка проводится редко, но занимает полдня.
Metaspace: Технический паспорт шкафа и чертежи квартиры. Это не сами вещи, а строительная документация, хранящаяся в отдельной папке на полке.

Жизненный цикл объекта (Promotion Pipeline)

[ new Object() ] 
       │
       ▼
   ┌───────┐
   │ Eden  │ ──(Minor GC: выжившие копируются)──► ┌──────────────┐
   └───────┘                                      │ Survivor S0  │
                                                  └──────┬───────┘
                                                         │ (Minor GC: ping-pong)
                                                         ▼
                                                  ┌──────────────┐
                                                  │ Survivor S1  │
                                                  └──────┬───────┘
                                                         │ (Возраст >= 15 или переполнение)
                                                         ▼
                                                  ┌──────────────┐
                                                  │   Old Gen    │
                                                  └──────────────┘

🟡 Middle Level

Внутреннее устройство Young Generation: Eden и Survivor

Young Generation разбито на три региона:

Eden (Рай): Сюда попадают абсолютно все новые объекты через быстрые локальные буферы потоков TLAB.
Survivor 0 (S0 / From Space) и Survivor 1 (S1 / To Space): Два буфера одинакового размера для выживших объектов.

По умолчанию соотношение размеров задается флагами:

-XX:NewRatio=2: размер Old Gen в 2 раза больше суммарного Young Gen (Young занимает $1/3$ кучи, Old — $2/3$).
-XX:SurvivorRatio=8: размер Eden относится к одному Survivor как $8:1$ (Eden занимает 80% Young Gen, S0 — 10%, S1 — 10%).

Алгоритм челночного копирования (Ping-Pong Copying):

В любой момент времени один из Survivor-регионов пуст (To-space), а второй содержит выжившие объекты (From-space).
При заполнении Eden запускается Minor GC:
- Живые объекты из Eden и активного Survivor копируются в пустой соседний Survivor.
- Всем скопированным объектам инкрементируется счетчик возраста (Age).
- Eden и старый Survivor очищаются одним сбросом указателя памяти.
- Роли Survivor меняются местами.

Продвижение в Old Generation (Tenuring & Promotion)

Объект продвигается (promoted) из Young Generation в Old Generation в трех случаях:

Достижение порога возраста (Tenuring Threshold): Объект успешно пережил заданное число Minor GC (по умолчанию -XX:MaxTenuringThreshold=15).
Преждевременное продвижение (Premature Promotion): Если суммарный объем выживших объектов превышает емкость региона Survivor, оставшиеся объекты сбрасываются напрямую в Old Gen.
Прямая аллокация больших объектов (Humongous Allocation): Очень большие массивы, не помещающиеся в TLAB/Eden, создаются сразу в Old Generation.

Metaspace: замена PermGen с Java 8

До Java 8 метаданные классов хранились в PermGen (Permanent Generation) внутри Java Heap:

PermGen имел жестко ограниченный размер (-XX:MaxPermSize), что при динамической генерации классов (Spring CGLIB, Hibernate) вызывало регулярный OutOfMemoryError: PermGen space.
В PermGen также находился строковый пул (String Pool) и статические поля.

С Java 8 PermGen полностью удален:

Метаданные классов перенесены в Metaspace — область нативной памяти операционной системы (Off-Heap).
Metaspace расширяется автоматически до физического лимита оперативной памяти сервера (если не ограничен флагом -XX:MaxMetaspaceSize).
Статические переменные классов и String Pool перенесены в обычный Java Heap.

🔴 Senior Level

Динамический расчет порога возраста (Dynamic Tenuring Threshold)

Флаг -XX:MaxTenuringThreshold=15 задает лишь максимально возможный предел возраста. На практике JVM динамически пересчитывает фактический порог продвижения на каждой сборке Minor GC с помощью параметра -XX:TargetSurvivorRatio (по умолчанию 50%):

В конце Minor GC виртуальная машина вычисляет распределение выживших объектов по возрастам (Age Table):
- Объем объектов с возрастом 1 = $X_1$
- Объем объектов с возрастом 2 = $X_2$
- …
JVM суммирует объемы: $S = X_1 + X_2 + \dots + X_k$.
Как только накопленная сумма $S$ превышает $50\%$ объема региона Survivor (TargetSurvivorRatio), порог возраста для этой сборки автоматически снижается до $k$!
Все объекты с возрастом $\ge k$ немедленно выталкиваются в Old Generation, чтобы предотвратить переполнение Survivor.

Физическое ограничение возраста: 4 бита в Mark Word

Частый вопрос на собеседованиях Senior: «Почему параметр MaxTenuringThreshold не может быть установлен больше 15?»

Ответ: В заголовке любого объекта в JVM HotSpot поле Mark Word имеет жестко фиксированную битовую структуру. Под хранение возраста объекта выделено ровно 4 бита: $2^4 - 1 = 16 - 1 = 15$ Максимальное число, которое можно закодировать в 4 битах — $11112 = 15{10}$. Любая попытка выставить -XX:MaxTenuringThreshold=16 завершится ошибкой инициализации виртуальной машины.

Эволюция поколений: Generational ZGC (Java 21+, JEP 439)

Изначально ZGC (Java 11–17) был однопоколенным (Single-Generational): сборщик сканировал всю кучу целиком. Это приводило к высокому потреблению ресурсов CPU на высоконагруженных приложениях с высоким темпом аллокации (Allocation Rate).

В Java 21+ представлен Generational ZGC (-XX:+UseZGC -XX:+ZGenerational):

Память разделена на Young и Old поколения, но сохраняется бесконкурентная природа ZGC (паузы $< 1$ мс).
Сборки в Young поколении запускаются гораздо чаще, задействуя минимум потоков CPU.
Достигнуто 4-кратное снижение нагрузки на процессор по сравнению с однопоколенным ZGC при сохранении ультранизких задержек.

🎯 Шпаргалка для интервью

30-секундный ответ (Elevator Pitch)

«JVM делит память на поколения на основе слабой гипотезы о поколениях: большинство объектов умирают молодыми. Young Generation (Eden + 2 Survivor S0/S1) хранит новые объекты и очищается быстрыми сборками Minor GC алгоритмом копирования. Old Generation хранит выжившие долгоживущие объекты (достигшие порога возраста или вытолкнутые при переполнении Survivor) и очищается более тяжелыми Major/Full GC. Metaspace находится вне кучи (в Native Memory) и хранит метаданные классов, байткод и Runtime Constant Pool. Предельный возраст объекта в Young Gen равен 15, так как под счетчик возраста в Mark Word заголовка объекта выделено ровно 4 бита».

3–4 каверзных вопроса с ответами

Почему в Young Generation используются именно два пространства Survivor (S0 и S1), а не одно?
- Ответ: Для полного устранения фрагментации памяти методом челночного копирования (Scavenge). Если бы был один Survivor, удаление умерших объектов внутри него оставляло бы пустоты («дыры»), требующие сложного уплотнения. Наличие двух областей позволяет всегда иметь один Survivor гарантированно пустым (To-space), куда выжившие объекты из Eden и активного Survivor плотно копируются подряд (bump-the-pointer), после чего исходные области очищаются мгновенно в один шаг.
Является ли Metaspace частью Java Heap?
- Ответ: Нет, Metaspace не входит в Java Heap. Начиная с Java 8, Metaspace располагается в нативной оперативной памяти процесса (Off-Heap). В Java Heap хранятся только сами экземпляры объектов, массивы, строковый пул и статические поля классов (внутри объектов java.lang.Class).
Почему максимальный порог продвижения (MaxTenuringThreshold) ограничен значением 15?
- Ответ: В заголовке объекта (Mark Word на 64-битной JVM) под счетчик возраста объекта (age bits) аппаратно выделено ровно 4 бита. Четырьмя битами можно представить числа от 0 до 15 ($2^4 - 1$). Число 16 физически невозможно записать в заголовок объекта.
Что такое динамический порог возраста (Dynamic Tenuring Threshold) и параметр TargetSurvivorRatio?
- Ответ: JVM не ждет обязательного достижения возраста 15. На каждом Minor GC строится таблица распределения выживших объектов по возрастам. Если суммарный объем объектов от возраста 1 до $N$ превышает процент TargetSurvivorRatio (по умолчанию 50% от размера региона Survivor), порог tenuring threshold принудительно снижается до $N$. Все объекты старше $N$ немедленно продвигаются в Old Generation, чтобы избежать переполнения Survivor.

Типичные ошибки и Red Flags

🚩 Утверждение: «Metaspace находится внутри кучи Java Heap» (грубейшая ошибка: Metaspace находится в Native Memory).
🚩 Заблуждение: «Объекты попадают в Old Generation только после достижения возраста 15» (объекты могут попасть туда раньше из-за dynamic tenuring threshold, humongous allocations или нехватки места в Survivor).
🚩 Утверждение: «Minor GC очищает всю кучу целиком» (Minor GC работает строго внутри Young Generation; для старшего поколения работают Concurrent Marking или Full GC).
🚩 Путаница между PermGen и Metaspace (PermGen был внутри Heap с фиксированным размером; Metaspace — в Native Memory с динамическим расширением).

Связанные темы

Что такое Young Generation — детальное устройство Eden и Survivor
Что такое Old Generation (Tenured) — алгоритмы сборки старшего поколения
Что такое Metaspace (или PermGen) — архитектура памяти классов
Какие алгоритмы GC существуют — Copying vs Mark-Sweep vs Mark-Compact
Что такое Garbage Collection — общие принципы работы сборщика мусора