Кратко и по сути.
Как работает generational GC
- Базовая гипотеза: большинство объектов «умирают молодыми» (обычно утверждают $>90\%$).
- Разделение по поколениям: обычно $2$ поколения — молодое (young) и старое (old). Новые объекты выделяются в молодом поколении.
- Minor GC: частые сборки молодого поколения — быстрые, часто реализуются как копирующие (копирование живых объектов в survivor-буферы), работают по времени пропорционально числу живых объектов, не всем кучи.
- Продвижение (promotion): объекты, пережившие несколько minor GC, переводятся в старое поколение. Старое поколение собирается реже (major/full GC), чаще марк-compact или mark-sweep+compact.
- Оптимизации: параллельные/конкуррентные сборщики, барьеры записи и remembered sets для избежания полного сканирования старого при minor GC, компактация для борьбы с фрагментацией.
Почему это эффективно для большинства приложений
- Большинство рабочих нагрузок действительно создают много краткоживущих временных объектов (запрос‑ответ, временные буферы и т.п.), поэтому minor GC быстро очищает большую часть мусора, снижая частоту дорогих полных GC.
- Minor GC работает на небольшой части кучи — меньше накладных расходов и более короткие паузы.
- Копирующие алгоритмы улучшают локальность данных и устраняют фрагментацию в молодом поколении, что ускоряет аллокации.
- За счёт редких сборок старого поколения общая нагрузка на GC снижается.
Какие классы приложений испытывают проблемы
- Приложения с большим объёмом долгоживущих объектов — большие in‑memory кэши, in‑memory базы/структуры (например, большие хранилища объектов, графы, сессии). Частые промоции и редкие освобождения ведут к частым и дорогим full GC.
- Нагрузки с высоким процентом выживаемости объектов (мало «умирающего молодого» мусора) — тогда выигрыш от молодого поколения пропадает, и система тратит ресурсы на продвижение/копирование.
- Приложения, активно выделяющие очень большие объекты, которые сразу попадают в large‑object space/старое поколение — ведёт к фрагментации и дорогим сборкам.
- Жёсткие требования к задержке/детерминизму (реальное время, низколатентные торговые системы) — непредсказуемые полные GC-паузы нежелательны.
- Сценарии с интенсивным взаимодействием с нативной памятью или с «залипшими» ссылками/финализаторами — GC не видит утечки в нативе, что ухудшает ситуацию.
Короткие рекомендации для проблемных случаев
- Тонкая настройка размеров поколений, порогов продвижения; использовать конкурентные/параллельные сборщики (G1, ZGC, Shenandoah) или уйти в off‑heap/пулы объектов; пересмотреть архитектуру (меньше долгоживущих аллокаций, кастомные кэши).
Если нужно, могу привести конкретные примеры режимов GC и советы по настройке для вашей нагрузки.