Java Memory Management and GC: Heap, Generations, G1, ZGC, and Real Leaks

Garbage collection is Java’s most successful abstraction — so successful that many developers ship for years without thinking about memory at all. Then one day the service OOMs at 2 a.m., or p99 latency spikes every forty seconds, and the abstraction demands its invoice.

You don’t need to be a GC engineer. You need the working model: where objects live, how collectors decide what dies, what the modern collectors trade against each other, and how leaks happen in a language that supposedly made them impossible. That’s this guide.

Stack and Heap: Where Things Actually Live

Every thread owns a stack — small (defaults around 1 MB), fast, holding each method call’s frame: parameters, local variables, return address. Frames vanish automatically on return; the stack needs no GC. Overflow it with runaway recursion and you get StackOverflowError.

All objects live on the shared heap. Local variables of object type hold references pointing into it:

void handle() {
    int retries = 3;                      // primitive → in the stack frame
    var user = new User("Priya");         // 'user' ref in frame → User object in heap
}                                          // frame gone; the User? GC's problem now

Allocation in the heap is astonishingly cheap — typically a pointer bump in a thread-local buffer, faster than C’s malloc. Java programs allocate torrentially (every boxed int, every substring, every stream op) and are designed to; the entire GC architecture is built around making that torrent cheap to clean up.

What GC Actually Does: Reachability, Not Reference Counting

The JVM doesn’t count references (that would leak cycles and tax every assignment). Instead, collectors periodically trace reachability: start from the GC roots — every thread’s stack variables, static fields, JNI handles — and follow references. Everything reached is alive; everything else is, by definition, garbage:

roots: [thread stacks] [static fields]
          │                 │
          ▼                 ▼
        Order ──▶ Customer   Config
          │
          ▼                     ┌────────┐   unreachable island
        LineItem                │ A ⇄ B  │ ← collected despite the cycle
                                └────────┘

Two mental corrections this model makes:

• Cycles are harmless. Two objects referencing each other die together the moment nothing external reaches them.
• “Unused” isn’t collected — unreachable is. An object you’ll never touch again but that’s still referenced from a static map is immortal. Hold that thought; it’s the entire leak story below.

System.gc() is a suggestion the JVM may ignore, and calling it in application code is a bug in almost all cases. Finalizers are deprecated and were never reliable; use try-with-resources for non-memory resources — GC manages memory, nothing else.

The Generational Bet

Empirically, across nearly all programs: most objects die young (that substring, that boxed Integer, that stream’s intermediates — dead microseconds after birth), while objects that survive a while tend to live long (caches, sessions, config). Collectors exploit this by splitting the heap:

┌───────────────── young generation ─────────────┬──── old generation ────┐
│  eden (new objects)  │ survivor S0 │ survivor S1│  long-lived objects    │
└──────────────────────┴─────────────┴────────────┴────────────────────────┘

• Allocation happens in eden. When eden fills, a minor GC traces just the young generation — and because most of it is dead, copying the few survivors out is fast. Dead objects cost nothing; they’re simply never copied.
• Objects surviving several minor GCs get promoted to the old generation.
• When the old generation fills, a major/full GC works the whole heap — historically the expensive, everything-pauses event.

Consequences you can use:

• Short-lived garbage is nearly free. Don’t contort code to avoid temporary objects on the JIT-optimized path; the generational design (plus escape analysis, which can avoid heap allocation entirely) already handles it.
• Premature promotion is the real cost. Medium-lived objects — alive just long enough to reach the old generation, dead soon after — are the GC-expensive pattern (think: per-request data held across slow calls).
• A “memory leak” graph in Java looks like a sawtooth whose valleys climb: each collection reclaims less, until OOM.

The Collectors That Matter in 2026

The JVM ships several collectors; you choose with a flag, and the differences are about pause time vs. throughput vs. memory overhead:

G1 divides the heap into ~2048 equal regions (young and old are region sets, not contiguous blocks) and collects incrementally, targeting a pause goal (-XX:MaxGCPauseMillis=100) by choosing how many regions to clean per cycle — “Garbage First” means it picks the most-garbage regions for the best ROI per pause.

ZGC (and Shenandoah, its sibling in spirit) does almost everything concurrently with your running application using colored pointers and load barriers — pauses stay under a millisecond even on terabyte heaps. Since JDK 21, generational ZGC added the young/old distinction, removing its main throughput penalty. The trend is clear: for latency-sensitive services on modern JDKs, ZGC has moved from exotic to routine.

Tuning advice that reflects actual practice: set the heap size (-Xmx/-Xms), pick the collector, and stop. The old dark art of tuning survivor ratios and tenuring thresholds is mostly obsolete on G1/ZGC; modern collectors self-tune better than folklore flags do. In containers, prefer -XX:MaxRAMPercentage=75 so the heap follows the container limit — and remember the JVM needs off-heap room too (metaspace, thread stacks, buffers), so never give the heap 100% of the container.

Memory Leaks in a Garbage-Collected Language

Java leaks are always the same bug wearing different costumes: a reachable reference to something you’ll never use again. The classic costumes:

1. The unbounded static cache — the number-one offender:

static final Map<String, Result> CACHE = new HashMap<>();   // grows forever

Static → GC-root-reachable → immortal. Fix: bound it (LRU via LinkedHashMap.removeEldestEntry, or a real cache like Caffeine with size/expiry), and ask whether it needed to be static at all.

2. Listeners and callbacks never unregistered. The publisher’s listener list keeps every subscriber — and everything each subscriber references — alive. Deregister on teardown, or the registry must use weak references.

3. Collections that only ever grow — audit lists, “recent items” without a cap, maps keyed by session ID with no eviction on logout.

4. The mutated-key ghost from the HashMap guide: entries unreachable by lookup but still referenced by the map — leaked and unfindable.

5. ThreadLocal in thread pools. Pool threads live forever, so per-request ThreadLocal values survive the request unless you remove() in a finally. This one produces the confusing cross-request-data-bleed bugs, too.

6. The subtle classics: a tiny subList/substring-style view pinning a huge backing structure (make an explicit copy when keeping a small slice of something big), and non-static inner classes silently holding their outer instance (this$0) — an anonymous listener inside a giant object keeps the giant alive.

The diagnostic path when memory climbs: watch the sawtooth (jconsole/Grafana), then take a heap dump — jmap -dump:live,file=heap.hprof <pid> or -XX:+HeapDumpOnOutOfMemoryError in prod JVM flags (do this today; the flag is free until the day it saves you) — and open it in Eclipse MAT. The dominator tree points at the few objects retaining the most memory; the leak is nearly always in the top three, and it’s nearly always a collection.

Reading OutOfMemoryError Like a Pro

OutOfMemoryError is a family; the message names the culprit:

• Java heap space — the classic. Either the workload genuinely needs more (-Xmx) or you have a leak (heap dump, MAT, dominator tree).
• GC overhead limit exceeded — the JVM spent >98% of time collecting for <2% recovery: you’re at the top of the climbing sawtooth. Treat as a leak until proven otherwise.
• Metaspace — class metadata, not objects: runaway class generation (proxies, scripting) or classloader leaks on redeploy.
• unable to create native thread — OS thread limit, not heap: thread-per-request without bounds (virtual threads largely retired this one).
• Direct buffer memory — off-heap NIO buffers, invisible to heap dumps; bounded by -XX:MaxDirectMemorySize.

One reflex worth installing: an OOM’s stack trace shows who made the final allocation — usually an innocent bystander. The heap dump shows who’s hoarding. Diagnose from the dump, not the trace.

What This Means for Everyday Code

Distilled into habits:

1. Allocate freely in the small; think twice in the immortal. Temporaries are near-free; anything reachable from a static or a long-lived object needs a lifecycle plan.
2. Every cache needs a bound and an eviction story — “cache” without “eviction” is “leak” pronounced optimistically.
3. Deregister what you register; remove() your ThreadLocals in finally.
4. Immutable objects are GC-friendly as well as thread-friendly — no old-gen object mutating to point at young objects (write barriers cost), no defensive lifetime puzzles.
5. Ship with -XX:+HeapDumpOnOutOfMemoryError and a metrics view of heap-after-GC. The trend line — not the current usage — is the health signal.
6. Reach for GC logs (-Xlog:gc*) before GC flags. Measure, then tune; most “GC problems” are leaks or undersized heaps, not collector choice.

Frequently Asked Questions

Does setting variables to null help the GC? Almost never — when a local variable’s method returns (or the JIT determines the variable is no longer used, which happens earlier), the reference stops counting toward reachability automatically. The exception that proves the rule: nulling out slots in long-lived arrays you manage yourself (the classic example is a hand-rolled stack’s popped slots, an actual bug in early collection implementations). In normal application code, x = null; lines are superstition.

What are weak, soft, and phantom references? Escape hatches from ordinary (“strong”) reachability. A WeakReference doesn’t keep its target alive — the basis of WeakHashMap for caches-that-shouldn’t-own-their-keys. SoftReferences are cleared only under memory pressure (in practice, dedicated cache libraries with explicit sizing behave more predictably). Phantom references support post-mortem cleanup via Cleaner, the modern replacement for finalizers. You’ll use libraries built on these more often than you’ll touch them directly — but now the Javadoc mentions make sense.

Why does my JVM’s memory in top exceed -Xmx? Because -Xmx bounds only the Java heap. The process also holds metaspace, code cache (JIT output), thread stacks (1 MB × threads), GC bookkeeping, and direct buffers. A 4 GB-heap JVM comfortably occupies 5+ GB of RSS. Container sizing that ignores this is the number-one cause of Kubernetes OOM-kills that “can’t happen because Xmx is set.”

Do virtual threads change GC behavior? They shift stack memory into the heap — virtual thread stacks are heap objects that grow and shrink — so massive-concurrency services see more heap traffic but no longer risk unable to create native thread. The concurrency guide covers the model; from the GC’s perspective they’re just more (well-behaved, mostly young) objects.

Is finalize() really gone? Deprecated for removal, and you should behave as if removed: it ran at unpredictable times, possibly never, could resurrect objects, and slowed collection. Resource cleanup belongs to try-with-resources; last-resort safety nets to Cleaner.

A Five-Minute Lab You Can Run Today

Nothing builds intuition like watching a collection happen. Run any Java service or test locally with:

java -Xmx256m -Xlog:gc file.jar        # small heap makes GC visible quickly

Then read the log lines: Pause Young (Normal) entries every so often, each reporting before->after(total) sizes and a pause of a few milliseconds — that’s the generational hypothesis working in real time (huge reclaim, tiny pause). Now write a deliberate leak — a static ArrayList appended to in a loop — and watch the pattern change: collections more frequent, after sizes climbing, Pause Full appearing, then the crash with heap dump if you enabled it. Ten minutes of this teaches more than any diagram, and the log vocabulary you just learned is exactly what you’ll grep during a real incident.

Self-Check

1. Two objects reference each other but nothing else references them. Collected or leaked — and why would the answer differ in a reference-counting system?
2. Why are minor GCs fast even when eden is full of garbage?
3. A service’s heap-after-GC climbs 2% daily until weekly restarts “fix” it. Name the three most likely culprits you’d check in the heap dump.
4. OutOfMemoryError: Java heap space — the stack trace points at StringBuilder.append in a logging utility. Is the logger the problem?
5. When would you pick ZGC over G1, and what did generational ZGC (JDK 21+) change about that decision?

(Answers: collected — reachability tracing sees an unreachable island; refcounting would leak the cycle. Survivor-copying cost scales with live objects, and almost nothing in eden is live; the dead are never touched. Unbounded static cache, listener registry, ever-growing collection — top of the MAT dominator tree. Probably not — the trace shows the final straw; find the hoarder in the dump. Latency-sensitive or huge-heap services; generational ZGC removed most of the throughput penalty, making it viable as a general default.)

That completes the Java series’ core arc: from how the JVM runs your code to how it cleans up after it. The through-line, if there is one: Java’s “ceremony” — static types, checked contracts, explicit design — is the price of systems that stay debuggable at millions of lines and terabytes of heap. Pay it deliberately, and the platform repays you for decades.