Class Loading & Linking
Before a class's code can run, the JVM takes it through loading, linking (verification, preparation, resolution), and initialization — a well-defined pipeline with well-defined triggers.
A .class file does not become runnable the instant the JVM sees it. The JVM takes each class through a defined life cycle — loading its bytecode, linking it (verifying, preparing, resolving), and finally initializing its static state — and the Java Language Specification pins down exactly when initialization must happen, even though loading/linking timing details are more implementation-flexible.
The Class Life Cycle Overview
Per the JLS/JVM Specification, a class or interface goes through: Loading (finding its bytecode and creating a Class object for it), Linking — which itself has three sub-phases, Verification, Preparation, and Resolution — and finally Initialization (running static initializers and static field assignments).
Loading -> Linking (Verification -> Preparation -> Resolution) -> Initialization
|
(then: instantiation/use)Loading
Loading is the process of finding a class's binary representation (typically a .class file, but it could come from a JAR, over a network, or be generated dynamically) and constructing the in-memory Class object that represents it. This is performed by a ClassLoader. The JVM ships a bootstrap loader for core platform classes, and typically an application/system class loader for user code; frameworks may add custom loaders.
Delegation: standard class loaders normally ask their parent loader to try loading a class first, only loading it themselves if the parent can't find it — this parent-delegation model helps prevent user code from silently shadowing core JDK classes. Exact class loader hierarchies are JVM/runtime-dependent (module-aware since Java 9's platform/application loader split).
Linking — Verification
Verification checks that the loaded bytecode is structurally valid and obeys the JVM's safety rules — correct constant pool references, no illegal type casts the verifier can detect, stack map consistency, no jumping into the middle of another method's bytecode, and so on. This step exists because bytecode can come from anywhere (not just javac), so the JVM cannot simply trust it.
If verification fails, the JVM throws a VerifyError (or a related linkage error) rather than running unsafe bytecode. In everyday development with javac-produced classes this almost never happens, but it can surface with hand-crafted or corrupted bytecode, or mismatched compiler/runtime versions.
Linking — Preparation
Preparation allocates storage for the class's static fields and sets them to their default values (0, false, null, and so on for the field's type) — it does not run any initializer expressions yet. This is why, structurally, every static field logically has a zero-like value before initialization proper occurs.
class Config {
static int retries = 5; // preparation: retries = 0; initialization: retries = 5
static String name = "svc"; // preparation: name = null; initialization: name = "svc"
}Linking — Resolution
Resolution replaces symbolic references in the constant pool (names of classes, methods, fields the class refers to) with direct references, by locating the actual referenced classes/members — loading them if necessary. The JVM Specification permits resolution to happen eagerly at link time, or lazily on first actual use of a specific reference; HotSpot typically resolves lazily, on demand.
Because resolution can be lazy, referring to a class that does not exist in code that never actually executes will not necessarily fail — the failure (e.g. NoClassDefFoundError) can surface only when that reference is actually resolved at runtime.
Initialization
Initialization runs a class's static initializer blocks and static field initializer expressions, in textual (top-to-bottom) source order, exactly once per class per class loader. This is the phase where static { ... } blocks execute and static fields get their real assigned values.
class Counter {
static int base = compute(); // runs first, in source order
static { base += 10; } // runs second
static int compute() {
System.out.println("computing base");
return 100;
}
}
public class Main {
public static void main(String[] args) {
System.out.println(Counter.base); // triggers initialization: prints "computing base", then 110
}
}Initialization Triggers
The JLS specifies a precise, limited set of actions that trigger class initialization (if not already initialized): creating an instance with new, invoking a static method of the class, using or assigning a static field of the class (except a compile-time static final constant, which is inlined and does not trigger initialization), reflectively initializing it, initializing a subclass (which first initializes its superclass), and being a program's designated main class.
class Holder {
static final int CONST = 42; // compile-time constant: does NOT trigger init
static int computed = expensive(); // NOT compile-time constant: DOES trigger init
static int expensive() {
System.out.println("Holder initialized");
return 99;
}
}
// Using Holder.CONST alone never prints "Holder initialized" -
// the compiler inlines the literal 42 at the use site.
// Using Holder.computed DOES trigger initialization.Class Initialization Order Between Related Classes
Initializing a class first initializes its direct superclass (if not already initialized), recursively up to Object. Interfaces are only initialized when needed for a similar set of triggers, and notably — unlike superclasses — a class does NOT automatically initialize the interfaces it implements just because the class itself initializes, unless those interfaces declare default methods being invoked or have their own static state accessed.
class Animal {
static { System.out.println("Animal init"); }
}
class Dog extends Animal {
static { System.out.println("Dog init"); }
}
public class Main {
public static void main(String[] args) {
new Dog(); // prints: Animal init, then Dog init
}
}Thread Safety of Initialization
The JVM guarantees that class initialization is thread-safe and happens at most once: if multiple threads trigger initialization of the same class concurrently, exactly one thread runs the static initializer while the others block until it completes. This is the mechanism behind the classic thread-safe lazy-singleton-via-static-holder-class idiom.
class Singleton {
private Singleton() {}
private static class Holder {
static final Singleton INSTANCE = new Singleton();
}
static Singleton getInstance() {
return Holder.INSTANCE; // Holder only initializes (and is thread-safe) on first access
}
}Linkage Errors and Edge Cases
If a static initializer throws an unhandled exception, the JVM wraps it in an ExceptionInInitializerError and marks the class permanently erroneous — any later attempt to use that class throws NoClassDefFoundError, even though the class was technically loaded. Referencing an incompatible or missing class at resolution time throws NoClassDefFoundError or subclasses of LinkageError such as IncompatibleClassChangeError.
A recursive/circular initialization dependency (class A's static initializer, directly or indirectly, triggers initialization of class B, which triggers A again) does not deadlock or infinite-loop — the JVM detects that the current thread is already initializing that class and simply proceeds, potentially observing partially-initialized static state.
Practical Usage
Understanding this pipeline explains real debugging situations: why a static field's default (zero-like) value can briefly be observed, why heavy work in a static initializer delays first use of a class, why NoClassDefFoundError can appear far from where a class was actually referenced in source, and why static-holder-class lazy initialization is both simple and safe.
Mental Model
Think of a class like a shipped product going through customs, then a warehouse setup crew, then a grand opening. Loading is customs clearance (the bytes arrive and get logged). Linking is the warehouse crew: verification checks nothing is broken or unsafe, preparation puts empty shelving in place (default zero values), resolution hooks up references to other warehouses as needed. Initialization is the grand opening — the static initializer code runs, once, filling the shelves with real values — triggered the first time a customer (some code) actually needs to walk in the door.
Quick Reference
Loading : bytecode -> Class object (via a ClassLoader)
Verification : bytecode safety/structure checks
Preparation : static fields get default (zero-like) values
Resolution : symbolic refs -> direct refs (can be lazy)
Initialization: static initializers/field expressions run, in source order, once
Triggers: new, static method call, non-constant static field access/assign,
reflective init, subclass init (superclass first), designated main class
NOT a trigger: reading a compile-time static final constantKey Takeaways
A class goes through loading, then linking (verification, preparation, resolution), then initialization — a defined life cycle, not a single atomic step.
Preparation zeroes static fields; initialization runs actual initializer code, in source order, exactly once.
The JLS specifies exact initialization triggers (new, static method/field access, reflection, subclass init) — reading a compile-time constant is a notable exception.
Initializing a class always initializes its superclass first; interface initialization follows separate, narrower rules.
Class initialization is guaranteed thread-safe and exactly-once, which is why static-holder-class lazy singletons work correctly under concurrency.
// Assuming Holder.CONST triggers Holder's static initializer to run System.out.println(Holder.CONST); // CONST is a compile-time static final constant
// Compile-time constants are inlined by the compiler at the use site; // only non-constant static state access triggers initialization. System.out.println(Holder.computed); // this DOES trigger initialization
A static final field initialized with a compile-time constant expression is inlined by the compiler wherever it's referenced, so referencing it alone does not load/initialize the declaring class.
class Config { static int value; // relies on 'default' value being meaningful } // reading Config.value before any initializer assigns it meaningfully class Config { static int value = loadFromEnvironment(); // explicit initializer } // Config.value is guaranteed fully initialized on first legitimate access // because Java class initialization runs before first use.
Relying on a static field's zero-like default (from preparation) as if it were meaningful application state is a design mistake — express intended defaults explicitly.
// Assuming a NoClassDefFoundError always points at the exact class you're missing catch (NoClassDefFoundError e) { /* ignore, must be a typo in my class name */ }
// NoClassDefFoundError can also mean: the class failed to initialize earlier // (ExceptionInInitializerError) and the JVM now refuses to use it again - // check for an earlier ExceptionInInitializerError in the logs.
A class whose static initializer threw is marked erroneous; every subsequent attempt to use it throws NoClassDefFoundError even though the class file is present and was loaded correctly the first time.
List the four phases of the class life cycle in order, and name the three sub-phases of linking.
Loading, Linking, Initialization (with a fourth informal stage: use, then eventually unloading). Linking consists of Verification, Preparation, and Resolution, in that logical order (though resolution can be deferred).
What value does a static int field have immediately after preparation but before initialization runs?
Its type's default zero-like value — 0 for int, false for boolean, null for reference types — regardless of any initializer expression in source, because initializer expressions only run during initialization.
Name at least four distinct actions that trigger a class's initialization, and one that does not.
Triggers: creating an instance with new; invoking a static method; reading or writing a non-constant static field; reflective initialization; initializing a subclass (initializes the superclass first); being the program's main class. Not a trigger: reading a compile-time static final constant, since the compiler inlines it.
Why is the static-holder-class idiom for lazy singleton initialization thread-safe without any explicit synchronization?
Because the JVM itself guarantees class initialization is atomic and happens at most once per class per class loader, even under concurrent access — the holder class is only initialized on first access to getInstance(), and the JVM serializes that initialization across threads.
What happens if a static initializer block throws an unchecked exception?
The JVM wraps it in an ExceptionInInitializerError, and the class is marked as having failed initialization permanently; any subsequent attempt to use that class throws NoClassDefFoundError, even though the class was loaded successfully.
Does initializing a class also initialize the interfaces it implements?
Not automatically in general — unlike the superclass chain, implemented interfaces are only initialized when specifically needed (e.g. a default method is invoked, or the interface declares its own static state that gets accessed), per the JLS rules for interface initialization.
Why might resolution of a symbolic reference to a nonexistent class not fail immediately when the referencing class is loaded?
Because the JVM Specification allows resolution to be deferred (lazy) until the reference is actually used at runtime — HotSpot commonly resolves lazily — so a dead code path referencing a missing class can go unnoticed until (if ever) that path executes.
What does this program print, and why, in terms of the class initialization rules?
It prints: A B 2 Accessing B.y (a non-constant static field) triggers initialization of B. Initializing B first requires initializing its superclass A (superclasses always initialize before the subclass), so A's static block runs (printing "A"), then B's static block runs (printing "B"), and finally B.y (2) is printed.
Write a class demonstrating the difference between a compile-time constant static field and a computed static field with respect to triggering initialization, with comments explaining what happens.
public class TriggerDemo { static class Marked { static final int CONST = 7; // compile-time constant: inlined by javac static int computed = sideEffect(); static int sideEffect() { System.out.println("Marked initialized"); return 99; } } public static void main(String[] args) { System.out.println(Marked.CONST); // does NOT print "Marked initialized" - // javac inlined the literal 7 at compile time System.out.println(Marked.computed); // NOW prints "Marked initialized", then 99 } }
The first println reads Marked.CONST, a compile-time constant that javac inlines directly into Main's bytecode, so Marked is not loaded/initialized yet — no "Marked initialized" output. The second println reads Marked.computed, a non-constant static field, which forces Marked's initialization: sideEffect() runs, printing "Marked initialized", and 99 is returned and printed.
Explain, step by step, what the JVM does the first time code calls new Dog() where Dog extends Animal and neither class has been used before, referencing loading, linking, and initialization.
1) Loading: the JVM locates Dog.class (and, since Dog extends Animal, also needs Animal) via a ClassLoader and constructs Class objects for both. 2) Linking: each class is verified for bytecode safety, prepared (static fields set to default zero-like values), and has its symbolic references resolved (eagerly or lazily, JVM-dependent). 3) Initialization: because new Dog() triggers initialization, and initializing a class initializes its superclass first, Animal's static initializers/field expressions run first, then Dog's. 4) Only after all of that completes does the JVM actually allocate a Dog instance and run its constructor chain (Animal's constructor, then Dog's).
class A {
static { System.out.println("A"); }
static int x = 1;
}
class B extends A {
static { System.out.println("B"); }
static int y = 2;
}
public class Main {
public static void main(String[] args) {
System.out.println(B.y);
}
}