Как JVM связана с областями поколения объектов

# Как JVM связана с областями поколения объектов

Управление памятью в Java основано на концепции поколений (Generational Garbage Collection). JVM разделяет кучу (Heap) на несколько областей, потому что выяснилось, что молодые объекты обычно живут очень недолго, а старые объекты живут долго.

Гипотеза слабой поколенческой ссылки

Исследования показали, что в типичных приложениях:

• 90% объектов умирают в первые секунды жизни
• Старые объекты редко ссылаются на молодые
• Молодые объекты часто ссылаются на старые

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

Структура кучи в JVM

1. Young Generation (Молодое поколение)

Основное место, где создаются новые объекты. Состоит из трёх областей:

Young Generation:
  ├── Eden Space (Эдем)
  ├── Survivor Space 0 (От 0)
  └── Survivor Space 1 (От 1)

Eden Space — основная область для новых объектов:

Object obj = new Object(); // создаётся в Eden

Когда Eden переполняется, запускается Minor Garbage Collection (быстрая сборка):

1. Живые объекты из Eden копируются в Survivor 0
2. Мёртвые объекты удаляются
3. Когда Survivor 0 переполнится, объекты копируются в Survivor 1

Survivor Spaces — переходные области для выживших объектов:

Iterация 1: Eden → Survivor0 (age=1)
Iterация 2: Survivor0 → Survivor1 (age=2)
Итерация 3: Survivor1 → Survivor0 (age=3)
...
После N сборок: → Old Generation

2. Old Generation (Старое поколение)

Для долгоживущих объектов, которые пережили несколько Minor GC:

// После многих Minor GC объект попадает сюда
Object oldObject; // существует давно → Old Generation

Сборка мусора в Old выполняется реже и дольше:

Minor GC: каждые N миллисекунд (быстро)
Major/Full GC: редко, когда Old переполнится (медленно)

3. Permanent Generation / Metaspace (Java 8+)

Для метаданных класса (не входит в Heap стандартно):

public class User {} // информация о классе → Metaspace

Порядок размещения объектов

Этап 1: Создание

List<String> list = new ArrayList<>(); // Eden
for (int i = 0; i < 1000; i++) {
    list.add(new String("temp" + i)); // Eden
}

Этап 2: Minor GC (когда Eden полон)

До Minor GC:
[Eden: 100MB] [Survivor0: 5MB] [Survivor1: 0MB] [Old: 50MB]

После Minor GC:
[Eden: 0MB] [Survivor0: 20MB] [Survivor1: 0MB] [Old: 50MB]
(живые объекты → Survivor0)

Этап 3: Promotion в Old

// Объект прожил много Minor GC
Object persistent = new Object(); // Young → Old после N сборок

Этап 4: Major GC

Когда Old переполнится → Major GC (Full GC)
Останавливает приложение (Stop-the-World pause)

Основные Garbage Collectors

1. Serial GC

-XX:+UseSerialGC

Одноточечный, для малых приложений.

2. Parallel GC

-XX:+UseParallelGC

Множество потоков, хороший throughput.

3. CMS (Concurrent Mark Sweep)

-XX:+UseConcMarkSweepGC

Минимизирует паузы, но более сложный.

4. G1GC (Garbage First)

-XX:+UseG1GC

Современный, предсказуемые паузы, рекомендуется.

// Пример запуска с G1GC
// java -XX:+UseG1GC -Xms4G -Xmx4G MyApp

Мониторинг поколений

# Просмотр размера поколений
jmap -heap <pid>

# Реал-тайм мониторинг
jstat -gc <pid> 1000

# Подробный анализ
jstat -gcdetails <pid>

Пример вывода jstat

S0C    S1C    S0U    S1U      EC       EU        OC         OU
512    512    100    0      4096     3000     20480      15000

S0C/S1C = Survivor Capacity
OC = Old Capacity
EC = Eden Capacity

Настройка размеров поколений

# Размер Young Generation (Eden + Survivor)
-Xmn1G

# Размер Survivor относительно Eden
-XX:SurvivorRatio=8  # Eden : Survivor = 8:1

# Age порог для promotion в Old
-XX:MaxTenuringThreshold=15  # объект должен пережить 15 Minor GC

# Пример полной конфигурации
java -Xms4G -Xmx4G -Xmn1G -XX:SurvivorRatio=8 \
     -XX:+UseG1GC -XX:MaxGCPauseMillis=200 MyApp

Оптимизация для приложения

Если много молодых объектов

-Xmn1.5G  # Больше Young Generation

Если много долгоживущих объектов

-Xmn512M  # Меньше Young, больше Old

Если требуется минимизировать паузы

-XX:+UseG1GC -XX:MaxGCPauseMillis=100

Резюме

JVM связана с поколениями памяти потому что:

1. Молодые объекты живут коротко → быстрые Minor GC
2. Старые объекты живут долго → редкие Major GC
3. Это снижает паузы → приложение работает быстрее
4. Оптимизирует CPU кеш → локальность данных

Поколенческая сборка мусора — это компромисс между скоростью приложения и эффективностью управления памятью.