Что такое ZGC

Ключевое инженерное достижение ZGC: длительность пауз Stop-The-World (STW) составляет менее 1 миллисекунды и практически не зависит от объема кучи (Heap). Пауза на куче в 16 ГБ...

🟢 Junior Level

ZGC (Z Garbage Collector) — это ультрасовременный сборщик мусора со сверхнизкими задержками (Sub-millisecond Latency), способный управлять оперативной памятью от десятков гигабайт до 16 терабайт.

Ключевое инженерное достижение ZGC: длительность пауз Stop-The-World (STW) составляет менее 1 миллисекунды и практически не зависит от объема кучи (Heap). Пауза на куче в 16 ГБ и на куче в 16 ТБ будет одинаково микроскопической (обычно от 0.1 до 0.5 мс).

Главный компромисс ZGC

ZGC спроектирован для систем с жесткими требованиями к SLA ответа: FinTech, High-Frequency Trading (HFT), Real-Time Bidding, телеком, игровые серверы.

Цена ультранизких пауз: Пропускная способность (Throughput) у ZGC на 5–15% ниже, чем у G1 или Parallel GC, из-за постоянных накладных расходов на барьеры чтения (Load Barriers) на процессоре.

Бытовая аналогия

Обычный сборщик (G1 / Parallel): Ремонт центрального шоссе. Движение полностью перекрывают бетонными блоками на 30 минут, чтобы дорожная техника переложила асфальт (STW пауза). Все машины стоят в пробке.
ZGC: Рабочие укладывают новый асфальт прямо на соседней полосе, пока автомобили продолжают ехать со скоростью 80 км/ч. Скорость потока слегка снизилась из-за ограничений, но шоссе ни на секунду не останавливается.

🟡 Middle Level

3 технологических столпа ZGC

Секрет отсутствия пауз в ZGC базируется на трех фундаментальных технологиях:

1. Colored Pointers (Цветные указатели)

В 64-битной архитектуре для адресации памяти достаточно 42–44 бит (до 16 ТБ). ZGC использует свободные старшие биты 64-битной ссылки для прямого кодирования метаданных сборщика мусора:

┌────────────────────────────────────────────────────────┐
│                   64-BIT ZGC POINTER                   │
├─────────────┬───────────┬───────────────┬──────────────┤
│ 16 бит      │ 4 бита    │ 1 бит         │ 43 бита      │
│ Не исп. (0) │ Цвет (GC) │ Зарезервирован│ Адрес в RAM  │
└─────────────┴───────────┴───────────────┴──────────────┘

Цветовые биты: Marked0, Marked1, Remapped, Finalizable.
Преимущество: Сборщик мусора определяет статус объекта (жив ли он, перенесен ли на новый адрес), просто прочитав сам указатель, без обращения к заголовку объекта в оперативной памяти!
Следствие: ZGC работает строго на 64-битных JVM и не поддерживает сжатые указатели (Compressed OOPs).

2. Load Barriers (Барьеры чтения) и механизм Self-Healing

В отличие от G1, перехватывающего запись ссылок, ZGC вставляет проверку при каждом чтении ссылки из кучи:

String name = user.getName(); // JIT вставляет Load Barrier перед разыменованием

Процессор проверяет цвет бита Remapped в адресе. Если бит корректен — чтение выполняется за 1 такт процессора.
Если бит сигнализирует, что объект сейчас эвакуируется на новый адрес:
- Срабатывает обработчик Load Barrier: он находит новый адрес объекта по таблице переадресации.
- Self-Healing (Самоисцеление): Поток прямо на лету перезаписывает старый указатель в памяти на новый адрес через атомарный CAS.
- При повторном обращении этот указатель уже «исцелен» и читается мгновенно.

3. Concurrent Evacuation (Конкурентная эвакуация)

Самая долгая фаза традиционных сборщиков — физическое перемещение выживших объектов и обновление всех ссылок на них — в ZGC выполняется в параллельных фоновых потоках без остановки приложения.

Сравнительная таблица: G1 GC против ZGC

Критерий	G1 GC	ZGC (Generational)
Длительность STW пауз	20–200 мс (зависит от настроек)	< 1 мс (гарантированно)
Зависимость паузы от Heap	Растет с увеличением памяти	Не зависит от размера кучи
Предельный размер памяти	Эффективен до 32–64 ГБ	До 16 Терабайт
Барьеры памяти	Write Barriers (при записи)	Load Barriers (при чтении)
Пропускная способность (Throughput)	Высокая	Ниже на 5–15%
Compressed OOPs	Поддерживается (< 32 ГБ)	Не поддерживается (требует 64 бита)

🔴 Senior Level

Эволюция: Generational ZGC (Java 21+, JEP 439)

В Java 11–17 ZGC был однопоколенным (Single-Generational):

При каждом цикле сканировалась вся 16-терабайтная куча целиком.
Если приложение генерировало огромное количество короткоживущих объектов в секунду (High Allocation Rate), сборщик не успевал размечать мусор. Возникал Allocation Stall (потоки приложения принудительно засыпали в ожидании освобождения страниц памяти).

Начиная с Java 21, представлен Generational ZGC:

Куча логически разделена на Young и Old поколения.
Young Generation собирается независимо, непрерывно и в разы быстрее, расходуя минимум ресурсов CPU.
Результат: Нагрузка на ядра CPU снижена в 2–4 раза, а риск Allocation Stalls практически сведен к нулю.
Как включить: Флаги -XX:+UseZGC -XX:+ZGenerational.

Мультимаппинг виртуальной памяти (Multi-Mapping)

Поскольку ZGC меняет биты цвета в указателе, процессор без специальной подготовки воспринял бы ссылки с битами Marked0 и Remapped как совершенно разные адреса оперативной памяти.

Для обхода этого ограничения ZGC на уровне ядра ОС (Linux virtual memory manager через mmap) отображает один и тот же физический фрейм оперативной памяти на 3 разных виртуальных диапазона адресов:

Виртуальный адрес (Marked0)  ────┐
Виртуальный адрес (Marked1)  ────┼───► Единая физическая страница RAM
Виртуальный адрес (Remapped) ────┘

Благодаря этому чтение по любому из «цветных» адресов всегда аппаратно попадает в одни и те же реальные данные в физической RAM.

Производственный тюнинг и мониторинг ZGC

# 1. Включение Generational ZGC (Java 21+)
-XX:+UseZGC -XX:+ZGenerational

# 2. Выделение потоков сборщика (по умолчанию = количество ядер / 4)
-XX:ConcGCThreads=4

# 3. SoftMaxHeapSize: мягкий лимит кучи для динамического сжатия в контейнерах
-XX:SoftMaxHeapSize=12g -Xmx16g

# 4. Логирование пауз и фаз ZGC
-Xlog:gc*,gc+phases=debug:file=/var/log/zgc.log:time,uptime,pid:filecount=5,filesize=100M

⚠️ Когда НЕ стоит использовать ZGC:

Если нагрузка является CPU-bound (процессор утилизирован на 85–95%): барьеры чтения Load Barriers создадут дополнительную нагрузку, которая просадит общую производительность.

Если куча меньше 4 ГБ: G1 эффективнее использует память малого объема благодаря Compressed OOPs.

Для пакетных Big Data расчетов (Batch): Parallel GC выполнит расчеты быстрее на 15–20%.

🎯 Шпаргалка для интервью

30-секундный ответ (Elevator Pitch)

«ZGC — масштабируемый сборщик мусора со сверхнизкими задержками (паузы < 1 мс), не зависящими от размера памяти (вплоть до 16 ТБ). Работает на основе Colored Pointers (биты статуса прямо в 64-битном указателе) и Load Barriers (перехват чтения ссылок с механизмом Self-Healing). Вся тяжелая фаза перемещения объектов происходит конкурентно, без остановки приложения. В Java 21+ стал генерационным (Generational ZGC), что устранило проблему Allocation Stalls и снизило потребление CPU. Платой за миллисекундные паузы является снижение пропускной способности (Throughput) на 5–15%».

3–4 каверзных вопроса с ответами

Каким образом ZGC удерживает паузы Stop-The-World менее 1 мс независимо от размера кучи?
- Ответ: В традиционных сборщиках длительность паузы зависит от объема живых объектов, которые необходимо скопировать на новое место (эвакуация). ZGC вынес фазу эвакуации и обновления ссылок из паузы STW в полностью параллельный режим (Concurrent). Во время ультракоротких пауз (< 1 мс) ZGC выполняет только остановку потоков на Safepoints для фиксации корней GC Roots, размер которых зависит лишь от числа потоков, а не от гигабайт кучи.
Что такое Colored Pointers (цветные указатели) и почему ZGC не поддерживает сжатые ссылки (Compressed OOPs)?
- Ответ: Colored Pointers — это технология использования свободных верхних 4 бит 64-битного адреса указателя (биты 42–45) для хранения метаданных состояния сборщика мусора (Marked0, Marked1, Remapped). Это позволяет мгновенно узнавать статус объекта без обращения к его заголовку в RAM. Из-за необходимости манипулировать битами внутри 64-битного указателя ZGC не может использовать сжатые 32-битные указатели (Compressed OOPs), поэтому на кучах менее 32 ГБ ссылки в ZGC занимают по 8 байт.
Что такое механизм Self-Healing (самоисцеление) в барьерах чтения ZGC?
- Ответ: Когда поток приложения читает поле-ссылку (Object obj = ref.field;), барьер чтения Load Barrier проверяет цвет указателя. Если объект был перемещен сборщиком, но ссылка в памяти еще хранит старый адрес, поток обращается к таблице переадресации, находит новый адрес, атомарно перезаписывает старую ссылку в куче на новый адрес и возвращает его вызывающему коду. Следующее чтение этого поля пройдет без задержки.
Почему в Java 21 потребовалось сделать ZGC генерационным (Generational ZGC)?
- Ответ: В однопоколенном ZGC сборщик был вынужден при каждом цикле сканировать всю кучу целиком, включая миллионы долгоживущих объектов. При высоком темпе создания короткоживущих объектов сборщик не успевал освобождать страницы памяти, что приводило к Allocation Stalls (потоки приложения засыпали в ожидании свободной памяти). Generational ZGC разделил кучу на Young и Old: молодое поколение собирается в разы чаще и дешевле, что снизило нагрузку на CPU на 50% и решило проблему задержек аллокации.

Типичные ошибки и Red Flags

🚩 Утверждение: «ZGC использует Write Barriers, как и G1» (ZGC использует Load Barriers на чтение ссылок).
🚩 Заблуждение: «ZGC поддерживает Compressed OOPs» (ZGC требует полные 64-битные указатели для Colored Pointers).
🚩 Слепой переход на ZGC при CPU-bound задачах (Load Barriers отнимают до 15% процессорного времени, усугубляя дефицит CPU).
🚩 Использование однопоколенного ZGC на Java 11/17 при экстремальном темпе аллокаций без учета риска Allocation Stall (надо переходить на Java 21+ Generational ZGC).

Связанные темы

Какие алгоритмы GC существуют — обзорная классификация сборщиков
Что такое G1 GC — сравнение G1 и ZGC
Что такое Shenandoah GC — альтернатива от Red Hat
Что такое stop-the-world — физика безопасных точек и пауз
Какие GC минимизируют stop-the-world паузы — детальный анализ задержек