Selecting the appropriate garbage collector is the first step in Java GC tuning. Serial, Parallel, G1, ZGC or Shenandoah according to application needs; 2. Enable GC logs (Java 8 uses -XX: PrintGCDetails, Java 9 uses -Xlog) to collect GC behavior data; 3. Monitor key indicators such as pause time, GC frequency, heap usage trend, throughput and object promotion rate, and use tools such as gceasy.io to analyze logs; 4. For frequent young generation GCs, it can be solved by increasing the size of young generations or enabling adaptive strategies; 5. Long-term Full GC should be switched to G1, ZGC or Shenandoah to avoid explicit System.gc() calls; 6. CMS heap fragmentation problems need to be upgraded to G1; 7. High promotion rate or memory leaks require heap dumps to be generated through jmap and analyzed by MAT; 8. Key parameters of G1 tuning include -XX:MaxGCPauseMillis, -XX:InitiatingHeapOccupancyPercent, etc.; 9. Real-time monitoring can use jstat, JConsole, VisualVM or JDK Flight Recorder; 10. For large heap (>32GB) and ultra-low latency requirements, ZGC or Shenandoah should be used; 11. Tuning should be based on production load testing, combined with log analysis, and gradually optimized, and priority should be given to the use of modern JDK default configuration to avoid excessive parameter tuning, and ultimately achieve stable and efficient Java application performance.

Java Garbage Collection (GC) tuning and analysis is essential for optimizing application performance, especially in high-throughput or low-latency systems. Poor GC behavior can lead to long pauses, increased response times, and even application crashes. This guide walks through the key concepts, tools, and best practices for tuning and analyzing Java garbage collection effectively.

Understanding Java Garbage Collectors

Before tuning, you need to understand which garbage collector your application is using. As of Java 17 , the main GCs are:

• Serial GC : Simple, single-threaded; suitable for small applications or embedded systems.
• Parallel GC (Throughput Collector) : Multi-threaded, focuss on high throughput; default in many JVMs.
• G1 GC (Garbage-First) : Designed for large heaps with predictable pause times; default since Java 9.
• ZGC (Scalable Low-Latency GC) : Designed for very large heaps (
• Shenandoah GC : Similar to ZGC, aims for low pause times with concurrent compaction.

Choose the right GC based on your application's latency and throughput requirements.

Example: For a trading platform needing sub-10ms pauses, ZGC or Shenandoah is preferred. For batch processing, Parallel GC may be better.

Enabling and Interpreting GC Logging

The first step in analysis is enabling GC logging to collect data.

Java 8 and Earlier:

 -XX: PrintGCDetails -XX: PrintGCDateStamps -Xloggc:gc.log

Java 9 (Unified Logging):

 -Xlog:gc*,gc heap=debug,gc pause=info:file=gc.log:time,tags

Common log entries include:

• GC cause (eg, "Allocation Failure", "Metadata GC Threshold")
• Heap usage before/after GC
• Pause duration
• Type of GC (Young, Full, Mixed)

Tip: Use -XX: UseGCLogFileRotation with -XX:NumberOfGCLogFiles and -XX:GCLogFileSize for production to avoid huge log files.

Key GC Metrics to Monitor

When analyzing GC logs, focus on these indicators:

• Pause Times : Long Full GC pauses (>1s) are red flags.
• Frequency of GC : Too frequently Young GC may indicate a small Eden space.
• Heap Utilization Trends : Check if old generation usage steadily increases — could signal a memory leak.
• Throughput : Aim for >95% of time spent in application, not GC.
• Promotion Rate : High object promotion to old gen may stress the old generation.

Use tools like GCViewer , gceasy.io , or JDK Mission Control to visualize logs and extract insights.

gceasy.io gives clear charts and recommendations — upload your log and get instant analysis.

Common GC Problems and Tuning Strategies

1. Frequent Minor GCs

• Symptom : Short, frequently Young GCs.
• Cause : Small Eden space or high allocation rate.
• Fix :
  • Increase Young generation size: -Xmn or -XX:NewRatio
  • Consider -XX: UseAdaptiveSizePolicy (enabled by default) to let JVM adjust

2. Long Full GC Pauses

• Symptom : Occasional long pauses (eg, 2 seconds).
• Cause : Old generation full, triggering serial mark-sweep-compact.
• Fix :
  • Switch to G1, ZGC, or Shenandoah
  • If using G1: Tune -XX:MaxGCPauseMillis=200 and monitor mixed GCs
  • Avoid explicit System.gc() calls with -XX: DisableExplicitGC

3. Heap Fragmentation (CMS only)

• Symptom : Concurrent mode failure, promotion failed.
• Fix :
  • Increase old gen size
  • Use G1 instead (CMS deprecated since Java 9)

4. High Promotion Rate / Memory Leaks

• Symptom : Old gen fills up quickly.
• Action :
  • Use heap dump analysis ( jmap -dump:format=b,file=heap.hprof <pid> )
  • Analyze with Eclipse MAT or VisualVM to find retained objects

Advanced Tuning with G1 GC

G1 is often the best balance for medium to large heaps. Key tuning flags:

• -XX:MaxGCPauseMillis=200 – Target max pause (JVM will try to meet this)
• -XX:G1HeapRegionSize – Manually set region size (default auto)
• -XX:G1ReservePercent=10 – Reserve space to reduce evacuation failures
• -XX:InitiatingHeapOccupancyPercent=45 – Start concurrent cycle earlier if old gen >45%

Pro tip: Avoid setting MinHeapFreeRatio and MaxHeapFreeRatio — they can interfere with G1's behavior.

Real-Time Monitoring Tools

In addition to logs, use real-time tools:

• jstat : Quick CLI tool to monitor GC stats

   jstat -gc <pid> 1s

  Watch YGC , YGCT , FGC , FGCT , and OU (old usage).

• JConsole / VisualVM : GUI tools with heap graphs and GC activity.

• JDK Flight Recorder (JFR) : Low-overhead profiling. Start with:

   -XX: FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr

When to Consider ZGC or Shenandoah

If your app requires:

• Heaps > 32GB
• Consistent sub-10ms pauses
• High availability (no long stop-the-world)

Then switch to ZGC:

 -XX: UseZGC -XX: ZUncommit -XX: ZUncommitDelay=300

Or Shenandoah:

 -XX: UseShenandoahGC -XX:ShenandoahGCMode=compact

Both require newer JDKs (ZGC: JDK 11 , Shenandoah: JDK 12 or backported).

Final Tips

• Don't over-tune : Start with default settings, especially with G1/ZGC.
• Reproduct production load : GC behavior varies with load; test under realistic conditions.
• Monitor in production : Use GC logs and metrics as part of observability.
• Update JDK : Newer versions have better GC defaults and fewer bugs.

GC tuning isn't about tweaking every flag — it's about understanding your application's memory behavior and choosing the right collector and heap sizing. With proper logging, monitoring, and iterative testing, you can achieve stable, responsive Java applications.

Basically: log first, analyze, then tune — not the other way around.

The above is the detailed content of A Guide to Java Garbage Collection Tuning and Analysis. For more information, please follow other related articles on the PHP Chinese website!