Что поменялось в сборщике мусора при обновлении версии Java

Что проверяют

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

Как отвечать

Сначала уточните, с какой версии на какую идёт переход: разговор про восьмёрку и семнадцатую отличается от разговора про соседние релизы. Дальше опорные точки, в которых стоит быть уверенным:

• в девятой версии сборщиком по умолчанию стал G1 вместо Parallel, а CMS объявили устаревшим;
• в одиннадцатой появились экспериментальный ZGC и Epsilon, сборщик, который ничего не собирает и нужен для замеров;
• в двенадцатой добавили Shenandoah, в четырнадцатой окончательно удалили CMS;
• в пятнадцатой ZGC и Shenandoah объявлены готовыми к продакшену;
• в двадцать первой ZGC стал поколенческим, то есть отдельно обрабатывает молодые объекты.

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

Где спотыкаются

Называют версии наугад и привязывают ZGC к десятке. Если не помните точно, так и скажите: «появился примерно тогда, стабильным стал позже». Выдуманный номер проверяется мгновенно и портит впечатление от остального ответа.

Второе: считают новый сборщик бесплатным ускорением. ZGC и Shenandoah платят за короткие паузы пропускной способностью и памятью, и на пакетной обработке Parallel нередко быстрее.

Третье: тащат старый набор флагов в новую версию. Тюнинг под CMS в лучшем случае игнорируется, в худшем виртуальная машина просто не стартует, потому что таких опций больше нет.