Garbage Collection — G1, ZGC, Parallel và cách chọn

GC là feature lớn nhất phân biệt Java với C/C++. Bạn không bao giờ gọi free(obj) — JVM tự reclaim memory khi object không còn reference. Đổi lại, JVM phải scan heap thường xuyên để biết cái nào còn dùng, cái nào dead.

Cost không miễn phí: trong service throughput thấp, GC pause vài chục ms thi thoảng vô hại. Trong service latency-sensitive (trading platform 1ms p99, real-time bidding 50ms p99), GC pause 200ms có thể trigger SLA breach. Lựa chọn collector sai → user thấy lag, alert nổ.

JVM cung cấp 3 collector chính (Java 21):

• Parallel GC: tối ưu throughput, pause dài chấp nhận được. Default Java 8 server.
• G1 GC: balanced, default Java 9+ server. Pause ~50-200ms.
• ZGC: low-latency, pause dưới 10ms (thường dưới 1ms), heap đến 16TB.

Bài này đi qua: generational hypothesis (vì sao chia young/old), 3 algorithm cốt lõi (mark-sweep, copying, compacting), chi tiết 3 collector (cách hoạt động, pause profile, khi dùng), đọc GC log, và pattern chọn collector theo workload.

1. Analogy — Dọn nhà 3 cách

Bạn có căn nhà chứa đồ đạc — vật cũ vứt đi, vật mới giữ.

Parallel GC = thuê 8 người dọn cùng lúc: nhanh hoàn thành (throughput cao), nhưng cả nhà đóng cửa 30 phút lúc dọn, không ai vào ra được. Phù hợp dọn theo lịch (đêm khuya).

G1 = chia nhà thành 50 phòng nhỏ, dọn xoay vòng từng phòng: mỗi lần đóng 1 phòng 5 phút, ai đi qua đi lại vẫn dùng phòng khác. Tổng dọn lâu hơn, nhưng "không bao giờ đóng cả nhà". Phù hợp nhà đông người ra vào.

ZGC = mỗi món đồ có nhãn màu, mọi việc dọn diễn ra đồng thời với người đang ở: thậm chí khi 1 nhân viên đang nhặt món lên kiểm, người khác có thể tiếp tục dùng tay. Không bao giờ "đóng phòng". Phức tạp nhưng latency cực thấp.

2. Reachability — định nghĩa "rác"

Object là rác khi không có reference nào dẫn từ GC root đến nó.

GC root:

• Static field của loaded class.
• Local variable trên stack mọi thread.
• JNI reference.
• Active thread object.

Algorithm "reachability": từ root, traverse graph reference. Object visit được = live. Không visit = dead, có thể reclaim.

Stack/Static (GC root)
   |
   v
[A] -> [B] -> [C]
        \
         [D] -> [E]

[F] -> [G]   (khong tu root toi -> rac, du F va G ref nhau)

Không phải reference count (như Python) — Java dùng reachability để xử lý cycle. F ↔ G ref lẫn nhau (refcount > 0) nhưng không reachable từ root → vẫn là rác. Reference counting fail vì cycle.

3. 3 algorithm cốt lõi

Mark-Sweep

flowchart LR
    A[1. Mark<br/>Traverse from root<br/>mark live object] --> B[2. Sweep<br/>Iterate heap<br/>free unmarked]

Mark: BFS/DFS từ root, mark mỗi object visit-được. Sweep: scan toàn heap linear, free object không mark.

Đơn giản. Vấn đề: fragmentation — object dead nằm rải rác → free space rời rạc → không alloc được object lớn dù tổng free đủ.

Copying (Cheney's algorithm)

flowchart LR
    A[Heap chia 2 nua: From + To] --> B[Copy live tu From sang To]
    B --> C[From cleared - rac di theo]
    C --> D[Swap From/To role]

Heap chia 2 nửa From + To. Alloc trong From. GC: copy mọi live object từ From → To, gom contiguous. From clear hoàn toàn (không cần sweep từng object — clear cả region 1 lần). Swap role.

Ưu: no fragmentation, allocation nhanh (bump pointer trong To). Nhược: dùng nửa heap — waste space. Phù hợp young gen (object chết nhiều, copy ít).

Mark-Sweep-Compact

flowchart LR
    A[1. Mark] --> B[2. Compact<br/>shift live object<br/>about beginning of region]

Mark như mark-sweep. Sau đó compact: shift mọi live object về đầu region → free space contiguous.

Ưu: no fragmentation. Nhược: cost shift object (cập nhật mọi reference đến object đã shift).

Old gen thường dùng mark-sweep-compact — object già không di chuyển nhiều, compact ít thường xuyên.

4. Generational hypothesis — chia young/old

Profile thực tế: 90-95% object chết trẻ (alloc xong dùng vài microsecond rồi không reference). 5-10% sống lâu (cache, singleton, long-lived state).

Tách heap thành 2 region với strategy khác:

• Young: GC thường xuyên (vài giây), copy algorithm (rẻ vì ít object live).
• Old: GC ít thường xuyên (vài phút), mark-sweep-compact.

Heap layout:
+-----------+-----------------------------+
|  Young    |          Old                |
| (30%)     |          (70%)              |
+-----------+-----------------------------+
| Eden | S0 | S1 |     Tenured             |
+-----------+-----------------------------+

Minor GC vs Major (Full) GC

Minor GC: scan young, copy live sang Survivor, promote object già sang Old. Nhanh (vài ms cho young 1GB) — vì 90% Eden là rác, copy ít.

Major / Full GC: scan toàn heap (young + old). Chậm hơn nhiều (hàng trăm ms cho heap 10GB). Trigger khi:

• Old đầy (object promote từ young không có chỗ).
• System.gc() (don't call).
• Metaspace đầy (full GC để unload class loader).

Production tip: monitor major GC frequency. > 1 major GC/giờ là red flag — heap quá nhỏ hoặc leak.

Tenuring

Object survive bao nhiêu round minor GC trước khi promote sang Old? Default ~15 (-XX:MaxTenuringThreshold=15).

Object age tăng mỗi minor GC. Đạt threshold → next GC promote sang Old.

Adaptive: nếu Survivor đầy → JVM hạ threshold → promote sớm để giải phóng young. -XX:+PrintTenuringDistribution show distribution thực tế.

5. Parallel GC

Default Java 8 server, deprecated dần Java 9+.

Cơ chế: nhiều thread (thường = #core) làm GC parallel. Algorithm:

• Young: copying (Eden + 2 Survivor).
• Old: mark-sweep-compact.
• Stop-the-world trong toàn bộ GC — app pause.

Pause time:

• Minor GC: vài chục ms (1GB young).
• Full GC: vài trăm ms đến giây (10GB heap) → vài giây (50GB heap).

Ưu:

• Throughput cao nhất: ít overhead, scale theo CPU.
• Đơn giản, predictable.

Nhược:

• Pause dài, không phù hợp latency-sensitive.
• Heap > 10GB pause time leo cao.

java -XX:+UseParallelGC -Xmx4g MyApp

Khi dùng:

• Batch job, ETL, scientific compute — không user request, throughput là tất cả.
• Heap nhỏ (< 4GB), latency không quan trọng.

6. G1 GC

Default Java 9+ server. Mainstream production choice 2017-nay.

Cơ chế: chia heap thành ~2048 region đều nhau (1MB-32MB tùy heap size). Mỗi region label là Eden, Survivor, Old, hoặc Humongous (object > 50% region size). Region không cố định — có thể đổi role qua time.

+------+------+------+------+------+------+------+
| Eden | Old  | Old  | Eden | Surv | Old  | Eden |
+------+------+------+------+------+------+------+
| Eden | Hum  | Old  | Old  | Eden | Surv | Old  |
+------+------+------+------+------+------+------+

Cycle G1

1. Young GC: scan Eden + Survivor regions. Stop-the-world. Copy live sang Survivor / Old. Pause ~10-50ms.
2. Concurrent marking: chạy đồng thời với app thread, mark live object trong Old. Không pause.
3. Mixed GC: Young + một số Old region được "best to collect" (chọn region có nhiều rác nhất → "garbage first"). Pause ~50-200ms.
4. Full GC (last resort): nếu mixed GC không kịp → fall back full GC. Pause hàng giây — bug.

Pause goal

java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Xmx8g MyApp

-XX:MaxGCPauseMillis=200 (default): G1 cố giữ pause ≤ 200ms. Soft target — G1 dùng heuristic chọn số region scan mỗi cycle để fit. Không guarantee absolute.

Set 50-100ms cho web service. Set 500ms-1s cho throughput-oriented.

Khi dùng G1

• Heap 4-32GB.
• Web service, microservice — pause 50-200ms acceptable.
• App có mixed workload (some throughput, some latency).
• Default cho hầu hết production app.

Tune G1

• -XX:G1HeapRegionSize=16m — region size, default tự compute.
• -XX:InitiatingHeapOccupancyPercent=45 — start concurrent marking khi old đạt 45% (default). Set thấp nếu thấy mixed GC không kịp.
• -XX:G1MixedGCCountTarget=8 — số mixed GC cycle để dọn Old (default 8).

Tune G1 phức tạp — đo trước, tune sau. Default thường đủ.

7. ZGC — low-latency

Production-ready Java 15+. Default Java 21+ cho heap lớn.

Mục tiêu: pause dưới 10ms, thường dưới 1ms, không scale theo heap size. Heap 16TB pause vẫn dưới 10ms.

Cơ chế cốt lõi: colored pointer + load barrier

ZGC dùng colored pointer — bit metadata trong reference (con trỏ object).

64-bit reference layout (Linux):
[unused: 17 bit][marked0: 1][marked1: 1][remapped: 1][finalizable: 1][address: 44 bit]

4 bit metadata trong pointer biểu thị state object trong GC cycle (đã mark? đã relocate?).

Load barrier: mỗi lần đọc reference, JVM check color bit. Nếu state cần update (vd object đã relocate, pointer cũ trỏ chỗ cũ) → JVM trigger fixup trong load barrier — update pointer atomic, rồi return.

Hệ quả: GC có thể relocate object đồng thời với app đang chạy. App đọc pointer cũ → load barrier silently update → app thấy pointer mới. Không cần stop-the-world.

Phase ZGC

flowchart LR
    A[Pause: Mark Start] --> B[Concurrent Mark]
    B --> C[Pause: Mark End]
    C --> D[Concurrent Reference Processing]
    D --> E[Concurrent Relocate]
    E --> F[End cycle]

Pause chỉ ở 2 điểm: mark start (~1ms) và mark end (~1ms). Mọi work thực (mark, relocate) concurrent với app.

Trade-off

Ưu:

• Pause cực ngắn: < 10ms thường < 1ms, không phụ thuộc heap size. Heap 1TB pause = pause heap 1GB.
• Heap lớn: hỗ trợ đến 16TB.
• Ít cần tune: heuristic tự thích nghi.

Nhược:

• Throughput thấp hơn G1 ~5-10%: load barrier check mọi reference đọc, overhead.
• CPU usage cao hơn: GC concurrent thread chạy song song với app, ăn CPU.
• Memory overhead 5-10%: cần extra space cho relocate.

java -XX:+UseZGC -Xmx16g MyApp

Java 21+: ZGC mặc định generational (-XX:+ZGenerational) — kết hợp benefit generational vào ZGC. Phiên bản cũ ZGC chỉ có "old" — fail short-lived garbage hiệu quả hơn G1 dù pause ngắn.

Khi dùng ZGC

• SLA latency p99 < 10ms — trading platform, real-time bidding, gaming server.
• Heap rất lớn (> 32GB) — pause G1 leo cao.
• Long-running service — throughput thấp 5% chấp nhận đổi pause ngắn.

Không dùng:

• Batch / throughput-oriented — Parallel hoặc G1 throughput cao hơn.
• Heap nhỏ (< 4GB) + đơn giản — overhead không bù lại.

8. Đọc GC log

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

Format Java 9+ unified log. Output mẫu (G1):

[2026-04-27T10:00:00.123+0700][1.234s][info][gc,start    ] GC(0) Pause Young (Normal) (G1 Evacuation Pause)
[2026-04-27T10:00:00.145+0700][1.256s][info][gc,heap     ] GC(0) Eden regions: 24->0(25)
[2026-04-27T10:00:00.145+0700][1.256s][info][gc,heap     ] GC(0) Survivor regions: 0->3(3)
[2026-04-27T10:00:00.145+0700][1.256s][info][gc,heap     ] GC(0) Old regions: 0->0
[2026-04-27T10:00:00.145+0700][1.256s][info][gc          ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 192M->24M(256M) 22.345ms

Đọc:

• GC(0): ID cycle.
• Pause Young (Normal): minor GC (young).
• Eden regions: 24->0(25): trước GC 24 region, sau 0 (clean), max 25.
• 192M->24M(256M): heap before → after (total). Reclaim 168MB.
• 22.345ms: pause duration.

Pattern cần để ý

• Throughput: % time app run vs GC. Tốt > 95%.
• Pause time p99: cao nhất 99% events. Match SLA.
• Frequency: minor GC mỗi 5-30s OK, mỗi giây = pressure cao.
• Promote rate: object promoted Old per second. Cao = old fill nhanh = full GC sớm.
• Allocation rate: byte alloc / second. Tăng → pressure tăng.

Tool phân tích

• GCEasy (web): paste log → report tự động.
• GCViewer (desktop): visualize timeline.
• JFR: capture GC event với detail (cause, region count, allocation rate).

9. Cách chọn collector

Default Java 21: G1. Đổi qua flag -XX:+UseZGC, -XX:+UseParallelGC, -XX:+UseSerialGC.

Flowchart quyết định

flowchart TD
    A[App workload] --> B{Latency SLA?}
    B -->|p99 < 10ms| C[ZGC]
    B -->|p99 50-200ms| D{Heap size?}
    B -->|p99 > 500ms| E[Parallel GC]
    D -->|< 32GB| F[G1 GC default]
    D -->|>= 32GB| C

Common mistakes

• Set -Xmx quá thấp: GC chạy liên tục, "GC overhead limit exceeded".
• -Xms != -Xmx: server long-running nên equal — predictable, no resize.
• Tune nhiều flag không đo: default thường tốt, đo trước khi tune.
• Ignore pause time: dùng Parallel cho web service → user complaint lag intermittent.
• Dùng ZGC cho heap nhỏ: overhead không bù được, dùng G1.

10. Pitfall tổng hợp

❌ Nhầm 1: Gọi System.gc() để "force clean".

System.gc();   // Hint - JVM co the ignore
// Voi G1: trigger full GC -> pause dai

✅ Đừng gọi. Tin GC heuristic. Disable bằng -XX:+DisableExplicitGC.

❌ Nhầm 2: Tin "GC tuning sẽ fix mọi performance".

Allocation rate cao -> tune GC khong giai quyet, refactor giam alloc.

✅ Profile alloc trước. Cắt alloc thừa hiệu quả hơn tune GC.

❌ Nhầm 3: Heap khổng lồ "an toàn".

-Xmx100g   # Pause Parallel/G1 leo cao

✅ Heap lớn dùng ZGC, hoặc shard logic vào nhiều JVM nhỏ.

❌ Nhầm 4: Catch GC log không monitor.

-Xlog:gc*  -> log file 100MB/ngay khong ai doc

✅ Ship log vào tool (Datadog, New Relic), set alert pause > N ms.

❌ Nhầm 5: Long-lived weak/soft reference cache không design.

Map<K, SoftReference<V>> cache = ...;
// SoftRef chi free khi sap OOM -> heap luon gan full -> GC chay lien tuc

✅ Dùng Caffeine/Guava cache với explicit eviction.

❌ Nhầm 6: Container không pass JVM flag.

docker run myapp java MyApp   # Default JVM detect 256MB, dung Serial GC

✅ Container Java 11+ tự nhận cgroup limit. Java 8 cần -XX:+UseContainerSupport. Set -Xmx explicit để control.

11. 📚 Deep Dive Oracle

12. Tóm tắt

• GC reclaim object unreachable từ GC root (static field, stack local, JNI ref, active thread). Reachability không phải refcount — handle cycle.
• 3 algorithm cốt lõi: mark-sweep (đơn giản, fragmentation), copying (no frag, dùng nửa heap), mark-sweep-compact (no frag, cost shift).
• Generational hypothesis: 90-95% object chết trẻ → tách young (copying, GC thường) + old (mark-compact, GC ít).
• Minor GC: scan young, fast (vài ms). Major / Full GC: scan toàn heap, chậm.
• Tenuring: object survive ~15 minor GC → promote Old. Adaptive nếu Survivor đầy.
• Parallel GC: throughput max, pause dài, batch / throughput workload. Default Java 8.
• G1 GC: chia heap thành region, "garbage first" — chọn region nhiều rác. Default Java 9+, pause 50-200ms typical.
• ZGC: colored pointer + load barrier, GC concurrent. Pause <10ms thường <1ms, không scale heap. Java 15+ production. Java 21+ generational.
• Chọn collector theo SLA latency: > 200ms → Parallel; 50-200ms → G1; <10ms → ZGC.
• Heap > 32GB: nên ZGC (G1 pause leo cao).
• -Xms = -Xmx cho server long-running. -XX:MaxGCPauseMillis=200 G1 soft target.
• Đọc GC log với -Xlog:gc*=info:file=gc.log. Tool: GCEasy, GCViewer, JFR.
• KPI monitor: pause time p99, throughput %, frequency, promote rate, allocation rate.
• Tránh: System.gc(), heap khổng lồ với Parallel/G1, soft/weak reference cache không bound.
• Container: Java 11+ tự nhận cgroup. Vẫn nên set -Xmx explicit cho predictable.

13. Tự kiểm tra

class Node { Node next; }
Node a = new Node();
Node b = new Node();
a.next = b;
b.next = a;
a = null; b = null;
// Refcount a, b van la 1 (do tu ref nhau) -> leak voi refcount
// Reachability: tu root khong toi a, b -> rac, free

GC 1: 192M->180M(256M) 50ms
GC 2: 250M->240M(256M) 80ms
GC 3: 256M->255M(256M) 200ms
GC 4: 256M->256M(256M) 500ms (Full GC)
OutOfMemoryError

GC 1: 192M->24M(256M) 20ms
GC 2: 195M->26M(256M) 22ms
GC 3: 198M->25M(256M) 21ms
...

# Set heap explicit (60-70% container memory)
JAVA_OPTS="-Xms2g -Xmx2g"

# Cho container 4GB:
docker run -m 4g -e JAVA_OPTS myapp java $JAVA_OPTS MyApp

# Hoac qua flag JVM:
java -XX:MaxRAMPercentage=70 MyApp   # Heap 70% container RAM

Bài tiếp theo: JVM tools — jstack, jmap, jstat, JFR