Skip to content
JVM Atlas

Guide

How does garbage collection work in the JVM?

How the JVM reclaims memory: GC roots and reachability, marking, sweeping and compaction, the difference between eligible and reclaimed objects, and HotSpot’s collectors.

Garbage collector

JVM specification

Automatic storage management: finds objects the program can no longer reach and reclaims their memory.

Simply put

You create objects but never delete them. The garbage collector periodically finds objects that nothing in your program can reach any more and reuses their memory.

What a developer sees

You never free memory yourself. When no chain of references from a GC root (a local variable of a running method, a static field, a JNI reference or one of the JVM’s own internal roots) leads to an object any more, a later collection reclaims its memory. HotSpot JDK 25 picks G1 by default on server-class machines and Serial on small ones (for example, with a single CPU); -XX:+UseZGC selects ZGC for very short pauses, and java -Xlog:gc prints every collection.

A memory leak in Java is an object that stays reachable by mistake, for example in a cache that only ever grows.

Picture it

Clearing up helium balloons after a party. Balloons whose strings someone is holding stay. Balloons nobody holds, even ones tied to each other, are cleared away when the cleaners come round.

People holding strings

GC roots: local variables of running methods, static fields, JNI references and the JVM’s own internal roots

A string

A reference

A balloon

An object

The cleaners’ round

A garbage collection

Where the picture stops working

Collectors do not inspect balloons one by one: they follow the strings from the roots and treat everything they did not reach as garbage, and many also move the surviving objects closer together. When the cleaners come round is the collector’s decision, not the program’s.

Deep dive: the specification and HotSpot in detail

JVMS §2.5.3 requires heap storage to be reclaimed by an automatic storage management system and mandates no technique. Collectors start from , determine , and reclaim the rest by sweeping, compacting or evacuating. HotSpot JDK 25 selects G1 on server-class machines (at least 2 CPUs and about 1.8 GB of memory) and Serial otherwise (gcConfig.cpp, os::is_server_class_machine). Collectors coordinate with application threads through and through barriers compiled into field accesses.

The specification requires

Automatic reclamation is required; the technique, timing and pauses are not specified.

HotSpot (JDK 25) does

HotSpot JDK 25: Serial, Parallel, G1 (default), ZGC, Shenandoah, Epsilon.

Common misconceptions

  • An object is collected as soon as it becomes unreachable.

    It becomes eligible. It is reclaimed during some later collection, or never if the program ends first. Reachability decides eligibility, not timing.

  • `System.gc()` runs the garbage collector immediately.

    It is a request the JVM may honour or ignore (-XX:+DisableExplicitGC); never rely on it for correctness.

Sources

GC roots

JVM specification

References the collector treats as live by definition: thread stacks, static fields, JNI handles and VM internals.

Simply put

The starting points of the search for live objects: variables in running methods, static fields of loaded classes, and a few references held by the JVM itself. Anything reachable from a root is kept.

Deep dive: the specification and HotSpot in detail

Roots include: references in the local variables and operand stacks of every thread's frames (located precisely using stack maps / oop maps), static fields (held in Class mirrors reachable from loaded classes and their loaders), JNI local and global references, objects used as monitors, references embedded in compiled code, and VM-internal tables. Generational and regional collectors also treat references from outside the collected area as roots for that collection (G1 remembered sets, card tables).

Common misconceptions

  • Objects referencing each other in a cycle can never be collected.

    Tracing collectors start from roots; an unreachable cycle is garbage like any other object.

Sources

HotSpot collectors

HotSpot · JDK 25

Six interchangeable implementations, selected with -XX:+Use…GC; G1 is the default on server-class machines.

Simply put

HotSpot ships several garbage collectors with different trade-offs. You pick one when starting the JVM; most applications keep the default, G1.

Deep dive: the specification and HotSpot in detail

Exactly one collector is active per JVM: Serial, Parallel, G1, ZGC, Shenandoah (included in OpenJDK builds from most vendors, but not in Oracle JDK builds) or Epsilon (experimental, no reclamation). Without an explicit choice HotSpot uses G1 on server-class machines and Serial otherwise.

Which collector is running?Shell
$ java -Xlog:gc -version

Verified with OpenJDK 25.0.4 · Linux x64 · 4 CPUs

Common misconceptions

  • A newer collector is always better.

    Each optimizes something different; ZGC trades some throughput and memory for low latency, Parallel the reverse.

Sources

Related guides

JVM Atlas

Explore the machine behind Java programs. A free, open-source atlas of the Java Virtual Machine. Specification baseline: Java SE 25. Implementation details: OpenJDK HotSpot, JDK 25.

MIT licensed · no accounts, no tracking, no backend · your progress stays in your browser.

JVM Atlas is an independent educational project and is not affiliated with or endorsed by Oracle. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.