JVM Garbage Collection — Field Reference

The generational hypothesis, GC roots, and the mark/sweep/compact cycle every collector below builds on.

An object is unreachable when no chain of strong references connects it to a GC root: local variables and operand-stack entries in live frames, static fields of loaded classes, JNI references, and references held directly by the JVM. The collector traverses the object graph from these roots; anything not visited is garbage.

Almost every production collector — Serial, Parallel, G1, Shenandoah, ZGC — leans on the generational hypothesis: most objects die young, a few live forever. Splitting the heap into a small, frequently-collected young generation and a larger, rarely-collected old generation lets the collector spend most of its effort where the payoff is highest.

flowchart LR
  subgraph HEAP["Java Heap"]
    direction LR
    subgraph YOUNG["Young Generation"]
      direction TB
      E["Eden\n(new allocations)"]
      S0["Survivor S0"]
      S1["Survivor S1"]
    end
    OLD["Old Generation\n(Tenured)"]
  end
  META["Metaspace\n(off-heap: class metadata)"]
  E -- "minor GC, survives" --> S0
  S0 -- "ages out" --> S1
  S1 -- "promoted" --> OLD
  HEAP -.-> META

Every tracing collector runs some variant of three phases:

• Mark — traverse from GC roots, flag every reachable object (typically a bit in the object header).
• Sweep — return the memory of unmarked objects to a free list.
• Compact / Copy — relocate surviving objects into contiguous memory to fight fragmentation and keep allocation a cheap pointer-bump.

Five collectors, one evolutionary line: throughput-first, then pause-aware, then almost entirely concurrent.

flowchart LR
  A["Serial\nsingle-threaded STW"] --> B["Parallel\nmulti-threaded STW"]
  B --> C["CMS\nconcurrent, no compaction\n(deprecated Java 9, removed 14)"]
  C --> D["G1\ndefault since Java 9\nregion-based, mostly-concurrent"]
  D --> E["Shenandoah / ZGC\nJava 11+ / 15+\nfully concurrent, sub-ms pauses"]
  E --> F["Epsilon\nno-op — allocates, never collects"]
  classDef legacy fill:#00000000,stroke-dasharray: 4 3;
  class A,B,C legacy;

• Serial — single-threaded, stop-the-world. Fine for small heaps and client apps; unacceptable for any latency-sensitive service.
• Parallel — same STW model, multiple threads doing the work. Throughput-optimized, still not pause-aware.
• CMS — the first attempt at concurrency. Never compacted, suffered fragmentation and "concurrent mode failure" fallbacks to a full STW collection. Deprecated in Java 9, removed in Java 14 — do not target it in new deployments.
• G1 — the default since Java 9. Region-based, mostly concurrent, offers a soft real-time pause-time target rather than a guarantee. See §03.
• Shenandoah / ZGC — sub-millisecond pauses regardless of heap size, at the cost of some throughput and (for ZGC) memory footprint. See §04–§05.
• Epsilon — allocates and never reclaims. A deliberate no-op collector, not a broken one — see §06 for when that's actually the right call.

Symptom: periodic multi-hundred-ms pauses with no full GCs in the logs, correlated with allocations just above the region size.

G1 divides the heap into equal-sized regions (1–32MB, chosen so the heap holds roughly 2,048 of them) and allocates normal objects into per-thread TLABs — a lock-free pointer bump inside an Eden region. Any object larger than 50% of a region is classified Humongous and bypasses this entirely.

Region sizeThe default formula

A humongous object skips Eden and Survivor and is placed directly in the Old Generation as a run of contiguous regions — breaking G1's core generational assumption that objects die young.

Why the pause happens

1. The allocating thread cannot use its TLAB and must acquire the global Heap_lock, stalling every other thread doing slow-path allocation.
2. G1 must find contiguous free regions large enough for the object.
3. If none are free, G1 triggers an emergency, synchronous young collection to coalesce space — this is the pause you see in the logs.

flowchart TD
  A["Sustained humongous allocation rate\n(e.g. 600MB/s)"] --> B{"IHOP threshold tripped?"}
  B -- yes --> C["Concurrent Mark starts"]
  C --> D{"Marking keeps pace?"}
  D -- "too slow" --> E["Marking interrupted"]
  B -- "space exhausted\nbefore marking finishes" --> F["Emergency Young GC (STW)"]
  E --> F
  F --> G["Coalesce contiguous regions\n→ multi-hundred-ms pause"]

Fix the allocation pattern, not the collector

Pool and reuse the oversized buffers instead of allocating them per request. A bounded, lock-free pool eliminates the humongous allocation rate directly:

public final class BufferPool {
    private static final int BUFFER_SIZE = 3 * 1024 * 1024;   // 3MB
    private static final int MAX_POOL_SIZE = 512;              // caps footprint at 1.5GB
    private final ConcurrentLinkedQueue<byte[]> pool = new ConcurrentLinkedQueue<>();

    public byte[] acquire() {
        byte[] buf = pool.poll();
        return buf != null ? buf : new byte[BUFFER_SIZE];   // fallback allocation
    }

    public void release(byte[] buf) {
        if (buf != null && buf.length == BUFFER_SIZE) pool.offer(buf);
        // full pool: let GC reclaim naturally
    }
}

Symptom: steady heap growth during a concurrent cycle, then a multi-second "Degenerated GC" stop-the-world pause.

Shenandoah is fully concurrent: it evacuates live objects while the application keeps mutating the graph. To keep marking correct under that mutation, it uses the tri-color abstraction plus a Snapshot-At-The-Beginning (SATB) write barrier.

Corruption risk: a mutator writes a reference to a White object into a Black object while destroying the only path from Grey. SATB's rule closes this: no object reachable at the start of the cycle may be lost. Every reference overwrite first logs the old value into a thread-local SATB queue — "greying" it — rather than requiring a re-scan of the whole graph.

flowchart LR
  A["Mutator writes new_value\ninto field"] --> B{"GC cycle active?"}
  B -- no --> F["Write proceeds\n(no barrier cost)"]
  B -- yes --> C{"old_value != null\nand unmarked?"}
  C -- no --> F
  C -- yes --> D["Enqueue old_value\ninto thread-local SATB buffer"]
  D --> E["old_value is now Grey"]
  E --> F

Floating garbage & the 40GB → 62GB climb

Because SATB keeps every object reachable at cycle-start alive for the whole cycle, anything that dies mid-cycle becomes floating garbage — uncollectable until the cycle ends. Under a burst of high-frequency mutation (order-book updates, in the source scenario), a 10-second concurrent cycle can pin tens of gigabytes of dead objects that would otherwise have been reclaimed immediately.

Shenandoah vs. G1's incremental update

G1 also uses SATB for marking, but leans on Remembered Sets for cross-region pointers and its evacuation phase is itself stop-the-world — so an overflowing SATB queue degrades throughput without necessarily forcing an emergency pause. Shenandoah's evacuation is concurrent; if its SATB queues overflow, marking cannot complete, evacuation can't be scheduled, and the JVM falls back to a synchronous Degenerated GC to finish the work.

These knobs trade memory and safepoint time for pause resilience — they buy headroom, they don't fix a sustained high-mutation-rate workload.

Symptom: pause times are excellent, but RSS runs far above the heap size and Kubernetes OOMKills the pod.

ZGC avoids external per-object GC metadata by embedding state directly into the pointer itself — a colored pointer.

+-------------------+-+----+-----------------------------------------------+
| 18-bit unused      |G|Colr| 42-bit object address                          |
+-------------------+-+----+-----------------------------------------------+

The color bits encode Marked0, Marked1, or Remapped. Dereferencing a colored pointer directly would crash the CPU, so ZGC maps the same physical memory into three separate virtual address ranges (multi-mapping) — the MMU resolves whichever colored address the pointer carries to the one physical page, with no per-access bitmask instruction required.

flowchart LR
  P["Physical page\n(1x actual RAM)"]
  M0["Virtual: Marked0"] --> P
  M1["Virtual: Marked1"] --> P
  R["Virtual: Remapped"] --> P

Why RSS looks 80% over heap size

Beyond the page-table tax, ZGC's ZPageCache deliberately retains freed physical pages rather than returning them, because returning memory is expensive:

madvise(addr, length, MADV_DONTNEED);
// synchronous — walks kernel page tables, triggers a TLB shootdown
// across every core. If the memory is needed again soon, the next
// touch is a real page fault: zero, map, and stall the thread.

Set -XX:ZUncommitDelay too low on a bursty workload and you get thrashing: free → uncommit → burst traffic → page fault → re-allocate → repeat — burning the exact throughput ZGC was meant to protect.

Diagnosing bloat: page cache vs. real leak

# boot with -XX:NativeMemoryTracking=detail
jcmd <pid> VM.native_memory baseline
# ...wait for RSS to climb...
jcmd <pid> VM.native_memory detail.diff

If growth sits under the GC category (and roughly tracks active heap usage), it's ZPageCache retention — expected. If Internal, Symbol, or Compiler categories climb continuously instead, that's a genuine native leak, not ZGC.

-XX:+UseZGC -XX:+ZGenerational
-Xms850g -Xmx850g                 # leave ~370GB for off-heap + page tables + OS
-XX:+ZUncommit -XX:ZUncommitDelay=120
-XX:ZCollectionInterval=60        # force periodic reclaim during quiet windows
-XX:ZFragmentationLimit=20
-XX:NativeMemoryTracking=summary

# node level — never leave THP at "always" under ZGC
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

Pick by constraint, not by reputation.

flowchart TD
  Q1{"Process is short-lived\nwith bounded, known allocation?"}
  Q1 -- yes --> EPS["Epsilon"]
  Q1 -- no --> Q2{"Pause SLA?"}
  Q2 -- "no strict SLA" --> G1["G1"]
  Q2 -- "< 10ms" --> Q3{"Heap fits in\n32GB with room\nto lose Compressed Oops?"}
  Q3 -- "small / mid heap" --> SH["Shenandoah"]
  Q3 -- "huge heap, sub-ms" --> ZG["Generational ZGC"]

Symptom: 80% CPU in ReferenceQueue.remove()/enqueue(), a multi-million backlog, throughput collapses under load.

SoftReference is not an application cache-eviction strategy. It is a JVM-managed emergency release valve, and treating it as a cache primitive for tens of millions of entries reliably collapses under load.

Why there's exactly one ReferenceHandler thread

When the GC determines an object is only softly/weakly/phantomly reachable, it appends it to a single, global, JVM-internal pending list — not directly to your ReferenceQueue. One high-priority daemon thread, the ReferenceHandler, drains that list and hands entries off to their Java-level queues. The single-thread design simplified JVM internals early on; at 50M references and 50K req/s it becomes the application's choke point.

sequenceDiagram
  participant GC as Garbage Collector
  participant PL as Reference.pending (global list)
  participant RH as ReferenceHandler (1 thread)
  participant RQ as Your ReferenceQueue
  participant APP as 64 application threads

  GC->>PL: discovers cleared soft/weak/phantom refs
  loop single-threaded drain
    RH->>PL: poll (lock-free CAS)
    RH->>RQ: enqueue()
  end
  APP->>RQ: remove() — blocks on empty / contends under backlog

The enqueue path is lock-free, but "lock-free" is not "free": atomic CAS on the pending-list head under sustained load triggers the MESI cache-coherency protocol to bounce that cache line across NUMA nodes on every write — hundreds of stalled cycles per operation, showing up as CPU time spent on hardware synchronization instead of business logic.

Why SoftReference eviction is unpredictable under G1

eligibleIdleTime = (MaxMemory - UsedMemory) * SoftRefLRUPolicyMSPerMB

G1 collects incrementally by region and has no global, real-time view of every soft reference's last-access time. Soft references in a hot young-gen region can be cleared prematurely while stale ones in an untouched old-gen region linger — and when memory pressure finally forces a clear, it clears everything past the threshold at once.

Cleaner (Java 9+) does not fix this. It still registers objects as PhantomReferences under the hood — they must still pass through the same single-threaded ReferenceHandler handoff before Cleaner's own thread pool ever sees them.

The fix: stop using JVM reference tracking for caching

Cache<CacheKey, CacheValue> cache = Caffeine.newBuilder()
        .maximumSize(maxEntries)                    // bounded — no OOM
        .expireAfterAccess(Duration.ofMinutes(10))   // predictable, not heap-pressure-driven
        .recordStats()
        .build();

Symptom: OutOfMemoryError: Metaspace after repeated hot-reload / plugin-reload cycles, even though "unloaded" classes should be gone.

A class is identified by its binary name plus its defining ClassLoader — so a class can only be unloaded once its ClassLoader is completely unreachable. Two distinct events are often conflated:

• Class unloading — a logical marking during a GC cycle once the loader is confirmed unreachable.
• Metadata deallocation — the physical reclaim of native memory, deferred until every class in a shared Metachunk is unloaded. One pinned class can hold an entire chunk's memory hostage.

Why G1 can delay this by minutes on an under-utilized heap

G1 unloads classes concurrently during its Remark phase, but that phase is triggered by old-gen occupancy crossing -XX:InitiatingHeapOccupancyPercent (default 45%). On a 32GB heap with a 2GB working set, that threshold may never trip — Metaspace grows completely decoupled from heap-driven GC triggers until it hits MaxMetaspaceSize on its own.

The two things quietly pinning your ClassLoader

Proxy cache reference chain

AppClassLoader (parent, immortal)
  └──> java.lang.reflect.Proxy$ProxyCache
        └──> CacheKey (interfaces from AppClassLoader)
              └──> generated Proxy class (defined by RestartClassLoader)
                    └──> RestartClassLoader  [LEAKED]

JDK dynamic proxies cache generated classes keyed by defining loader + interfaces. Because the parent loader is immortal, that cache entry is never evicted — pinning every class the child loader ever defined.

SoftReference caches in Spring / CGLIB

Using the same LRU formula from §07: on a 32GB heap with 30GB free, SoftRefLRUPolicyMSPerMB=1000 (the default) computes an eligible idle time of roughly 347 days. With no real heap pressure, the GC simply refuses to clear these caches — and they're anchoring your restart-scoped loader the entire time.

flowchart TD
  A["GC.class_histogram shows\nrising ClassLoader instance count"] --> B["jcmd <pid> GC.heap_dump"]
  B --> C["Open in Eclipse MAT"]
  C --> D["Histogram → find your\ncustom ClassLoader class"]
  D --> E["Right-click → Path to GC Roots\n(exclude weak/soft refs)"]
  E --> F{"Root is..."}
  F --> G["a Thread's threadLocals\n→ ThreadLocal leak"]
  F --> H["an unterminated Thread\n→ still running / never joined"]
  F --> I["a static field\n→ global cache/singleton"]
  F --> J["JMX MBeanServer\n→ registered, never unregistered"]

-Xlog:class+unload=info,gc+metaspace=debug,gc+class*=debug:file=/var/log/app/gc_metaspace.log:time,uptime,level,tags

Seeing [debug][gc,class,load] entries with zero corresponding class,unload entries across a Full GC is a confirmed hard leak, not a timing artifact.

Symptom: old-gen collections get progressively more expensive, and the post-Full-GC baseline never returns to where it started.

A JVM leak is not lost memory in the C sense — it's unused but still-reachable memory. Something is holding a chain of strong references from a GC root (a static field, an active thread stack, a stale ThreadLocal entry) to objects the application logically no longer needs.

Leak vs. allocation churn — the distinguishing test

Triage order — cheapest signal first

1. GC logs — does post-Full-GC heap occupancy trend upward across days? That alone confirms a leak.
2. jcmd <pid> GC.class_histogram — snapshot, wait an hour, diff. Look for classes with continuously growing instance counts.
3. JFR with jdk.OldObjectSample — near-zero overhead, samples objects that survive into old-gen and reconstructs their allocation stack trace and GC-root reference chain.
4. Isolated heap dump — only if JFR is inconclusive, and only after draining traffic (below).

jcmd <pid> JFR.start name=LeakDetection duration=15m filename=leak.jfr settings=profile

Common leak sources

• Unbounded caches — a raw ConcurrentHashMap used as a cache with no eviction policy.
• ThreadLocal leaks — pooled threads that never call .remove(); see the fix below.
• Metaspace / ClassLoader leaks — dynamic-proxy frameworks that fail to unload (§08).
• Off-heap / native leaks — direct ByteBuffers or Netty buffers that bypass the heap entirely and are invisible to heap-only tooling; confirm with -XX:NativeMemoryTracking=detail.

// Leak-prone: relies on every code path reaching finally { remove() }
private static final ThreadLocal<UserSession> SESSION = new ThreadLocal<>();
void process(UserSession s) {
    SESSION.set(s);
    try { doWork(); } finally { SESSION.remove(); }   // miss this once, and it leaks
}

// Leak-proof: binding is scoped to run() and cleared automatically on exit
private static final ScopedValue<UserSession> SESSION = ScopedValue.newInstance();
void process(UserSession s) {
    ScopedValue.where(SESSION, s).run(this::doWork);   // no remove() to forget
}

Every flag referenced above, in one table.

Every "gotcha" from the source material, grouped by failure mode. Skim before a design or code review.

Synthesized from these internal Q&A deep-dives. Each contains the full scenario, code walkthroughs, and team-recommendation writeups this reference condenses — pull the original for complete context.

• Shenandoah GC SATB Queue Overflow and Degenerated GC Mitigation2026-07-19
• ZGC Multi-Mapping and RSS Bloat: Tuning 1TB Heaps in Kubernetes2026-07-19
• The SoftReference Cache Trap: ReferenceHandler Bottlenecks and High-Throughput Eviction Redesign2026-07-19
• Metaspace Leak Diagnosis: Classloader Leaks, G1GC Dynamics, and SoftReference Retention in Spring DevTools2026-07-19
• G1GC Humongous Allocation Pathology: Diagnostics, Internals, and Architectural Remedies2026-07-19
• A Java microservice memory leak diagnosis (allocation churn vs. leak, JFR, ScopedValue)2026-07-07
• ClassLoader Leak Diagnosis and GC Eligibility2026-04-07
• ZGC for Low Latency and Epsilon GC's Niche2026-02-24
• Detecting Memory Leaks Caused by Java Threads2026-03-19
• Java's Memory Management for Unreachable Objects: A Deep Dive into Garbage Collection2026-03-22