Chọn GC collector theo SLA latency và đọc GC log xác nhận

TL;DR: Chọn GC collector không phải chọn "cái tốt nhất" mà là khớp collector với SLA latency + cỡ heap. Batch/offline không có user chờ → Parallel GC (throughput tối đa). Web/microservice pause p99 vài chục tới vài trăm ms chấp nhận được → G1 (default Java 9+, ít phải tune). SLA p99 dưới 10ms hoặc heap vượt 32GB → ZGC / Shenandoah (concurrent compaction, đổi ~10-15% throughput lấy pause dưới 10ms). Sau khi chọn, xác nhận bằng GC log -Xlog:gc*=info: đọc pause type (young/full), reclaim ratio, và pause duration để biết collector có thực sự đạt SLA không. -Xlog:gc* là bằng chứng; đừng tune mù không có nó.

Bạn deploy một service mới, chọn collector theo... mặc định. App chạy ổn tới ngày traffic tăng, p99 latency (ngưỡng mà 99% request nằm dưới) thỉnh thoảng vọt lên 400ms và alert nổ. Câu hỏi không phải "collector nào tốt nhất" — mà collector nào khớp với SLA của service này, và làm sao xác nhận nó đang đạt SLA đó bằng số liệu chứ không phải cảm giác.

Bài 06 cho biết mỗi collector phối ba thuật toán nền khác nhau. Học xong bài này, bạn chọn được collector khớp SLA của service và đọc GC log để xác nhận lựa chọn bằng số liệu.

1. Bốn collector, một trục quyết định

Bài 06 liệt kê collector theo tên. Để chọn, xếp chúng theo hai trục thực dụng: pause profile (ảnh hưởng latency) và throughput (ảnh hưởng chi phí máy).

Hình dung như chọn phương tiện chở hàng theo tuyến (yêu cầu latency) và khối lượng (throughput cần):

Bảng kỹ thuật đầy đủ cho từng collector:

Java 21 mặc định G1. -XX:MaxGCPauseMillis=200 là soft target mặc định của G1 — nó cố giữ pause dưới 200ms bằng heuristic chọn số region quét mỗi cycle, không phải cam kết tuyệt đối.

2. Nên chọn collector nào cho SLA của service?

Với p99 = 5ms, mọi collector stop-the-world (Parallel, và cả G1 với pause 50-200ms) đều loại ngay — một pause 50ms đã xài hết 10 lần budget. Chỉ ZGC hoặc Shenandoah (pause dưới 10ms) đạt. Heap 12GB không bắt buộc ZGC vì cỡ này, nhưng ràng buộc latency thì có. Đáp án: ZGC (production từ JDK 15; trên Java 21 bật chế độ generational bằng -XX:+ZGenerational — generational thành mặc định từ JDK 23, xem bài 12b).

Đây là toàn bộ cây quyết định:

flowchart TD
    A["Workload + SLA"] --> B{"Co user cho request?"}
    B -->|"Khong (batch, ETL)"| C["Parallel GC"]
    B -->|"Co"| D{"SLA p99 latency?"}
    D -->|"Vai chuc - vai tram ms OK"| E["G1 (default)"]
    D -->|"Duoi 10ms bat buoc"| F["ZGC / Shenandoah"]
    E --> G{"Heap vuot 32GB?"}
    G -->|"Co"| F
    G -->|"Khong"| H["G1 giu nguyen"]

Nhánh cuối: ngay cả khi SLA rộng, heap vượt 32GB vẫn nên cân nhắc ZGC. Lý do chính là Full GC của G1 (fallback compacting toàn heap) có pause leo theo cỡ heap — càng nhiều region càng lâu — trong khi ZGC giữ pause phẳng bất kể heap. Pause young và mixed của G1 thì đều được adaptive-sizing ghìm quanh MaxGCPauseMillis bất kể heap (điểm §1); chỉ Full GC mới thực sự scale theo cỡ heap. Một điểm phụ: qua mốc ~32GB thì mọi collector đều mất compressed oops (reference thành 64-bit), nên việc ZGC vốn dùng 64-bit colored pointer (không bao giờ có compressed oops) không còn là bất lợi footprint riêng ở cỡ heap này.

3. Đọc GC log — xác nhận bằng số liệu

Chọn xong phải verify. Bật unified GC log (định dạng chuẩn từ Java 9):

java -Xlog:gc*=info:file=gc.log:time,uptime,level,tags MyApp

Một dòng pause young của G1 trông như sau:

[2026-04-27T10:00:00.145+0700][1.256s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 192M->24M(256M) 22.345ms

Bóc từng trường:

• GC(0) — ID của cycle.
• Pause Young (Normal) — minor GC (chỉ quét young). Nếu là Pause Full thì mới là major/full GC.
• 192M->24M(256M) — heap dùng trước → sau (tổng heap). Reclaim 168MB.
• 22.345ms — thời gian pause.

Phân tích sức khoẻ:

• Reclaim ratio = 168/192 ≈ 87% → phần lớn là rác, generational hypothesis (giả thuyết hầu hết object chết trẻ — bài 06) đang đúng.
• Utilization sau GC = 24/256 ≈ 9% → heap dư thoải mái, chưa áp lực.
• Pause 22ms → khoẻ với web service (SLA p99 50-200ms).

3.1. Pattern khoẻ vs pattern nguy

Một dòng đơn lẻ không đủ — nhìn xu hướng qua nhiều cycle:

# KHOE: heap-after on dinh, reclaim cao, pause on dinh
GC(1) 192M->24M(256M) 20ms
GC(2) 195M->26M(256M) 22ms
GC(3) 198M->25M(256M) 21ms

# NGUY: heap-after tang dan, reclaim giam, pause phinh -> leak
GC(1) 192M->180M(256M) 50ms
GC(2) 250M->240M(256M) 80ms
GC(3) 256M->255M(256M) 200ms (Pause Full)

Ở pattern nguy, after không giảm nghĩa là object già không chết — old gen phình dần, Full GC dày lên rồi tiến tới OutOfMemoryError. Đây là chữ ký memory leak đọc thẳng từ GC log.

4. KPI cần monitor

Không đọc log bằng mắt trong production — ship vào tool và set alert trên bốn KPI:

• Pause p99 — cao nhất 99% events, phải khớp SLA. Vượt SLA = đổi collector hoặc tune.
• Throughput % — phần trăm thời gian app chạy (ngoài GC). Tốt khi vượt 95%.
• Full GC frequency — vượt 1 lần/giờ là red flag: heap quá nhỏ hoặc leak.
• Allocation rate — byte alloc/giây; tăng đột biến = pressure tăng, nguồn của promote sớm (bài 06).

Tool đọc log: GCEasy (paste log → report), GCViewer (timeline desktop), hoặc JFR (event GC kèm cause + region count — xem bài 08).

5. Pitfall tổng hợp

❌ Nhầm 1: Chọn ZGC cho heap nhỏ "cho hiện đại".

java -XX:+UseZGC -Xmx1g MyApp   # overhead ~10-15% khong bu lai duoc voi heap nho

✅ Heap dưới 2GB dùng Serial hoặc G1 — GC cycle vốn đã nhanh, overhead ZGC không đáng.

❌ Nhầm 2: Dùng Parallel cho web service vì "throughput cao".

Parallel full GC 10GB heap -> pause vai giay -> user thay lag intermittent

✅ Web có user chờ → G1 (hoặc ZGC nếu p99 gắt). Parallel dành cho batch không ai chờ.

❌ Nhầm 3: Tune hàng loạt flag mà không đọc log.

-XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=8m -XX:...   # doan mo

✅ Đo trước bằng -Xlog:gc*, xác định bottleneck (pause? frequency? promote rate?), rồi tune một biến một.

6. 📚 Deep Dive Oracle

7. Liên hệ các bài khác

• GC — reachability và ba thuật toán nền — vì sao mỗi collector có pause profile riêng (cách phối mark/copy/compact + concurrent tới đâu).
• GC modern — G1 sâu — khi chọn G1, mổ region/SATB/mixed GC và các flag tune Full GC.
• ZGC và Shenandoah — khi SLA ép dưới 10ms, cơ chế concurrent compaction và trade-off throughput.
• JFR và profiling — capture GC event chi tiết (cause, allocation rate) để correlate với latency spike.

8. Tóm tắt

• Chọn collector = khớp SLA latency + cỡ heap: batch → Parallel; web pause vài chục-vài trăm ms → G1 (default); p99 dưới 10ms hoặc heap vượt 32GB → ZGC/Shenandoah.
• -XX:MaxGCPauseMillis=200 là soft target mặc định của G1 — heuristic, không cam kết tuyệt đối.
• ZGC/Shenandoah đổi ~10-15% throughput lấy pause dưới 10ms → chỉ chọn khi latency là ràng buộc thật; heap nhỏ dùng chúng là lãng phí.
• Bật -Xlog:gc*=info:file=gc.log để verify: đọc pause type, reclaim ratio (before->after), pause duration.
• Đọc xu hướng qua nhiều cycle: heap-after ổn định + reclaim cao + pause ổn định = khoẻ; heap-after tăng dần = leak.
• Monitor 4 KPI: pause p99, throughput %, Full GC frequency (hơn 1 lần/giờ = red flag), allocation rate. Ship log vào GCEasy/GCViewer/JFR.
• Tune từng biến một sau khi đọc log, không đoán mò — mọi quyết định đổi collector hay chỉnh flag phải bắt đầu từ log thực.

9. Tự kiểm tra

Bài tiếp theo: CLI tools — jps, jstack, jmap, jstat và jcmd