Патерни тюнінгу GC (збирача сміття Java)

GC-тюнінг – це не магія сеньйорів, а набір повторюваних патернів.
Ти перестаєш гадати, чому сервіс підвисає щоранку о 9:03, і починаєш керувати паузами як дорослий інженер.

Правильні патерни тюнінгу GC дають три бонуси:

стабільні latency без раптових фризів,
менші рахунки за залізо,
аргументи, щоб не дати менеджеру спихнути все на «ну ти ж щось там не так накрутив у JVM».

Інструменти

№	Патерн / інструмент	Ключовий показник (metric)	Типова ціль / орієнтир	Коли порівнювати
1	Мінімізація пауз	GC pause P95, ms	< 50–100 ms для онлайн сервісів	При аналізі latency API, UI, платежів
2	Максимізація пропускної здатності	Оброблені запити/події за годину	Максимум при прийнятних паузах	Для batch job, ETL, масових розрахунків
3	Контроль розміру heap	Heap usage %, Xms/Xmx	60–85% при стабільному навантаженні	При плануванні RAM, виборі лімітів у контейнерах
4	Робота з young generation	Minor GC / сек, young gen usage %	Часті, але короткі minor GC без promotion failure	Веб/мікросервіси з великою кількістю короткоживучих обʼєктів
5	Робота з old generation	Old gen occupancy %, GC pause P99	Old gen < 70–80%, паузи стабільні	Сервіси з кешами, сесіями, довгоживучими даними
6	Оптимізація Eden space	Eden refill time, MB/s alloc	Eden не заповнюється миттєво, але й не простоює	Піки навантаження, спайки трафіку
7	Тюнінг Survivor space	Survivor usage %, promotion rate %	Немає mass-promotion в old, survivor не переповнений	При рості old gen після піків навантаження
8	Зменшення promotion failure	Кількість promotion failure / год	≈ 0 подій за годину	Після збільшення навантаження або зміни схеми кешування
9	Уникнення частих Full GC	Full GC / добу	< 1–2 Full GC / добу	При скаргах на раптові фризи системи
10	Обмеження алокацій у пікових потоках	Allocation rate, MB/s	Зниження alloc rate без втрати бізнес-логіки	Аналіз гарячих endpoint-ів та потоків обробки
11	Pre-allocation структур	Pre-allocation hit ratio, %	> 80% звернень до вже виділених структур	Парсери, цикли, обробка логів
12	Оптимізація object pooling	Pool reuse ratio, %	> 70–80% reuse без contention	Гарячі обʼєкти з частим створенням/знищенням
13	Зменшення тимчасових обʼєктів	Обʼєктів/операцію, alloc MB/s	Вдвічі менше обʼєктів/операцію у гарячих шляхах	Після профайлінгу коду (JFR, async-profiler)
14	Tuning G1GC pause targets	MaxGCPauseMillis, ms	Target 50–200 ms під SLO	G1GC на проді, коли паузи стрибають
15	Tuning G1GC regions	Розмір регіону, MB	1–4 MB для більшості сервісів	При аналізі ефективності mixed/young GC в G1
16	Tuning G1GC mixed cycles	Mixed GC / хвилину, reclaimed MB	Стабільний reclaim без піків пауз	Коли old gen повільно, але впевнено зростає
17	Tuning G1 InitiatingHeapOccupancyPercent	IHOP %, heap at cycle start %	Старт циклу при 30–45% heap	Коли GC запускається або занадто рано, або запізно
18	Tuning G1 ReservePercent	Reserve %, old gen occupancy %	5–15% резерву без OOM	При тупиках через забитий old gen
19	Tuning ParallelGC threads	GC threads count	GC threads ≈ CPU cores або трохи менше	Для batch, heavy CPU job з ParallelGC
20	Tuning ZGC heap fragmentation	Fragmentation %, relocation thrash	Низька фрагментація при паузах < 10 ms	Low-latency сервіси з ZGC
21	Tuning ZGC relocation set	Relocated MB / цикл	Релокація не створює піків CPU	Високе навантаження на heap з ZGC
22	Tuning ZGC concurrent cycles	ZGC cycles / хвилину	Стабільна частота циклів без starvation	Прод-трафік з нерівномірними піками
23	Tuning Shenandoah evacuation	Evacuated MB / цикл	Ефективний репак без росту пауз	JVM на Shenandoah у Linux/RedHat
24	Tuning Shenandoah pacing	Pacing overhead %, pause time	Низький pacing overhead при стабільному latency	Коли Shenandoah дає непередбачувані спайки
25	Tuning metaspace limits	Metaspace MB, GC for metadata / год	Метадані без неконтрольованого росту, немає OOM	Динамічне завантаження класів, плагіни
26	Tuning compressed oops	Heap size GB, oops enabled	Використання compressed oops до ~32 GB	Великі сервіси з heap 8–32 GB
27	Tuning compressed class pointers	Class space MB	Compressed class pointers увімкнені	Велика кількість модулів / класів
28	Зменшення частоти safepoint	Safepoint time %, events / хв	Safepoint < 5% CPU часу	При підозрі, що стопи не від GC
29	Уникнення частих stop-the-world	STW pause P95, ms	Рідкі та короткі STW-паузи	Коли юзери бачать реальні фризи
30	Розподіл heap по поколіннях	Young/old ratio %, survivor size %	Баланс без promotion storm і OOM	Після змін моделі памʼяті або трафіку
31	Правильний розподіл thread stack	Thread stack size KB, threads count	Немає stack overflow й зайвого overcommit	Багатопотокові сервіси, thread pools
32	Tuning DirectByteBuffer usage	Direct memory MB, buffer count	Direct memory < ліміту, без OOM Direct buffer	Netty/NIO сервіси
33	GC-friendly data structures	Garbage/op, allocations/op	Менше обʼєктів на бізнес-операцію	Перехід на primitive/легкі колекції
34	Уникнення розмитих посилань	Ref-cleared events, cache hit ratio	Кеш не здувається при першому GC	Кеші на Soft/Weak reference
35	Tuning reference processing	Reference queue lag, ms	Малий lag обробки reference-черг	Інтенсивне використання Soft/Weak/Phantom
36	Tuning string deduplication	Dedup ratio %, string heap MB	Високий dedup ratio та економія heap	JSON/XML heavy сервіси, логування
37	Tuning interned strings	Intern table size, lookups/sec	Таблиця intern без вибухового росту	DSL, SQL/JPQL, власні мови
38	Tuning off-heap кешів	Off-heap cache MB, hit ratio %	Значна економія heap при стабільному hit ratio	Великі кеші, каталоги, карти
39	Tuning netty buffer sizes	Avg buffer size, fragmentation %	Мінімум дрібних алокацій, низька фрагментація	Netty/gRPC/кастомні протоколи
40	Tuning thread-local caches	ThreadLocal hit ratio %, memory per thread	Високий hit ratio без зайвого споживання памʼяті	Гарячі серіалізатори, форматери, парсери
41	Tuning allocation rate	Allocation rate MB/s, GC cycles / хв	Зниження alloc rate → менше GC циклів	Після ідентифікації гарячих алокацій
42	Tuning object lifetime distribution	Short-lived vs long-lived %, objects	Чітко розділені профілі життєвого циклу	Мікс кешів, потоків подій, сесій
43	Tuning finalizers avoidance	Finalizable objects count	~0 обʼєктів з фіналізаторами	Легасі-код, старі бібліотеки
44	Tuning cleaner tasks	Cleaner queue lag, cleaned objects/sec	Стабільний cleanup без піків пауз	Канали, сокети, файли
45	Tuning GC logging verbosity	GC log volume MB/добу	Логи дають картину, але не забивають диск	Прод-сервіси з аналізом логів
46	Аналіз GC логів	К-сть проаналізованих релізів/квартал	Кожен великий реліз має GC-ревʼю	Регулярні релізи, зміни трафіку
47	Інтеграція GC метрик у Prometheus	GC metrics coverage %, кількість дашбордів	Є дашка з GC-паузами, heap, Full GC	Усі важливі прод-сервіси
48	Контроль GC пауз у SLA	% запитів у SLO	> 99% запитів укладаються у latency SLO	Платіжні, критичні сервіси з контрактами

Порівняння

Якщо спростити до людських категорій, у нас є три великі сім’ї підходів:

Патерни «я не хочу пауз»
Мінімізація пауз, уникнення Full GC, tuning G1GC pause targets, tuning ZGC/Shenandoah, контроль safepoint.
Це для всього, де користувач живий і нервовий: фінтех, маркетплейси, ігри, будь-який UI чи API, який бачить юзер.
Патерни «я хочу прокачати throughput»
Контроль розміру heap, ParallelGC threads, оптимізація Eden/Survivor, pre-allocation, object pooling.
Тут ми дозволяємо довші паузи, але хочемо втиснути максимум роботи в одиницю часу: batch job, nightly репорти, ETL.
Патерни «я хочу, щоб GC менше чіпав мій код»
Зменшення тимчасових об’єктів, GC-friendly data structures, off-heap кеші, Netty-буфери, ThreadLocal кеші.
Це вже інженерна дієта: ми не тільки тюнимо JVM, а й переписуємо код, щоб він не поводився як пилосос для heap.

Реальне життя, звісно, суміш: ти водночас хочеш і latency, і throughput, і щоб на проді не палало. Але завжди корисно чесно відповісти собі:
«Що мені важливіше саме в цьому сервісі: час відповіді чи кількість оброблених запитів?»
Як тільки з’являється відповідь – стає ясно, які патерни в пріоритеті.

Best practices

Починати не з флагів JVM, а з GC-логів і метрик. Спочатку дивимось, потім крутити.
Міняти один параметр за раз і фіксувати результат, а не влаштовувати «оптом 15 флагів на удачу».
Тримати heap достатньо великим, але не гігантським на всяк випадок. Закон «а раптом знадобиться» вбив не один прод.
Спостерігати GC-паузи під реальним бойовим навантаженням, а не під локальним «я натиснув F5 пару разів».
Виносити патерни в чеклисти й knowledge base, щоб команда не повторювала одні й ті ж помилки кожен реліз.
Чітко розділяти «я міняю код» і «я тюню JVM». Спочатку проста оптимізація коду, потім магія флагів.
Домовитися з командою: будь-який серйозний GC-тюнінг – через профайлер і метрики, а не через «мені здається, так буде краще».
Використовувати G1GC як «дефолт для нормальних людей», а ZGC/Shenandoah – коли ти точно знаєш, що робиш і навіщо.
Окремо стежити за metaspace – він любить вистрілити в голову тоді, коли всі вже дивляться тільки на heap.
Регулярно переглядати GC-настройки після росту трафіку, появи нових фіч чи міграції в інший cloud/hardware.

Типові помилки

Включити екзотичний GC «бо десь у статті написали, що він найшвидший» і забути, що ваша система взагалі інша.
Скопіювати флаги JVM з блогу якогось євангеліста і не розуміти, що вони роблять.
Закрутити MaxGCPauseMillis до смішних значень і дивуватися, чому GC жере CPU, як голодний.
Робити гігантський heap, щоб «рідше прибирався», і потім дивуватися, чому одна пауза триває пів хвилини.
Заливати все в Soft/WeakReference і називати це «розумним кешем», який після першого ж стресу здувається, як повітряна кулька.
Ігнорувати GC-логи, логи валити в /dev/null, а потім у проді грати в детектив.
Ставити десятки лейєрів кешів (кожен зі своєю політикою) і потім звинувачувати GC, що він не розуміє «геніальну архітектуру».
Залишати фіналізатори та сподіватися, що JVM все за вас прибере. JVM не домробітниця.
Ввімкнути GC-логування на максимум деталізації й убити диск логами, а потім їх ще й ніхто не читає.
Плутати «latency проблеми» з «GC проблемами» і не дивитися в базу/мережу/локи, де насправді болить.

Сценарії, де це рятує життя

Прод у піку трафіку (чорна п’ятниця, зарплатний день, реліз нової фічі) і раптово latency стрибає в космос. GC-патерни дозволяють швидко зрозуміти: це GC чи щось інше.
Мікросервіс у Kubernetes, який регулярно викидають за OOM, хоча «пам’яті ж наче хватає». Тюнінг heap, metaspace та алокацій часто рятує поди від небуття.
Легасі моноліт, який всі бояться чіпати. GC-тюнінг стає єдиним безпечним способом витиснути ще трохи життя з динозавра.
Високонавантажений batch-процес, який не вкладається у вікно overnight. Після тюнінгу GC і алокацій він раптом закінчується не о 10 ранку, а в 3:40.
Продукт, де менеджери вже нав’язали ідею «переписати все на іншу мову, бо Java повільна». Пара вечорів з GC-логами іноді дешевші, ніж «rewrite всього світу».
Сервіс, який тримає мільйони підключень/сесій. Без нормального патерну роботи з heap та off-heap кешами він або падає, або душить залізо.
Кейси, де треба виконувати обіцянку по SLA, а не щось абстрактне типу «ну воно ж якось працює». GC-патерни дають ті самі цифри, за які потім можна сперечатися з менеджментом.

Чеклист “як вибрати рішення”

Що болить?
– довгі паузи,
– OutOfMemory,
– нестабільне latency,
– «CPU на 100% у java-процесу».
Поки немає чіткої відповіді – не ліземо в флажки.
У нас важливіше latency чи throughput?
– latency критичний: дивимось у патерни мінімізації пауз, G1/ZGC, heap помірний, багато метрик;
– throughput важливіший: Parallel/агресивний G1, великі batch-job в нічний час.
Які GC вже стоять?
– G1GC за замовчуванням: зазвичай тюнимо паузи, heap, young/old, дивимося логи;
– щось екзотичне: спочатку розуміємо, навіщо його взагалі включили.
Чи є GC-логи і метрики?
– ні: включити;
– так: завести хоча б просту дашку з паузами, heap usage, кількістю GC.
Чи є гарячі місця з дикими алокаціями?
– так: спочатку оптимізуємо код (зменшуємо тимчасові об’єкти), потім тюнимо JVM;
– ні: фокусуємось більше на конфігурації GC.
Чи готові ми міняти код?
– ні: працюємо з «м’якими» патернами – heap, покоління, паузи, логи;
– так: додаємо GC-friendly структури, off-heap, ThreadLocal-кеші за розумом.
Наскільки команда розуміє обраний GC?
– нуль: краще залишитися на G1GC і не гратися в ZGC/Shenandoah;
– норм: можна пробувати нові збирачі, але тільки з rollback-планом.
Є rollback-план?
– якщо ні – це не тюнінг, це російська рулетка.
– якщо так – можна пробувати змінювати флаги у невеликому відсотку інстансів і дивитися на метрики.

Жарт

GC-тюнінг в корпорації часто виглядає так:
Менеджер:
«У нас latency підскочило. Зроби щось із Java, але без downtime, без ризиків і бажано до кінця дня».
Розробник:
«Може, вимкнемо три зайві прокладки між сервісами, приберемо логування всіх полів у debug і перестанемо серіалізувати пів бази в кожному запиті?»
Менеджер:
«Ні, це довго. Ти ж там просто флажки покрути. Я вчора статтю читав, там людина параметр міняла – і в неї все полетіло».
А потім, звичайно, GC винен.
Не те, що мікроменеджмент, три рівні абстракції й десять мідлів, які «хотіли як краще» :)

Нормальний підхід: тюнити GC так, щоб коли наступного разу хтось у чаті напише «знов та ваша Java лагає», ти мовчки кидаєш графік з паузами в 5–15 мс і питаєш:
«Ну що, шукаємо проблему далі?»