Garbage collection (GC) tuning has long been regarded as one of the most complex aspects of Java performance engineering. Historically, developers spent days tweaking obscure JVM command-line flags to balance throughput and pause latency. Fortunately, modern Java has simplified this landscape. In 2026, for applications running on JDK 21 or later, the decision has largely come down to choosing between two highly optimized garbage collectors: the Garbage-First Garbage Collector (G1GC) and the Z Garbage Collector (ZGC).
To make the right choice for your workload, it is essential to understand their underlying architectures, how they trade off performance, and the massive impact of Generational ZGC.
G1GC: The Throughput-Optimized Standard
G1GC is the default garbage collector in modern JDKs. It is designed for multi-processor machines with large memory spaces. G1GC divides the Java heap into equal-sized virtual regions. It tracks the amount of live data in these regions and prioritizes collecting regions with the most garbage first (hence "Garbage-First").
G1GC is generational by default, separating the heap into Eden, Survivor, and Old generations to take advantage of the weak generational hypothesis (the fact that most objects die young). While G1GC performs much of its work concurrently, it still relies on short Stop-The-World (STW) pauses to complete collection phases.
G1GC’s main strength is throughput. By allowing small, predictable pause times (usually ranging from 10 to 100 milliseconds), it maximizes the CPU cycles dedicated to running actual application code. It also has a relatively low memory overhead, typically requiring only 5% to 10% of the heap for GC metadata.
ZGC: The Ultra-Low Latency Revolution
ZGC is a scalable, low-latency garbage collector designed to handle heaps ranging from a few hundred megabytes to multiple terabytes. Unlike G1GC, ZGC performs all of its heavy lifting—marking, compaction, and reference processing—concurrently with the application threads.
ZGC achieves this using colored pointers (storing metadata in the unused bits of object references) and load barriers (intercepting object reads to ensure the application thread always sees the correct memory location).
The headline feature of ZGC is its pause time: it guarantees sub-millisecond pause latencies, often measured in microseconds, regardless of the size of your heap. Whether you are running a 2GB heap or a 2TB heap, your pause times remain negligible.
Generational ZGC (JDK 21+)
In JDK 21, ZGC took a massive leap forward with the introduction of Generational ZGC, enabled using:
-XX:+UseZGC -XX:+ZGenerational
Before Generational ZGC, the collector treated all objects equally. Collecting young and old objects together meant ZGC had to scan the entire heap frequently, which consumed significant CPU. Generational ZGC solves this by maintaining separate generations for young and old objects.
With Generational ZGC, young-generation collections happen frequently and concurrently, requiring very little CPU overhead. This dramatically improves throughput while maintaining ZGC's sub-millisecond pause times. It makes ZGC competitive with G1GC even for throughput-intensive applications.
Comparing the Metrics
When evaluating G1GC vs. ZGC, consider these core metrics:
- Pause Latency:
- ZGC: Sub-millisecond (typically under 200 microseconds).
- G1GC: 10 to 100 milliseconds, occasionally spiking higher depending on heap size and tuning.
- Throughput:
- G1GC: Excellent. It remains the gold standard for pure batch processing or compute-heavy workloads.
- ZGC: Generational ZGC is within 1% to 5% of G1GC's throughput for most workloads, making it viable for almost all web applications.
- Memory Overhead:
- G1GC: Low. Requires minimal extra RAM.
- ZGC: Moderate. Because ZGC runs concurrently, it requires a larger memory head-room to prevent "allocation stalls" (where application threads produce garbage faster than ZGC can clean it). It is recommended to allocate 20% to 30% more memory for ZGC compared to G1GC.
Decision Matrix: G1GC or ZGC?
To choose the best collector for your application, use these guidelines:
Choose G1GC if:
- You are running a batch processing job, data pipeline, or offline calculation where raw throughput is critical, and pause times do not impact users.
- Your application runs in a highly resource-constrained environment (like a small Docker container with less than 2GB of RAM).
- You are satisfied with the default behavior and do not want to allocate extra RAM overhead for GC.
Choose Generational ZGC if:
- You run interactive, low-latency web services, microservices (e.g., Spring Boot, Quarkus), or APIs where response-time consistency (p99 and p99.9 latency) is critical.
- Your application has a large heap (above 4GB to 8GB) and you want to avoid long garbage collection pauses.
- You want to eliminate p99 latency spikes caused by GC without spending weeks tuning parameters.
For most modern Indian startups and enterprise APIs running on AWS or Azure, response time is a key business metric. Upgrading to JDK 21+ and enabling Generational ZGC is one of the easiest ways to improve your API metrics overnight.