A Comprehensive Overview of Java Garbage Collection Algorithms and ZGC

The article begins with an introduction to the necessity of garbage collection (GC) in the HotSpot JVM, outlining the basic steps of identifying unreachable objects and reclaiming their memory.

It then describes classic GC techniques:

Reference counting – simple but cannot resolve cyclic references.

Reachability analysis – marks objects reachable from GC roots; objects not reachable are considered dead.

Next, it explains several fundamental algorithms:

Mark‑Sweep – marks live objects then sweeps dead ones; suffers from fragmentation.

Copying (used in young generation) – splits the heap into Eden and Survivor spaces, copying live objects to a new region.

Mark‑Compact – similar to Mark‑Sweep but compacts live objects to eliminate fragmentation.

These concepts lead to a discussion of generational collection, which combines the above algorithms to handle young and old generations separately.

The article then surveys major JVM collectors:

Serial Collector : single‑threaded, stops all application threads during both marking and sweeping; suitable for client‑mode or single‑CPU environments.

ParNew Collector : multithreaded version of Serial, works well with CMS in server mode.

Parallel Scavenge : multithreaded young‑generation collector aiming for high throughput.

Serial Old : single‑threaded old‑generation collector, often paired with Serial Scavenge.

Parallel Old : multithreaded old‑generation collector, paired with Parallel Scavenge.

CMS (Concurrent Mark‑Sweep) : focuses on low pause times by performing most work concurrently; drawbacks include high CPU usage and inability to handle floating garbage.

G1 (Garbage‑First) : region‑based collector that combines parallelism, concurrency, and predictive pause‑time goals; uses both marking‑compact and copying within regions.

Finally, the article introduces ZGC (Z Garbage Collector), a low‑latency collector first experimental in JDK 11 and production‑ready since JDK 15. ZGC operates in three concurrent phases—marking, relocation, and relocation cleanup—using read barriers and colored pointers (Marked0, Marked1, Remapped, Finalizable) to minimize stop‑the‑world pauses. It supports large heaps (up to 4 TB addressable, theoretically 16 TB), NUMA‑aware allocation, and offers advantages such as immediate region reclamation, reduced memory barriers, and extensible pointer metadata. However, ZGC has limitations: it struggles with very high allocation rates, may have lower overall throughput compared to G1, and can suffer from “floating garbage” when allocation outpaces collection.

The article concludes that ZGC builds upon previous GC ideas, combining concurrent marking and relocation with innovative techniques like read barriers and colored pointers, but it is not a universal solution; developers must weigh its low‑latency benefits against its throughput and allocation‑rate constraints.