Как работает система поколений при сборке мусора?

Принцип работы системы поколений (Generational GC)

Система поколений (Generational Garbage Collection) — это оптимизационная стратегия сборки мусора, основанная на эмпирическом наблюдении, известном как "гипотеза о поколениях" (weak generational hypothesis). Она утверждает, что большинство объектов в типичных Java/Kotlin-приложениях живут очень недолго ("умирают молодыми"), а выжившие объекты, как правило, остаются в памяти надолго.

Архитектура кучи с поколениями

Куча делится на два или три основных физических раздела (поколения):

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

• Eden Space: Здесь размещаются все новые объекты при их создании.
• Survivor Spaces (S0 и S1, "To" и "From"): Два равных по размеру региона для объектов, переживших сборку мусора в Eden.

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

Сюда перемещаются объекты, которые пережили несколько сборок в молодом поколении.

3. Permanent Generation / Metaspace (в современных JVM)

Хранит метаданные классов, строковые константы (до Java 8).

Механизм работы

Фаза создания объектов

// Все новые объекты создаются в Eden
val newObject = MyClass() // Размещается в Eden Space

Minor GC (Малая сборка)

1. Когда Eden заполняется, запускается Minor GC
2. Алгоритм (чаще всего Copying Collector) работает:
   • Все живые объекты из Eden копируются в Survivor Space S0
   • Мертвые объекты в Eden игнорируются (память освобождается)
   • Объекты из S1 (если есть) также проверяются и копируются в S0

// Пример жизненного цикла объекта
class DataHolder(var data: String)

fun process() {
    val temp = DataHolder("temporary") // Создан в Eden
    // temp становится недостижимым после выхода из метода
    // Будет собран при следующем Minor GC
}

Повышение поколения (Promotion)

Каждый объект имеет счетчик возраста (age counter). При каждой выжившей сборке в молодом поколении возраст увеличивается. Когда возраст достигает порога (обычно 15), объект промотируется (promoted) в старое поколение.

// Псевдокод логики промоции
if (object.age > PROMOTION_THRESHOLD) {
    moveToOldGeneration(object);
}

Major/Full GC (Полная сборка)

Когда Old Generation заполняется, запускается Major GC, который:

• Сканирует все поколения
• Использует более медленные алгоритмы (Mark-Sweep-Compact)
• Вызывает заметные паузы (STW - Stop-The-World)

Преимущества системы поколений

✅ Уменьшение времени пауз: Minor GC работает только с маленьким Young Generation, поэтому выполняется быстро.

✅ Локальность данных: Связанные объекты часто создаются вместе и остаются рядом в памяти.

✅ Эффективное использование памяти: Быстрое освобождение памяти от короткоживущих объектов.

Алгоритмы для разных поколений

Для Young Generation:

• Copying Collector (быстрый, но требует свободного пространства)
• Parallel New Collector (многопоточная версия)

Для Old Generation:

• Mark-Sweep-Compact (помечать → очищать → уплотнять)
• Concurrent Mark-Sweep (CMS) - минимизирует паузы
• G1/Garbage First (современный, работает с регионами)
• ZGC/Shenandoah (ультра-низкие паузы)

Практическое значение для Android

В Android с ART (Android Runtime) система поколений реализована с оптимизациями:

// Важно избегать преждевременных промоций
class DataManager {
    // ПЛОХО: большие временные объекты
    fun processData() {
        val largeBuffer = ByteArray(10 * 1024 * 1024) // 10MB в Eden
        // Может вызвать частые Major GC
    }
    
    // ХОРОШО: переиспользование объектов
    private val reusableBuffer = ByteArray(1024)
    fun optimizedProcess() {
        // Используем существующий буфер
    }
}

Оптимизации разработчика

1. Избегайте утечек памяти в старом поколении
2. Минимизируйте создание объектов в циклах
3. Используйте пулы объектов для часто создаваемых типов
4. Настройте параметры GC через JVM флаги при необходимости

Система поколений обеспечивает баланс между производительностью сборки мусора и использованием памяти, что критически важно для responsive-приложений, особенно на мобильных устройствах с ограниченными ресурсами.