GC tradeoffs: пауза, throughput, память и давление аллокаций

Две команды. Одна переходит с G1 на ZGC и снижает паузы с 60 мс до <1 мс — но throughput падает на 12%, а память растёт на 18%. Другая сокращает аллокации на 60% и снижает паузы с 200 мс до 15 мс — без смены коллектора. Какая правка долгосрочнее?

3-way tradeoff

Каждый GC выбирает две из трёх:

Выбор коллектора — это вопрос workload’а. Batch-сервисам без требований к latency подходит throughput → ParallelGC. Latency-sensitive интерактивным сервисам нужны короткие паузы → ZGC, Shenandoah, Go. Неправильный выбор может стоить 30–50% throughput или 10x p99 latency.

Справочные числа GC

• Go concurrent GC, типичный STW: ~100 мкс – 1 мс
• JVM G1 по умолчанию: 200 мс (цель)
• JVM ZGC пауза: <1 мс на кучах несколько ТБ
• V8 Orinoco типичная пауза: 5–15 мс
• Накладные расходы write barrier: ~2–10% CPU
• Rate аллокаций, при котором GC начинает доминировать: ≥500 МБ/с/ядро
• GOGC по умолчанию: 100 (куча удваивается между циклами)
• Доля GC в здоровом сервисе: <5% CPU типично

Давление аллокаций как первопричина

Если сервис аллоцирует 1 ГБ/с, GC будет занят вне зависимости от коллектора. Давление аллокаций — причина; время паузы — симптом.

Сокращение давления аллокаций имеет неограниченный потенциал; настройка GC — ограниченный (оптимизирует стоимость работы, но не устраняет её). Паттерн среднего+ разработчика: когда GC широко представлен в профиле, смотрим на профиль аллокаций. Широкий листовой узел в профиле аллокаций — цель.

Приоритет правок (от большего рычага к меньшему):

1. Устранить аллокацию целиком (мутация на месте, struct-of-arrays, примитивы).
2. Пул/переиспользование аллокации (sync.Pool в Go, пулы объектов в Java/JS).
3. Escape analysis — стековая аллокация вместо кучи (работает в Go, .NET, частично в JVM с C2).
4. Уменьшить аллокацию (меньший struct, меньший буфер, предварительно sized контейнер).
5. Убрать аллокацию с hot path (вычислить один раз, переиспользовать).
6. Настроить коллектор (GOGC, MaxGCPauseMillis, max-old-space-size).
7. Сменить алгоритм GC (ParallelGC → G1 → ZGC).

Object pooling: когда работает, когда нет

sync.Pool в Go, Apache Commons Pool в Java, пулы объектов в .NET — паттерны переиспользования аллокаций для снижения давления на GC.

Работает хорошо: объекты дорогие в создании и кратко используются на hot path — bytes.Buffer, JSON-энкодеры, regexp-объекты, scratch slices.

Не работает или вредит:

• Объекты дёшевы в создании (экономия меньше накладных расходов пула).
• Объекты долгоживущие (пул держит память без освобождения).
• Координационные расходы потоков превышают экономию от аллокации.

sync.Pool в Go имеет преимущество: GC может опустошить пул между циклами — память не теряется навсегда. Пулы JVM/.NET держат память до явного освобождения.

Правило: пулить только то, что профиль отмечает как горячий узел аллокации. Не пулить превентивно.