JVM, memory and garbage collection: the must-knows

For this sheet, we'll walk the JVM from the outside in: architecture, class loading, runtime data areas, object layout, the JIT, then GC basics and the collectors. The second half goes where senior rounds go: reference types, leaks, every OutOfMemoryError message, the flags and tools, a GC log line read out loud, and the talk track. Everything is correct for Java 21 on HotSpot (the JVM inside OpenJDK, Oracle JDK, Temurin and Corretto), and I flag where older or newer versions differ.

01Picture it first: the JVM in one diagram

Think of the JVM as a small factory. The class loaders are receiving: they accept .class files, inspect them and file them. The runtime data areas are the floor space: one big shared warehouse (the heap), a records office for blueprints (metaspace), and a private workbench for each worker (thread stacks). The execution engine is the workforce: an interpreter that reads instructions one by one, a JIT that rewires the busiest stations into machines, and a cleaning crew (the GC) that clears the warehouse.

The diagram below is the one I'd expect you to draw in the first two minutes of a JVM round. Notice the split between what's shared and what belongs to a single thread.

Fig. 1

JVM architecture: the class loader subsystem with bootstrap, platform and application loaders feeds the runtime data areas, where heap and metaspace are shared and each thread has its own stack, PC register and native stack, and the execution engine with interpreter, JIT and garbage collector runs the code and calls native libraries through JNI

• JVM vs JRE vs JDK: the JVM runs bytecode; the JDK is the JVM plus the class library plus tools (javac, jcmd, jlink). Since Java 11, Oracle no longer ships a separate JRE (a few vendors still package one); you build a trimmed runtime with jlink. JDK, JRE and JVM explained
• Write once, run anywhere: javac produces platform-neutral bytecode; each OS has its own JVM that interprets and compiles it. From source to bytecode

02Class loading: load, link, initialize

A class enters the JVM in three phases, defined in chapter 5 of the JVM spec. Interviewers ask this to see whether you know that "loading a class" and "running its static block" are different moments.

Parent delegation is the rule every built-in loader follows: before loading a class itself, a loader asks its parent. The chain is bootstrap (native code, loads java.base and other core modules), platform (Java 9+, replaced the extension loader; loads modules like java.sql), and application (also called system, loads your classpath and module path). The reasons are safety and uniqueness: nobody can slip in their own java.lang.String, and a class is loaded once per hierarchy.

• Class identity is name plus defining loader: the same com.acme.User loaded by two loaders is two different classes, which is how you get ClassCastException: com.acme.User cannot be cast to com.acme.User in app servers and plugin systems.
• Who breaks delegation on purpose: Tomcat's webapp loader looks in the WAR first (child-first) so each app can ship its own library versions; ServiceLoader and JDBC use the thread context class loader so core code can find classes on your classpath.
• Class.forName("X") initializes, loader.loadClass("X") doesn't: that's why old JDBC code called Class.forName on the driver, to run its static block that registered it.

Static init runs on the first active use of the class: new, a static method call, reading or writing a static field that isn't a compile-time constant, reflection like Class.forName, initializing a subclass (the parent goes first), or being the main class. It does not run for a static final primitive or String with a constant initializer (the compiler inlines the value), for Foo.class, or for new Foo[10].

class Config {
    static final int MAX = 10;            // compile-time constant, inlined by javac
    static final Integer BOXED = 20;      // not a constant: needs initialization
    static { System.out.println("Config init"); }
}

public class Main {
    public static void main(String[] args) {
        Config[] slots = new Config[3];   // no init: an array of Config is its own class
        System.out.println(Config.MAX);   // no init: 10 was copied into Main's bytecode
        System.out.println(Config.BOXED); // first active use
    }
}

The output is 10, then Config init, then 20. Notice two things. The array creation and the constant read never touch Config, and the static block runs exactly once, right before the first real use. This is also why lazy holder singletons work: the nested Holder class isn't initialized until getInstance() reads its field, and the JVM's class-init lock makes it thread-safe for free. More in The static keyword in Java.

03Runtime data areas: what lives where

The JVM spec defines six runtime data areas. Two are shared, three are per thread, and one (the runtime constant pool) lives inside the method area.

• Metaspace replaced PermGen in Java 8 (JEP 122). PermGen was a fixed-size part of the heap that ran out with OutOfMemoryError: PermGen space when apps loaded many classes or redeployed. Metaspace lives in native memory and grows on demand, so the classic failure became a slow native-memory leak instead. Interned strings and static values had already moved to the heap.
• Stack vs heap in one sentence: the stack holds primitives and references local to a method call and disappears when the call returns; the heap holds the objects those references point to and is cleaned by the GC. User u = new User() puts the reference u (4 bytes with compressed oops) in the frame and the User object on the heap.
• Fields live with their object: an int field of a heap object is on the heap, not the stack. "Primitives go on the stack" is only true for local variables.
• Stacks are thread-safe by construction: nothing else can see your frame, which is why local variables never need synchronization but shared heap objects do.

Escape analysis is the JIT's answer to "can objects ever avoid the heap?". C2 checks whether an object escapes the method (stored in a field, returned, passed to code it can't inline). If it doesn't, C2 can apply scalar replacement: it never allocates the object and keeps its fields in registers or stack slots. HotSpot doesn't allocate whole objects on the stack; it removes them. It also enables lock elision on objects no other thread can see.

// After C2 compiles this method, Point is usually never allocated:
// p doesn't escape, so x and y live in registers.
record Point(int x, int y) {}

static long distanceSquared(int x, int y) {
    Point p = new Point(x, y);
    return (long) p.x() * p.x() + (long) p.y() * p.y();
}

04Object layout: what an object costs

Interview questions for this topicComing soon