Why Garbage Collection Tuning Matters
Java's automatic memory management is one of its greatest strengths — and one of its most misunderstood aspects. The Garbage Collector (GC) reclaims memory occupied by objects that are no longer reachable, but this process takes CPU time and can introduce stop-the-world pauses that degrade user experience in latency-sensitive applications. Understanding your GC options lets you trade off throughput, latency, and memory overhead intelligently.
The Generational Hypothesis
Most JVM GCs are built on a key observation: most objects die young. Memory is split into generations:
- Young Generation (Eden + Survivor spaces): New objects are allocated here. Minor GCs run frequently and collect mostly short-lived objects cheaply.
- Old Generation (Tenured): Long-lived objects are promoted here. Major (full) GCs are more expensive and less frequent.
- Metaspace: Stores class metadata (replaced PermGen in Java 8+).
Choosing a Garbage Collector
| Collector | Goal | Best For | Available Since |
|---|---|---|---|
| Serial GC | Simplicity | Single-core, small apps | Java 1 |
| Parallel GC | Maximum throughput | Batch processing, data pipelines | Java 1.4 |
| G1 GC | Balanced latency/throughput | Most server applications | Java 7 (default since 9) |
| ZGC | Ultra-low latency (<1 ms pauses) | Large heaps, latency-critical apps | Java 11 (production: 15) |
| Shenandoah | Low latency | Similar to ZGC, RedHat-led | Java 12 |
Essential G1 GC Tuning Flags
G1 is the default collector for most Java 9+ applications and the right starting point for tuning:
-XX:MaxGCPauseMillis=200— Sets the target maximum pause time (default 200 ms). Lower values make G1 collect more frequently in smaller chunks.-Xms/-Xmx— Set initial and maximum heap size. Keep them equal to avoid heap resizing overhead in production.-XX:G1HeapRegionSize=N— Tune region size (1–32 MB, power of 2) for very large or small heaps.-XX:InitiatingHeapOccupancyPercent=45— Percentage of heap occupancy that triggers a concurrent marking cycle. Lower values start GC sooner, reducing the chance of full GC.
Switching to ZGC or Shenandoah
If G1 pause times still exceed your SLA, consider a low-latency collector:
# Enable ZGC
-XX:+UseZGC
# Enable Shenandoah (OpenJDK builds)
-XX:+UseShenandoahGCBoth collectors do most of their work concurrently with your application threads, keeping pause times in the sub-millisecond range regardless of heap size. The trade-off is slightly higher CPU usage during concurrent phases.
How to Diagnose GC Problems
- Enable GC logging:
-Xlog:gc*:file=gc.log:time,uptime - Analyse logs with GCViewer or GCeasy.io (free online tool).
- Look for frequent full GCs, long pause times, and high promotion failure rates.
- Profile heap allocation with Java Flight Recorder (JFR) and JDK Mission Control (JMC).
- Identify allocation hot spots — often, reducing object churn is more effective than tuning the collector.
Key Takeaways
Start with G1 and its defaults — they are well-calibrated for general workloads. Profile before tuning; premature GC tuning is a common source of new problems. If pause times are genuinely an issue, ZGC or Shenandoah offer impressive low-latency characteristics with minimal configuration on modern JVM versions.