درونیات JVM، حافظه و Garbage CollectionJVM Internals, Memory & Garbage Collection

This chapter is the heart of Java. Get it right and the rest of the language becomes logical instead of memorized. So don't rush. We go step by step — first grab the idea with a simple analogy, then meet its technical name, then wire it back to real code and interview questions.

Part 0 — Three words you must understand from scratch

Before anything, let's unpack three words that repeat throughout the chapter, in plain language. If these click, the rest is easy.

What does "abstraction" mean?

Imagine driving a car. You only deal with the steering wheel, gas pedal, and brake. What explosions happen inside the engine, how fuel burns, how the gears turn — none of that is your concern, and you don't need to know.

That's abstraction: "hide the complexity, expose only what the user needs."

What is a "virtual machine"?

So when we say the JVM is an "abstract machine," we mean an imaginary computer that hides the underlying hardware details from you.

What does "stack-based" mean?

The JVM uses a structure called a stack to do its computations. A stack is exactly what it sounds like: a pile of plates. The last plate you put on is the first one you take off (this is called LIFO: Last In, First Out).

For example, to compute 2 + 3, the JVM does this: push 2 onto the stack, push 3 on top, then see the add instruction, pop both, add them, and push 5. You don't need to memorize the details right now; just know the stack is the JVM's moment-to-moment workbench.

Part 1 — What exactly does the JVM do? (The big picture)

Let's trace the whole path from "code you write" to "what the CPU does" with an analogy.

So the full path is:

your code (.java)  ──javac──▶  bytecode (.class)  ──JVM──▶  runs on real hardware
   readable English          standard intermediate language     the OS's native machine code

The subtle point: bytecode is platform-independent — the same .class file works on any system. The only thing that differs between operating systems is that last step (the JVM), which has a separate build for each OS.

The JVM does three things with bytecode:

1. Load: find the .class file and bring it into memory.
2. Verify: check that the bytecode is safe and well-formed.
3. Execute: first interpret it line by line; and for the parts that repeat a lot ("hot code"), compile them to native machine code at runtime so they run fast. This runtime compilation is called JIT (Just-In-Time).

The JVM's three subsystems

We'll open all three departments below.

The most important mindset shift: "standard" vs "product"

Here's a senior-level point many people get wrong:

The conclusion here is interview gold:

Part 2 — Class loading: loading → linking → initialization

When your program runs, the JVM does not load all classes at once. It loads a class only when you actually need it for the first time. This is called lazy loading.

When the JVM finally needs a class, it prepares it in three phases in a precise order (per JLS §12.4 and JVMS §5). Let's see them through the analogy of hiring a new employee.

Phase 1: Loading

The "HR department" (the ClassLoader) reads the bytes of the .class file (from disk, from inside a JAR, from the network, or even bytes generated on the fly) and builds a personnel file in memory — in Java this file is a Class<?> object placed on the heap.

Phase 2: Linking — three sub-steps

Now that the file is built, we connect the employee to the company's systems. Three sub-steps:

1. Verification — the security check: the bytecode is checked for safety and correctness: is it type-safe? Are the stack operations valid? Does it have illegal jumps into the code? This is the backbone of JVM security — it's this verification that prevents tampered bytecode from corrupting memory.

2. Preparation — the empty desk: static fields are created and given their default value (numbers 0, objects null, booleans false) — not their real value. Like giving the employee an empty desk and a blank notebook, not their actual tools.

3. Resolution — turning promises into addresses: in your code you wrote "go work with the Database class." For now that's a symbolic name, vague. Here the JVM turns that name into a direct reference (the exact address of that thing in memory). This step can also be lazy and deferred to the last moment.

Phase 3: Initialization

Now it's "the first day of work." The JVM runs a special hidden method called <clinit> (short for class initializer). You don't write this method; the compiler builds it from two things and runs it top to bottom:

• the real initialization of static fields (the 0s and nulls from the previous step now get their real values),
• and the static { ... } blocks.

When does it run? Only on "active use" of the class: new, calling a static method, reading/writing a static field (unless it's a compile-time constant), reflection, or initializing a subclass.

From this guarantee, a very popular and clever pattern for a lazy Singleton is built:

public class Config {
    private Config() {}                       // nobody outside can construct it

    // This inner class isn't loaded until getInstance() is called (lazy loading).
    private static class Holder {
        static final Config INSTANCE = new Config(); // <clinit> once, thread-safe, by the JVM
    }

    public static Config getInstance() { return Holder.INSTANCE; }
}

ClassLoader hierarchy and the delegation model

The HR departments (ClassLoaders) work as a parent-child chain with one strict rule: "ask your boss first." This is the parent-delegation model: each loader first asks its parent to load the class; only if the parent fails does it try itself.

Bootstrap ClassLoader   (native/C++, loads the Java core: java.lang.* etc.)
   └─ Platform ClassLoader   (formerly "extension"; the JDK's own standard modules)
        └─ System/Application ClassLoader   (your program's classpath)
             └─ Custom / web-app ClassLoaders (e.g., Tomcat)

Why does this rule exist? Security. Let's see with an example:

Part 3 — Runtime data areas: where does memory live?

This part shows you where each thing is stored when your program runs. Let's start with the kitchen analogy, then see the precise table.

Now the full table of areas and what error each throws when it fills up:

Two important notes about this table:

1. Each thread has its own stack. If a method calls itself infinitely (endless recursion), the stack fills up and you get StackOverflowError. On the other hand, if you create tens of thousands of platform threads, the system's native memory runs out (each stack is about 512KB–1MB, tunable with -Xss).

2. Metaspace replaced PermGen. This is one of the most important Java 8 changes and a common interview question — we open it fully in the next section.

Zooming in on Metaspace: why and how it replaced PermGen

What exactly is in Metaspace? Metadata (i.e., "data about data"): the class name, the list of methods and their parameters, the list of fields and their types, inheritance info, and the constant pool. Note: the value of a field (e.g., that a user's name is "Ali") is on the Heap; but the fact that "the User class has a name field of type String" is in Metaspace.

Part 4 — Object layout and headers (HotSpot, 64-bit)

Now that we know objects live on the Heap, let's see what an object exactly looks like in memory. Besides your own fields, each heap object has a header the JVM needs to manage it:

[ mark word: 8 bytes ][ klass pointer: 4 bytes ][ your fields... ][ padding to a multiple of 8 ]

• Mark word — management stuff: identity hashCode, age bits for GC, lock state, and during a GC move, a forwarding pointer.
• Klass pointer — points to the class metadata in Metaspace (i.e., "which class am I an instance of?").

So an empty Object is 16 bytes (12 bytes header + 4 bytes padding). Arrays add an extra 4-byte "length" field.

Part 5 — Garbage Collection fundamentals

Here we reach Java's magic: you don't free memory by hand; an automatic Garbage Collector does it. But how does it know which object is "garbage"?

GC works by "reachability," not counting

The generational hypothesis

An empirical observation that the entire design of modern GCs is built on: most objects die young. That is, most objects become useless very soon after being created (like temporary variables inside a method). The GC exploits this fact by splitting the heap:

Young generation:  [ Eden | Survivor S0 | Survivor S1 ]      Old generation (Tenured)

• New objects are created in Eden (ultra-fast allocation, just bumping a pointer).
• A young GC (minor GC) copies the live objects of Eden and one Survivor into the other Survivor and increments their age. Since it only touches live objects and most are dead, it's very cheap.
• An object that survives enough young cycles (-XX:MaxTenuringThreshold, up to 15) is promoted/tenured to the Old generation.
• A major GC collects the old generation; and a Full GC collects everything (young + old + often metaspace). The Full GC is the expensive one you want to avoid.

Weak references: weak / soft / phantom

Java has a few special reference types that let you tell the GC "this object isn't all that important":

• SoftReference — cleared only under memory pressure. Good for caches (but be careful, it can leak).
• WeakReference — cleared at the next GC once it's only weakly reachable. The basis of WeakHashMap.
• PhantomReference — for deterministic cleanup of native resources after an object dies (the Cleaner class, the modern replacement for finalize()).

Part 6 — The GC landscape: which one, when?

Java has several different Garbage Collectors, and you pick one with a flag. Each is a trade-off between throughput (total work done) and latency (short pauses).

G1 with a bit of detail

G1 (short for Garbage-First) divides the heap into about 2048 equal regions (each 1–32MB). Each region dynamically gets tagged as Eden, Survivor, Old, or Humongous (objects larger than half a region). G1 marks mostly concurrently, then does STW evacuation pauses that pull live objects first out of the regions with the most garbage — hence "Garbage-First." You give a pause target, not an exact layout; G1 itself decides how many regions to collect to hit your target. G1 effectively eliminated the multi-second Full GCs of the old CMS collector (CMS was fully removed in Java 14).

ZGC and Generational ZGC — state the versions precisely

ZGC is a concurrent, region-based, compacting collector that, using tricks called colored pointers and load barriers, moves objects while the program is running. Its headline: pauses are sub-millisecond (typically 0.05–0.5ms) and do not grow with heap size — it scales to multi-terabyte heaps.

Part 7 — JIT compilation, tiered, and inlining

Remember we said the JVM first interprets code and compiles the hot parts? Let's make it precise.

HotSpot first interprets the bytecode and simultaneously profiles it: how many times was each method called? Which branches are taken most? Which types actually show up? Hot methods are turned into native code by two compilers:

• C1 (client): fast compile, light optimization → fast startup.
• C2 (server): slow compile, aggressive optimization (inlining, loop unrolling, dead-code elimination) → peak performance.

Tiered compilation (the default) combines both compilers across 5 levels:

Level 0: interpreter
Level 1: C1, no profiling (trivial methods)
Level 2: C1, limited profiling
Level 3: C1, full profiling      ← most methods warm up here
Level 4: C2, fully optimized     ← the hottest methods reach here

Code starts interpreted, gets compiled by C1 after warming up with profiling, and the truly hot paths "graduate" to C2. Compiled code lives in the code cache.

Inlining — the most valuable optimization

Inlining means replacing a call to a method with the body of that method. Why does it matter? Because once the body is copied in place, all the other optimizations can cross the method boundary and combine. C2 aggressively inlines small, hot methods.

Escape analysis and scalar replacement

C2 tries to prove whether an object escapes the method/thread that created it (i.e., is seen anywhere outside). If it's proven never to escape:

• Scalar replacement: the object is never allocated on the heap; its fields go straight into registers/the stack. That's why a hot loop creating a temporary Point can produce zero garbage.
• Lock elision: if there's a synchronized on an object that doesn't escape, that lock is removed entirely.

// C2 can prove p doesn't escape; the temporary object may never reach the heap.
int sumOfSquares(int[] xs, int[] ys) {
    int total = 0;
    for (int i = 0; i < xs.length; i++) {
        Point p = new Point(xs[i], ys[i]); // scalar-replacement candidate
        total += p.x * p.x + p.y * p.y;
    }
    return total;
}

Deoptimization

C2 makes speculative bets (e.g., "this call site has only ever seen ArrayList, so I'll assume it always does and generate optimized code"). If reality one day violates that assumption (suddenly a LinkedList arrives), the JVM throws away that compiled code, temporarily falls back to the interpreter, and may recompile. This shows up as a short performance dip after a new type appears.

Part 8 — Key flags every senior should know

# heap size — in production set min == max to avoid resize pauses and fragmentation
-Xms4g -Xmx4g

# container-aware (on by default since Java 10+): take heap as a percentage of container memory
-XX:MaxRAMPercentage=75.0

# collector choice
-XX:+UseG1GC            # default
-XX:+UseZGC             # generational from Java 23+
-XX:MaxGCPauseMillis=100

# per-thread stack size
-Xss512k

# Metaspace cap (otherwise it grows until native memory is exhausted)
-XX:MaxMetaspaceSize=256m

# on OOM: take a heap dump and die fast (for later diagnosis)
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps
-XX:+ExitOnOutOfMemoryError

# GC log (unified, since Java 9+)
-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=5,filesize=20m

Part 9 — Memory leaks and classifying OutOfMemoryError

Classic leak sources:

• static collections that only grow (static Map cache = ... that never removes anything).
• Unbounded caches — use a size cap instead (Caffeine, LRU).
• Listeners/callbacks that are never unregistered — the subject keeps the observer forever.
• ThreadLocal in thread pools — a pooled thread never dies, so the ThreadLocal value is never freed; always remove() it in a finally.
• ClassLoader leak — one lingering reference to a web app's classes keeps the whole ClassLoader (and all its classes in Metaspace) alive across redeploys.

Types of OutOfMemoryError (each means something different)

Part 10 — How to read a GC log

Modern JVMs (9+) use unified logging (-Xlog:gc*). A G1 young pause looks like this:

[2.335s][info][gc,start] GC(12) Pause Young (Normal) (G1 Evacuation Pause)
[2.340s][info][gc      ] GC(12) Pause Young (Normal) (G1 Evacuation Pause) 512M->48M(1024M) 5.219ms

Read it like this: GC number 12 was a young evacuation pause; the heap went from 512M before → 48M after (so 464M was freed), the total heap is 1024M, and the pause took 5.219ms.

Look for these signs:

• Rising count and length of pauses = trouble ahead.
• Seeing Pause Full on G1/ZGC = a red flag; investigate (allocation spike, humongous objects, too-small heap).
• The live size after each Full GC continually rising = a leak (each collection frees less; the floor keeps rising).
• to-space exhausted = young objects are promoting too fast; tune the sizes.

Part 11 — Common pitfalls and subtleties

Part 12 — Interview questions (with answers)

class Cache {
    private static final Map<Key, Value> M = new HashMap<>();
    static void put(Key k, Value v) { M.put(k, v); } // never evicts
}

Integer a = 127, b = 127;
Integer c = 128, d = 128;
System.out.println((a == b) + " " + (c == d));

Senior notes & advanced edge cases

So far we know where memory lives and how GC cleans up. But in production, the thing that pages you at 3 a.m. is usually the hidden layer underneath those ideas: why your container gets OOM-killed even though -Xmx was respected, why one innocent thread freezes the whole JVM, why "correct" code sees stale values across cores. This section is exactly that layer.

1) The Java Memory Model (JMM): the piece the main chapter skipped

The chapter was about "memory" — but where's its most critical piece, the memory model? The heap is shared across threads, yet each core has its own caches and write buffers, and the compiler/CPU are allowed to reorder instructions. So this question is not obvious at all: "if thread A writes a field, when does thread B see it?"

The heart of the JMM is the happens-before relation: if action X happens-before action Y, then X's effects are guaranteed visible to Y. The edges that matter:

• Monitor lock: an unlock on a lock happens-before every subsequent lock on the same lock.
• volatile: a write to a volatile field happens-before every subsequent read of that field.
• Thread start/join: thread.start() happens-before code inside that thread; that thread's code happens-before a returning thread.join().
• Transitivity: if A→B and B→C then A→C.

Safe publication and final fields. How do you hand an object to another thread without a lock? The JMM guarantees that if an object is properly constructed (i.e., this does not escape during the constructor), its final fields are visible to all threads immediately after the constructor returns — this "final-field freeze" is exactly what makes String and immutable objects safe: you can pass them between threads with zero synchronization. Other safe ways: write through a volatile/AtomicReference field, use a static initializer (the <clinit> guarantee), or pass through a concurrent collection.

// Correct double-checked locking: instance MUST be volatile,
// otherwise another thread can see a non-null but half-constructed reference.
class Lazy {
    private static volatile Lazy instance;   // broken without volatile
    static Lazy get() {
        Lazy r = instance;
        if (r == null) synchronized (Lazy.class) {
            r = instance;
            if (r == null) instance = r = new Lazy();
        }
        return r;
    }
}

2) RSS vs heap: why a -Xmx2g container gets killed at 3 GB

The most common "production mystery": live heap is 1.2 GB, you set -Xmx2g, yet the container hits OOMKilled (exit 137) at 3 GB. Why? Because the heap is only one slice of the whole process's memory. The kernel kills based on RSS (the process's total resident physical memory), not the Java heap.

A one-line decomposition; RSS is the sum of all of these, not just the heap:

flowchart TD
  RSS["Container RSS  (what the kernel OOM-kills on)"] --> Heap["Java Heap (-Xmx)"]
  RSS --> Meta["Metaspace + Compressed Class Space"]
  RSS --> Code["JIT Code Cache"]
  RSS --> Stacks["Thread stacks  (N x -Xss)"]
  RSS --> Direct["Direct / mapped ByteBuffers (NIO, Netty)"]
  RSS --> GC["GC structures (card table, RSets, mark bitmaps)"]
  RSS --> Native["Native libs, JNI, malloc arenas"]

3) TLAB: how allocation is "just bumping a pointer"

The chapter said Eden allocation is "just bumping a pointer." But if every thread contended on one shared pointer they'd need a lock and it would be slow. The fix: the TLAB (Thread-Local Allocation Buffer). Each thread gets its own private chunk of Eden and inside it just bumps a pointer with zero synchronization. That's why allocating a small object in Java is effectively a few nanoseconds.

4) Cross-generational references: card tables and remembered sets

Here's an apparent contradiction seniors must be able to resolve: a young GC wants to scan only young to stay fast; but if an old object points to a young object, that young object is alive — so how do we know without scanning the whole old gen?

5) Time-to-safepoint: how one thread freezes the whole JVM

The chapter said GC pauses everyone at a safepoint. The overlooked senior nuance: reaching a safepoint is not instant. The JVM is "cooperative"; each thread only checks for a safepoint at specific points (method returns, loop back-edges). The catch: for speed, HotSpot omits that check in simple counted loops (an int counter with a known bound)!

6) The mark word isn't just hashCode: lock states

The chapter called the mark word "management stuff." Let's unpack it, because it's an interview question. Those same 8 bytes mean different things depending on state, with a state tag at the bottom:

• Unlocked: hashCode + age bits.
• Thin / lightweight lock: a CAS installs a pointer to a Lock Record on the thread's stack — a cheap uncontended lock.
• Inflated / heavyweight lock: under contention the lock "inflates" and the mark word points to an OS-level ObjectMonitor (mutex/park).
• GC-marked: during collection.

7) Three more subtleties the chapter didn't open

Compressed Class Space — the "second Metaspace." When compressed class pointers are on (heap under 32 GB), the klass metadata itself is stored in a separate, contiguous region called the Compressed Class Space (default ~1 GB reserved, tuned with -XX:CompressedClassSpaceSize). So Metaspace is actually two parts, and you can specifically get OutOfMemoryError: Compressed class space (distinct from Metaspace) — usually when you generate thousands of dynamic classes.

Inline caches and expensive polymorphism. The JIT colors each virtual call site by the types it has seen: monomorphic (one type → inline + a guard), bimorphic (two types), and megamorphic (more than two → it gives up, does a vtable lookup, and does not inline). A very heavily shared interface with dozens of implementations (a hot-path logging call, a generic abstraction) can turn call sites megamorphic and slow — sometimes "less abstraction" in a hot path really is faster. Related: OSR (On-Stack Replacement) lets a long-running loop be compiled while it's still executing; and intrinsics are methods like System.arraycopy, Math.max, Integer.bitCount that the JIT replaces with hand-written assembly/CPU instructions.

8) Startup & warmup: the cost that burns microservices

The JIT needs to "warm up": the first few seconds run interpreted and slow. For a long-lived service that's irrelevant, but for serverless, scale-to-zero, and fast Kubernetes scaling it hurts. The modern options:

• AppCDS (Application Class Data Sharing): archives parsed classes so the next start doesn't re-parse them.
• JEP 483 (AOT Class Loading & Linking, JDK 24, Project Leyden): one step past AppCDS — it also loads and links classes ahead of time into an "AOT cache"; the official demo shows Spring PetClinic starting up to ~42% faster. Requires a "training run" that mimics production.
• CRaC (Coordinated Restore at Checkpoint): checkpoints an already-warmed JVM and restores it in milliseconds — instant startup and instant peak performance (available in Azul/Zulu builds).
• GraalVM Native Image: compiles the whole program AOT into a native binary: near-instant startup and low memory, but no JIT (lower peak for heavy loads) and a closed world (reflection needs configuration).

Hard senior interview questions (additional)

Sources: JEP 439, JEP 474, JEP 490, Inside.java: Generational ZGC.