Vòng đời một class trong JVM: load, link, initialize

TL;DR: Sau khi ClassLoader tìm được file .class, JVM còn xử lý qua ba phase tuần tự: Loading (đọc và parse bytecode, tạo Class object), Linking (verify bytecode → prepare cấp phát static field với giá trị default → resolve symbolic reference), và Initialization (chạy <clinit> — gán static field và chạy static block). Phân biệt được ba phase này cho phép định vị hai lỗi hay nhầm: ClassNotFoundException là checked exception, ném khi code chủ động tìm class theo tên (Class.forName) mà không thấy; NoClassDefFoundError là Error, ném khi JVM cố link/init một class đã compile-time tham chiếu nhưng vắng lúc runtime — hoặc khi static init đã throw một lần khiến class chết vĩnh viễn.

Một bug production kinh điển: log đứng ở

Caused by: java.lang.NoClassDefFoundError: com/google/common/collect/ImmutableList
    at com.myapp.Service.<init>(Service.java:12)

Bạn mở pom.xml — Guava có đủ. Build xanh, test local xanh. Nhưng deploy lên môi trường khác thì NoClassDefFoundError. Vì sao không phải ClassNotFoundException? Hai lỗi này khác nhau ở phase nào trong vòng đời class phát sinh ra chúng — và đó chính là manh mối để debug.

Bài này trace ba phase Loading → Linking → Initialization, rồi dùng chúng để định vị chính xác ClassNotFoundException so với NoClassDefFoundError.

1. Ba phase: Load → Link → Initialize

JVM biến một file .class thành class dùng được qua ba phase tuần tự (JLS §12, JVMS §5):

flowchart LR
    A["1. Loading<br/>doc .class, parse bytecode<br/>tao Class object"] --> B["2. Linking"]
    B --> B1["2a. Verification<br/>bytecode hop le?"]
    B1 --> B2["2b. Preparation<br/>cap static field = default"]
    B2 --> B3["2c. Resolution<br/>symbolic -> direct reference"]
    B3 --> C["3. Initialization<br/>chay clinit: gan static + static block"]
    C --> D["Class san sang dung"]

    style B1 fill:#FCD34D
    style D fill:#6EE7B7

Ba phase này giống một dây chuyền nhà máy biến linh kiện thô thành máy chạy được:

2. Loading — đọc .class và tạo Class object

JVM tìm file .class qua ClassLoader (bài 01), parse bytecode, tạo một Class<?> object trong bộ nhớ. Loading là lazy: JVM không nạp sẵn cả JAR mà chờ tới khi một class thực sự cần. Thời điểm nạp chính xác do JVM quyết định (JVMS §5.3), chậm nhất là ngay trước khi class bị dùng chủ động (active use) — và chính các tình huống active use đó cũng kích hoạt phase Initialization (§4), theo danh sách chuẩn JLS §12.4.1:

• new MyClass() — tạo instance đầu tiên.
• MyClass.staticMethod() — gọi static method.
• MyClass.STATIC_FIELD — đọc hoặc ghi static field non-constant.
• Class.forName("MyClass") — nạp và init tường minh.
• Init subclass → nạp và init superclass trước.

Nhờ lazy, app có 1000 class trong JAR nhưng một lần chạy chỉ chạm 50 thì JVM chỉ xử lý 50 — phần còn lại không tốn gì.

3. Linking — verify, prepare, resolve

Linking gồm ba bước con. Bước Preparation là chỗ hay bị hiểu sai nhất, nên ta dừng lại ở đó.

Verification — kiểm bytecode hợp lệ: stack frame nhất quán, type an toàn, không nhảy lung tung. Đây là lá chắn chống class file độc hại (ví dụ ai đó viết tay bytecode để đọc trộm bộ nhớ).

Preparation — cấp phát bộ nhớ cho static field và set giá trị default theo type (0 cho số, null cho reference, false cho boolean). Chưa chạy bất kỳ assignment nào trong code.

Resolution — chuyển symbolic reference (chuỗi text như "java/lang/String" trong constant pool — bảng hằng số nhúng trong .class, chứa mọi tên class/method/field dạng chuỗi) thành direct reference (con trỏ tới Class object thật). Có thể lazy: JVM trì hoãn resolve tới khi reference được dùng.

Trước khi xem một ví dụ, hãy tự trả lời:

public static int count = 100;
// Sau Preparation: count == ?
// Sau Initialization: count == ?

Sau Preparation, count là 0 — giá trị default của int, vì Preparation chỉ cấp bộ nhớ và set default, chưa chạy assignment. Chỉ sau Initialization, <clinit> mới chạy count = 100. Hai thời điểm này tách biệt là nền để hiểu lỗi circular static reference ở phần tự kiểm tra.

4. Initialization — chạy static initializer (clinit)

Phase cuối chạy <clinit> lần đầu class bị active use (§2) — method do JVM tự sinh, chứa:

• Assignment cho static field (static int count = 100;).
• Nội dung mọi static { ... } block.

<clinit> chạy một lần trên mỗi loader, và thread-safe (JVM giữ lock init). Thứ tự thực thi là thứ tự các câu lệnh xuất hiện trong source:

class Config {
    static final int VERSION = 1;                    // 1
    static String name = loadName();                 // 2
    static { System.out.println("Config init"); }    // 3
    static List<String> tags = new ArrayList<>();    // 4
}

Khi static init ném exception

Nếu <clinit> ném exception, class bị JVM đánh dấu erroneous vĩnh viễn. Điều xảy ra tiếp theo là nguồn của nhiều giờ debug lãng phí — hãy tự đoán trước:

class Bad {
    static int x = 1 / 0;   // static initializer chia cho 0
}

try { int v = Bad.x; } catch (Throwable t) { System.out.println(t); }
// Lan 1: ?

try { int v = Bad.x; } catch (Throwable t) { System.out.println(t); }
// Lan 2: ?

Kết quả hai lần khác nhau:

Lan 1: java.lang.ExceptionInInitializerError
         Caused by: java.lang.ArithmeticException: / by zero
Lan 2: java.lang.NoClassDefFoundError: Could not initialize class Bad

Lần đầu, JVM chạy <clinit>, gặp 1 / 0 ném ArithmeticException, wrap lại thành ExceptionInInitializerError — có cause gốc. Class bị mark erroneous. Lần thứ hai, JVM từ chối init lại một class đã chết, ném thẳng NoClassDefFoundError: Could not initialize class Bad — không kèm cause.

5. ClassNotFoundException khác NoClassDefFoundError chỗ nào?

Hai lỗi anh em, hay bị nhầm. Khác biệt cốt lõi: phát sinh ở phase nào, do ai chủ động tìm.

ClassNotFoundException

Ném khi code chủ động tìm class theo tên (chuỗi string) mà không thấy. Là checked exception — phải catch hoặc declare throws.

try {
    Class<?> c = Class.forName("com.foo.NonExistent");
} catch (ClassNotFoundException e) {
    // JVM chu dong tim theo ten, khong thay
}

Stack trace có Class.forName hoặc loader.loadClass. Nguyên nhân thường gặp: JAR thiếu trong runtime classpath, typo tên class, hoặc nạp qua loader sai.

NoClassDefFoundError

Ném khi JVM cố link hoặc init một class A mà code đã compile-time tham chiếu, nhưng A vắng mặt lúc runtime. Là Error (không phải Exception) — không nên catch.

// Compile-time: Guava co trong classpath -> bien dich OK
ImmutableList<String> list = ImmutableList.of("a");
// Runtime: Guava vang -> new/link that bai -> NoClassDefFoundError

Nguyên nhân thường gặp:

• Compile classpath có JAR, runtime classpath thiếu (Maven scope provided mà môi trường runtime không cung cấp là case kinh điển).
• Class nạp OK nhưng static init throw → class chết → mọi truy cập sau ném NoClassDefFoundError: Could not initialize class... không kèm cause (§4).
• Hai thư viện kéo hai version khác nhau; version được chọn thiếu method version kia cần → NoSuchMethodError (anh em cùng họ).

Phân biệt nhanh

6. Pitfall tổng hợp

❌ Nhầm 1: Catch NoClassDefFoundError để "xử lý cho êm".

try { useGuava(); } catch (NoClassDefFoundError e) { /* nuot loi */ }

✅ Đây là Error, báo hiệu môi trường hỏng (thiếu JAR / class chết). Nuốt nó chỉ giấu bug — fix classpath thay vì catch.

❌ Nhầm 2: Nhồi logic nặng, dễ fail vào static block.

class Config {
    static { Files.readAllBytes(Path.of("/etc/app/config")); }  // fail -> class chet
}

✅ Nếu static init fail, class chết vĩnh viễn và các lần sau chỉ ra NoClassDefFoundError trống. Dùng holder pattern để init lazy và cô lập lỗi:

class Config {
    private static class Holder { static final Config INSTANCE = load(); }
    static Config get() { return Holder.INSTANCE; }
}

7. 📚 Deep Dive Oracle

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

• Bài 01 — ClassLoader hierarchy và parent delegation — phase Loading dùng loader nào là chuyện của bài đó; loader sai là một nguyên nhân ClassNotFoundException.
• Bài 01c — Classloader isolation trong thực tế — NoClassDefFoundError khi deploy vào Tomcat/Spring Boot thường là hệ quả của isolation, không chỉ thiếu JAR.
• Bài 05b — Ngoài heap: metaspace, stack, native — metadata class (klass) sau khi load nằm ở Metaspace; còn Class object (mirror mà Foo.class trả về) là object thường trên heap.

9. Tóm tắt

• JVM xử lý class qua ba phase: Loading (đọc .class), Linking (verify + prepare + resolve), Initialization (chạy <clinit>).
• Lazy loading: class chỉ nạp khi lần đầu thực sự cần.
• Preparation set static field giá trị default; Initialization mới chạy assignment thật — hai thời điểm tách biệt.
• <clinit> chạy một lần trên mỗi loader, thread-safe, theo thứ tự source.
• Static init throw → class erroneous vĩnh viễn: lần 1 ném ExceptionInInitializerError (có cause), lần 2+ ném NoClassDefFoundError (không cause). Tìm log lần đầu để debug.
• ClassNotFoundException: checked exception, code chủ động tìm theo tên mà không thấy.
• NoClassDefFoundError: Error, link/init class compile-time có nhưng runtime vắng — hoặc class đã chết vì static init fail.

10. Tự kiểm tra

Bài tiếp theo: Classloader isolation trong thực tế