Сборка мусора в JVM

Сборщик забирает недостижимое, а не ненужное

Создал weak-ссылку и soft-ссылку на два массива и позвал System.gc(). Weak обнулилась, soft осталась жива. Дальше набивал кучу до отказа - перед самым падением обнулилась и soft. А weak на объект, который держала обычная переменная, пережила всё.

Вот вся механика в одном замере. Сборщик обходит граф от GC roots - стеков потоков, статических полей, ссылок из нативного кода через JNI (Java Native Interface) - и забирает то, до чего не дошёл. Обычная ссылка (strong) держит объект намертво. Weak сдаётся на ближайшей сборке. Soft держится, пока память есть, и жертвует собой перед падением - потому и годится под кэш «лучше медленно, чем упасть».

Отсюда честный ответ про утечки: они есть. Достижимый, но забытый объект - кэш без выселения, статическая коллекция, неотписанный листенер - для сборщика законный жилец. Читать твои намерения он не умеет, он умеет ходить по ссылкам.

GC roots

точки старта обхода: стеки, статика, JNI

soft / weak

чистится под давлением памяти / на ближайшей сборке

Молодая сборка стоит по выжившим

Те самые 1907 МиБ мусора через кучу 64 МиБ: Serial сделал 328 сборок и потратил на паузы 12 мс суммарно. Двенадцать миллисекунд на два гигабайта мусора - примерно 0,04 мс на сборку.

Так дёшево вышло потому, что в моём цикле почти ничего не выживало. Молодая сборка копирует выживших в survivor и объявляет остаток свободным; мёртвые объекты не обходятся и не стоят ничего. Мусор в Java дёшев ровно до тех пор, пока умирает молодым.

Ломается всё, когда объекты доживают до переезда в old. Full GC берётся за старое поколение целиком, и вот он уже дорогой. Частые full GC - обычно признак преждевременного promotion: «подростки» не успели умереть в young, переехали и умерли там, где уборка стоит дорого. Лечится это чаще снижением аллокационного трафика, чем флагами.

minor / full GC

уборка молодого поколения / всей кучи

stop-the-world

пауза всех прикладных потоков на время работы сборщика

Какой сборщик тебе дали на самом деле

Запустил java в контейнере с лимитом 1791 МиБ и двумя ядрами, распечатал флаги: UseSerialGC=true. Поднял лимит до 1792 МиБ - UseG1GC=true. Вернул 2 ГиБ, но оставил одно ядро - снова Serial.

То есть G1 включается по умолчанию только на «серверной» машине: минимум 1792 МиБ памяти И минимум два ядра, оба условия сразу. Половина продовых подов с лимитом в гигабайт молча работает на Serial - однопоточном сборщике, - и никто об этом не знает, пока не посмотрит флаги.

Чем это оборачивается, видно на живом наборе в 450 МиБ при куче 900 МиБ. Serial: 20 пауз, 769,6 мс суммарно, худшая 271,23 мс. Parallel: 14 пауз, 241,4 мс, худшая 53,13 мс. G1: 13 пауз, 51,6 мс, худшая 11,74 мс. Между худшей паузой Serial и G1 - 23 раза. Дальше по профилю. Нужны единицы миллисекунд на большой куче - ZGC: он переносит объекты одновременно с работой приложения, не останавливая его, и платит за это лишним процессорным временем. Нужна максимальная суммарная пропускная способность, а паузы терпимы (ночной пересчёт, отчёты) - Parallel.

// смотри флаги, а не документацию:
// java -XX:+PrintFlagsFinal -version | grep -E "UseG1GC|UseSerialGC"

// лимит 1791 МиБ, 2 ядра -> UseSerialGC = true   {ergonomic}
// лимит 1792 МиБ, 2 ядра -> UseG1GC     = true   {ergonomic}
// лимит 2 ГиБ,    1 ядро -> UseSerialGC = true   {ergonomic}

G1

региональный сборщик с целевой паузой, дефолт на серверной машине

эргономика JVM

автовыбор сборщика и размеров кучи по железу и лимитам

Тюнинг: сначала данные, потом флаги

Позвал System.gc() и посчитал сборки через GarbageCollectorMXBean: было ноль, стало одна. Добавил -XX:+DisableExplicitGC - осталось ноль. То есть это просьба, которую администратор гасит одним флагом, и в проде обычно гасит.

Смотреть надо не в среднее. У Serial в моём замере средняя пауза вышла 38,48 мс при худшей 271,23 мс - разница в семь раз, и SLA (service level agreement) рвёт именно худшая. Отсюда рабочий порядок: включить GC-логи флагом -Xlog:gc, посмотреть частоту, длительность и темп promotion, а оценивать по p99 - это значение, хуже которого оказался только один замер из ста. Средняя прячет редкие длинные паузы, p99 их показывает.

// А самый действенный тюнинг обычно вообще не в флагах. Тот же цикл с объектами, которые не покидают метод: 97 мс и НОЛЬ сборок, потому что JIT (just-in-time) убрал аллокации. С -XX:-DoEscapeAnalysis - 1045 мс и 985 сборок. Меньше мусора в горячем коде, и настраивать становится нечего.

-Xlog:gc

лог сборок: частота, длительность пауз, promotion

Как отвечать: «Как выберешь сборщик мусора для сервиса?»

Сначала посмотрю, что уже включено. G1 становится дефолтом только от 1792 мегабайт памяти и двух ядер, так что в поде на гигабайт я молча получу Serial - это одна строка с PrintFlagsFinal. Дальше от профиля. Онлайн-сервису с требованием по латентности - G1: на моём замере с живым набором в 450 мегабайт худшая пауза у него была 11,74 мс против 271 мс у Serial. Если нужны единицы миллисекунд на большой куче - ZGC, он перемещает объекты одновременно с работой приложения, а платим за это процессорным временем. Ночному пересчёту, где важна суммарная пропускная способность, а не отклик, лучше Parallel: паузы длиннее, зато совокупно быстрее. Но до смены сборщика я включу -Xlog:gc и посмотрю на длину пауз по p99 и на темп promotion: частые full GC чаще лечатся снижением аллокаций в горячем коде, чем флагами.

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

На чём валят

• −«В Java есть сборщик, значит утечек нет». Достижимый мусор - кэш без выселения, статическая коллекция, листенер - не заберут никогда.
• −Считать, что G1 включён. Ниже 1792 МиБ памяти или на одном ядре JVM молча ставит Serial; проверяется одной командой с -XX:+PrintFlagsFinal.
• −Судить о сборщике по средней паузе. У меня средняя была 38 мс при худшей 271 мс - SLA рвёт вторая.
• −Мерить сборщики на потоке чистого мусора. Там побеждает Serial, потому что копировать нечего; на живом наборе картина переворачивается.
• −System.gc() в проде «для порядка». Это внеплановая пауза на ровном месте, а на многих стендах вызов ещё и выключен флагом.