Tổng kết module — JVM Internals

Bạn vừa mở nắp JVM từ lúc một class được nạp tới lúc object của nó bị thu dọn. Sợi chỉ xuyên suốt module: mọi triệu chứng production kỳ lạ đều có một cơ chế cụ thể bên dưới — và giờ bạn biết cơ chế đó tên gì, đo bằng tool nào, đọc log ra sao.

Nhìn lại theo bốn cụm

Class loading (01 → 01b → 01c): JVM nạp class qua hierarchy ba tầng Bootstrap → Platform → Application với parent delegation; vòng đời load → link → initialize giải thích vì sao ClassNotFoundException khác NoClassDefFoundError; và identity của class = (loader, tên) là gốc của bug "X cannot be cast to X" trong Tomcat/Spring Boot.

Bytecode và JIT (02 → 03 → 04 → 04b → 04c → 10): class file là cấu trúc đọc được bằng javap; method nóng leo thang interpreter → C1 (~200 lần gọi) → C2 (~5000); C2 thắng lớn nhờ inlining + devirtualization qua inline cache, và đặt cược bằng deoptimization khi profile đổi; escape analysis cho scalar replacement — object không thoát khỏi method thì không cần cấp phát trên heap.

Bộ nhớ và object layout (05 → 05b → 09 → 09b): heap chia thế hệ với Eden cấp phát bump-the-pointer + TLAB; ngoài heap còn metaspace, stack, native — mỗi vùng một chữ ký OOM riêng; mỗi object trả 12–16 byte header (mark word + klass pointer), field được reorder và pad theo align 8; compressed OOP cho heap dưới 32GB dùng reference 4 byte — và 33GB có thể chứa ÍT object hơn 31GB.

GC, safepoint và chẩn đoán (06 → 06b → 12 → 12b → 11 → 07 → 08 → 13): rác định nghĩa bằng reachability từ GC roots; ba thuật toán nền (mark-sweep, mark-copy, mark-compact) phối thành mọi collector; chọn collector theo latency SLA rồi xác nhận bằng -Xlog:gc*; G1 chia heap thành region, dùng SATB và remembered set; ZGC và Shenandoah kéo pause xuống dưới ~10ms bằng read barrier — ZGC qua colored pointer, Shenandoah qua load-reference barrier; nhưng pause thật có thể dài hơn GC log vì time-to-safepoint. Bộ jcmd/jstat/jmap/jstack + JFR là mắt của bạn vào tất cả những thứ trên, và bài 13 gộp chúng lại thành một capstone debug memory leak thật.

Bản đồ chẩn đoán — triệu chứng nào, mở bài nào

flowchart TD
    A["Trieu chung production"] --> B["ClassNotFound / CastException"]
    A --> C["OOM"]
    A --> D["Cham sau deploy / cham dan"]
    A --> E["Pause dai / P99 spike"]
    B --> B1["01b - 01c: vong doi + isolation"]
    C --> C1["05b: chu ky OOM tung vung"]
    D --> D1["04c: warm-up, deopt + JIT log"]
    E --> E1["06b: GC log - 11: safepoint/TTSP"]

✅ Self-assessment

Bạn đã đạt module này nếu tự tin trả lời được từng câu:

• Explain cách JVM nạp class qua hierarchy ba tầng và parent delegation
• Diagnose lỗi classloading trong container: ClassNotFoundException vs NoClassDefFoundError và "X cannot be cast to X"
• Trace cấu trúc class file và bytecode một method bằng javap — từ constant pool tới invokedynamic
• Trace đường biên dịch một method từ interpreter qua C1/C2 cùng các tối ưu inlining, devirtualization, escape analysis
• Diagnose độ trễ sau deploy bằng JIT log — phân biệt deoptimization với warm-up
• Explain bố cục bộ nhớ JVM (heap generational, metaspace, stack, native) và chữ ký lỗi bộ nhớ từng vùng
• Explain object layout (header, mark word, field packing, compressed OOP) để ước lượng footprint object
• Explain nguyên lý GC (reachability, ba thuật toán nền, generational) và cơ chế sâu G1, ZGC, Shenandoah
• Justify lựa chọn GC collector bằng latency SLA và bằng chứng GC log
• Diagnose pause STW dài hơn GC log báo cáo qua safepoint/TTSP và verify bằng JFR + CLI tools

Câu nào còn lấn cấn, mở lại đúng bài: triệu chứng production kiểu OOM/pause/cast-fail có trong bản đồ chẩn đoán phía trên, còn các năng lực Explain/Trace (bytecode, object layout, nguyên lý GC…) thì tra ở phần Nhìn lại theo bốn cụm — mỗi cụm link đủ mọi bài sở hữu năng lực đó.

Học tiếp gì

Module cuối của course — Collections Internals — áp chính các kỹ năng này vào đọc source JDK: ArrayList.grow() 1.5x, HashMap treeify, và một mini-challenge debug P99 spike dùng cả JFR lẫn hiểu biết về object layout bạn vừa có.

Bài tiếp theo: Tổng quan module Collections Internals