Choosing the right garbage collector and configuring it properly is the key to optimizing Java application performance. First, select the GC type according to application needs: Serial GC is used for small memory applications, Parallel GC is used for high throughput scenarios, G1 GC is used for large memory and controllable pauses, and ZGC or Shenandoah is used for ultra-low latency requirements (such as financial transactions). 1. Set the heap size reasonably to avoid being too large or too small. It is recommended that -Xms and -Xmx are equal to -Xmx to prevent dynamic expansion; 2. For G1 GC, you can set the target pause time through -XX:MaxGCPauseMillis, adjust -XX:G1HeapRegionSize to deal with large objects, and trigger concurrent marks in advance through -XX:InitiatingHeapOccupancyPercent to avoid Full GC; 3. If you pursue submillisecond pauses, you should use ZGC (JDK 11), configure parameters such as -XX: UseZGC and -Xmx16g, and their pause time is almost not affected by the heap size; 4. Avoid calling System.gc() and disable explicit GC to prevent accidental Full GC, analyzes memory usage, GC frequency and pauses through GC logs and monitoring tools, troubleshoots memory leaks and reduces frequent object creation. The final strategy is: first measure, then select the appropriate collector, and finally finely adjust the parameters so that the GC becomes a performance boost rather than a bottleneck, and ends completely.

Java applications often face performance bottlenecks not from poor code logic, but from inherent memory management. At the heart of this issue lies garbage collection (GC)—a powerful automatic memory reclamation system that, when misconfigured, can cause long pauses, high CPU usage, and unpredictable latency. Tuning garbage collection is essential for high-throughput, low-latency systems. Here's how to do it effectively.

Understanding Java Garbage Collectors

Before tuning, you need to know which garbage collector your JVM is using. Java offers several GC implementations, each suited to different workloads:

• Serial GC : Simple, single-threaded; best for small applications or embedded systems.

  

   -XX: UseSerialGC

• Parallel GC (Throughput Collector) : Multi-threaded, optimized for high throughput. Default on many JVMs.

   -XX: UseParallelGC

• CMS (Concurrent Mark-Sweep) : Low-pause collector, mostly concurrent. Deprecated since Java 9, removed in Java 14.

  

   -XX: UseConcMarkSweepGC

• G1 GC (Garbage-First) : Designed for large heaps (multi-GB) with predictable pause times. Default since Java 9.

   -XX: UseG1GC

• ZGC and Shenandoah : Ultra-low-pause collectors (sub-10ms), scalable to very large heaps (terabytes). Available in newer JDK versions (ZGC from JDK 11 , Shenandoah from JDK 12 ).

   -XX: UseZGC
  -XX: UseShenandoahGC

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

Key Metrics to Monitor

Effective tuning starts with measurement. Use tools like jstat , VisualVM , JConsole , or async-profiler to observe:

• GC frequency and duration : Long or frequent pauses hurt responsiveness.
• Heap usage trends : Watch for steady growth (possible memory leak) or fragmentation.
• Promotion failure or full GCs : Indicate survival space or tenured generation sizing issues.
• CPU overhead from GC threads : Especially relevant with parallel or concurrent collectors.

Enable GC logging to get detailed insights:

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

(For Java 9 ; syntax differences in older versions using -XX: PrintGCDetails , etc.)

Practical Tuning Strategies

1. Size the Heap Appropriately

Avoid setting -Xmx too high or too low.

• Too large : Increases GC pause times, especially with non-concurrent collectors.
• Too small : Causes frequently GCs and potential OutOfMemoryError .

Start with realistic estimates:

 -Xms4g -Xmx4g # Set initial and max heap equal to avoid resizing

2. Tune G1 GC (Commonly Used)

G1 balances throughput and latency. Key tuning flags:

• Target pause time :

   -XX:MaxGCPauseMillis=200

  G1 will try to meet this, possibly at the cost of throughput.

• Adjust region size (only if needed):

   -XX:G1HeapRegionSize=16m

  Useful when dealing with large objects.

• Fine-tune mixed GCs :

   -XX:G1MixedGCCountTarget=8

  Limits number of GCs in a mixed cycle to reduce pause time.

• Control when old regions are collected :

   -XX:InitiatingHeapOccupancyPercent=45

  Start concurrent cycle earlier to avoid full GC.

3. Optimize for Low Latency with ZGC

If sub-millisecond pauses are required, use ZGC:

 -XX: UseZGC -XX:MaxGCPauseMillis=10 -Xmx16g

ZGC scales well with large heaps and keeps pauses nearly constant regardless of heap size. Requires JDK 11 (preferred: JDK 17 for stability).

4. Avoid Common Pitfalls

• Don't force GC with System.gc() : Can trigger full GC unless disabled with -XX: DisableExplicitGC .
• Watch for memory leaks : Use heap dumps ( jmap -dump ) and analyze with tools like Eclipse MAT.
• Avoid excessive object allocation : Reuse objects, use object pools if appropriate (eg, StringBuilder in loops).

When to Consider Alternative Collectors

• High throughput, batch processing? → Stick with Parallel GC .
• Large heap, modern pause requirements? → G1 GC .
• Real-time or low-lateency service (eg, trading, gaming)? → ZGC or Shenandoah .
• Limited resources (small heap)? → Serial GC .

Switching collectors is often more impactful than fine-tuning the wrong one.

Tuning garbage collection isn't about finding magic JVM flags—it's about aligning GC behavior with your application's behavior. Measure first, then adjust. Start with the right collector, set reasonable heap bounds, and use logging to validate improvements. With the right setup, GC goes from a hidden liability to a silent enabler of performance.

Basically, it's not about eliminating GC—it's about making it work for you, not against you.

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