How to Pick the Best Java HotSpot GC: Serial, Parallel, CMS, G1 & ZGC

Overview

HotSpot JVM offers a variety of garbage collectors, each with distinct characteristics. Selecting the most appropriate collector depends on the application’s workload, latency requirements, and hardware resources.

Serial Collector

Serial is a single‑threaded collector that uses the copy algorithm for the young generation. It pauses all application threads during GC, making it suitable for client‑side applications with small heaps where pause times are short and noticeable latency is minimal.

ParNew Collector

ParNew is the multithreaded version of Serial. It runs multiple GC threads in parallel, reducing collection time on multi‑CPU servers, but still stops all user threads during the collection phase. It is best for environments with several CPUs where throughput matters more than absolute pause time.

Parallel Scavenge Collector

Parallel Scavenge also targets the young generation with a multithreaded copy algorithm, but its primary goal is maximizing CPU throughput rather than minimizing pause time. It is ideal for background compute workloads that do not require frequent user interaction.

Key JVM flags: -XX:GCTimeRatio – sets the desired ratio of GC time to total time (inverse of throughput). -XX:MaxGCPauseMillis – specifies the maximum pause duration; the collector adjusts the young‑generation size accordingly. -XX:+UseAdaptiveSizePolicy – enables automatic tuning of heap regions based on the above parameters.

Old Generation Collectors

Serial Old and Parallel Old are the old‑generation counterparts of Serial and Parallel Scavenge, respectively, both using the mark‑compact algorithm. Serial Old is single‑threaded, while Parallel Old runs multiple GC threads to improve throughput.

CMS (Concurrent Mark‑Sweep) aims for the shortest pause times by performing most of its work concurrently with application threads. Its phases include Initial Mark (STW), Concurrent Mark, Remark (STW), and Concurrent Sweep. While CMS reduces pause latency, it suffers from lower throughput, inability to collect “floating” garbage efficiently, and fragmentation due to its mark‑sweep algorithm.

CMS drawbacks:

Lower throughput because of concurrent thread switching overhead.

Can trigger frequent Full GCs when floating garbage accumulates.

Fragmentation from the mark‑sweep approach; mitigated with -XX:+UseCMSCompactAtFullCollection and -XX:CMSFullGCsBeforeCompaction.

CMS was deprecated starting with Java 9 in favor of newer collectors.

Three‑Color Marking and Leak Problem

The three‑color algorithm classifies objects as white (unvisited), gray (marked but children not yet processed), and black (fully processed). A leak can occur when a black object points to an unmarked white object that becomes unreachable, causing the white object to be missed during the collection cycle.

G1 (Garbage‑First) Collector

G1 is a modern collector that works across both young and old generations. It divides the heap into equal‑sized regions and prioritizes reclaiming regions with the most garbage, achieving predictable pause times.

Key concepts:

Remembered Set – each region records references to objects in other regions, allowing the collector to avoid scanning the entire heap.

G1 phases:

Initial Mark – STW, marks objects directly reachable from GC roots.

Concurrent Mark – runs in parallel with application threads to perform a full reachability analysis.

Final Mark – STW, captures objects allocated during the concurrent phase.

Evacuation (or “Cleanup”) – STW, evacuates live objects and compacts the heap.

ZGC (Z Garbage Collector)

ZGC, introduced in Java 11, targets ultra‑low pause times (≤10 ms) even for multi‑terabyte heaps (up to 16 TB in later releases). It is a non‑generational collector that uses colored pointers stored in object references rather than object headers.

Key features:

Uses load‑linked/store‑conditional techniques to relocate objects without stopping the world.

Supports NUMA‑aware allocation and UMA (unified memory architecture) optimizations.

ZGC phases:

Pause Mark Start

Concurrent Mark

Relocate

Remap – updates references via a write barrier (different from JMM barriers) and employs a read barrier for safety.

While ZGC dramatically reduces pause times, it may increase overall CPU usage and still performs some STW work during the final phases.