Advanced Java Garbage Collection Tuning

Optimizing the JVM’s garbage collection (GC) is a critical aspect of ensuring high performance, low latency, and stability for Java applications, especially those handling significant loads or requiring stringent response times.

1. Understanding Garbage Collection Goals

Before tuning, you need to define your application’s performance goals. The primary goals of GC tuning typically revolve around:

• Throughput: The percentage of time the application is running versus the time spent in GC. High throughput is desirable for batch processing or applications where occasional longer pauses are acceptable.
• Latency (Pause Time): The duration for which the application threads are paused during GC cycles. Low latency is crucial for interactive applications or those with strict real-time requirements.
• Footprint: The amount of memory consumed by the JVM. While more memory can sometimes improve GC performance, it can also lead to increased costs and potential swapping if not managed correctly.

It’s often a trade-off between these goals. For instance, optimizing for very low latency might sacrifice some throughput.

2. Choosing the Right Garbage Collector

The Java HotSpot VM provides several garbage collector implementations, each with different characteristics:

• Serial GC (-XX:+UseSerialGC): A simple, single-threaded collector. Best suited for small applications with limited memory or single-processor machines where pauses are not a major concern.
• Parallel GC (-XX:+UseParallelGC): A multi-threaded collector for the young generation, aiming for high throughput. It can still have significant stop-the-world pauses during full GC. Often a good default for server-side applications before Java 9.
• CMS GC (Concurrent Mark Sweep) (-XX:+UseConcMarkSweepGC): Designed to minimize pause times by performing most of the garbage collection work concurrently with the application threads. However, it can suffer from fragmentation and might still have longer “stop-the-world” pauses. Deprecated in Java 9 and later removed.
• G1 (Garbage-First) GC (-XX:+UseG1GC): The default collector since Java 9. It aims to provide a good balance between throughput and low latency, especially for large heaps. G1 divides the heap into regions and prioritizes collecting regions with the most garbage. G1 GC Documentation
• Shenandoah GC (-XX:+UseShenandoahGC): A low-pause-time collector developed by Red Hat. It performs most GC activities concurrently, including compaction, aiming for sub-millisecond pause times even with large heaps. Available in later versions of OpenJDK. JEP 189: Shenandoah GC
• ZGC (-XX:+UseZGC): A scalable, low-latency garbage collector designed for very large heaps (terabytes). It aims for pause times under 10 milliseconds and performs all expensive work concurrently. Available in later versions of OpenJDK. JEP 377: ZGC
• Epsilon GC (-XX:+UseEpsilonGC): A “no-op” garbage collector that only allocates memory and never reclaims it. Useful for very short-lived applications or performance testing where GC interference is undesirable. JEP 318: Epsilon GC

Choosing the right collector depends on your application’s specific requirements. For most modern applications with decent heap sizes, G1 is a good starting point. For applications with very strict latency requirements and large heaps, Shenandoah or ZGC might be more suitable.

3. Heap Sizing (-Xms, -Xmx, -Xmn, -XX:SurvivorRatio, etc.)

Properly sizing the JVM heap is fundamental to GC performance:

• -Xms (Initial Heap Size): Setting this to the same value as -Xmx can prevent resizing pauses during startup.
• -Xmx (Maximum Heap Size): Should be set based on the application’s memory requirements and available resources. Avoid setting it too high, as it can lead to longer GC pauses. A common recommendation is to not let the JVM use more than 75% of the available RAM to avoid swapping.
• -Xmn (Young Generation Size): A larger young generation can reduce the frequency of minor GCs, which are typically less expensive. However, it can also increase the duration of minor GCs.
• -XX:SurvivorRatio: Controls the size ratio between the Eden space and the survivor spaces in the young generation. A higher ratio means a larger Eden space.
• -XX:NewRatio: Controls the ratio between the young and old generations.
• -XX:MaxNewSize: Sets the maximum size of the young generation.

General Guidelines for Heap Sizing:

• Start by profiling your application to understand its memory usage patterns.
• Set -Xms and -Xmx to the same value in production to avoid runtime resizing.
• Experiment with different young generation sizes to find a balance between minor GC frequency and duration.
• Monitor GC logs to see how the different generations are being utilized.

4. Tuning Garbage Collection Parameters

Each garbage collector has specific tuning parameters:

G1 GC Specific Parameters:

• -XX:MaxGCPauseMillis: A soft goal for the maximum GC pause time. G1 will try to meet this goal, potentially at the cost of throughput.
• -XX:InitiatingHeapOccupancyPercent: The percentage of the heap occupancy at which a concurrent GC cycle is started. Lowering this value can start GC earlier but might increase GC frequency.
• -XX:G1NewSizePercent, -XX:G1MaxNewSizePercent: Control the initial and maximum size of the young generation as a percentage of the total heap.
• -XX:G1ReservePercent: Specifies a percentage of the heap to reserve as free space to reduce the risk of promotion failures during GC.
• -XX:ParallelGCThreads: Sets the number of threads used during parallel young generation and full GC phases.
• -XX:ConcGCThreads: Sets the number of threads used for concurrent GC phases.

Shenandoah GC Specific Parameters:

• -XX:ShenandoahGCHeuristics: Controls the heuristics used by Shenandoah to trigger GC cycles.
• -XX:ShenandoahRegionSize: Sets the size of the heap regions.
• -XX:ShenandoahConcurrentGCThreads: Sets the number of threads for concurrent GC phases.

ZGC Specific Parameters:

• -XX:ZAllocationSpikeTolerance: Controls how aggressively ZGC reacts to allocation spikes.
• -XX:ZCollectionInterval: Sets a target interval for GC cycles.
• -XX:ZProactive: Enables proactive GC cycles.

Common Parameters (Applicable to Multiple Collectors):

• -XX:+UseAdaptiveSizePolicy: Enables adaptive sizing of the young generation and survivor spaces (often enabled by default).
• -XX:MaxTenuringThreshold: Specifies the number of minor GC cycles an object can survive before being promoted to the old generation.
• -XX:+PrintGCDetails, -XX:+PrintGCTimeStamps, -Xlog:gc*: Enable detailed GC logging, which is crucial for monitoring and tuning. Enabling GC Logging

5. Monitoring and Analyzing GC Logs

GC logs provide invaluable information about the JVM’s memory management behavior. Analyzing these logs helps identify:

• GC frequency and duration.
• Heap utilization.
• Promotion rates.
• Full GC occurrences.
• Potential memory leaks.

Tools for GC Log Analysis:

• jstat -gcutil <pid> <interval>: A command-line utility to monitor GC statistics in real-time. jstat Documentation
• GCViewer: A standalone graphical tool for visualizing and analyzing GC logs.
• GCEasy: An online GC log analyzer that provides detailed reports and recommendations.
• Java Mission Control (JMC): A comprehensive tool that includes a GC analyzer and other profiling capabilities.
• VisualVM: A visual tool that integrates several JVM monitoring and profiling capabilities, including GC monitoring.

6. Reducing Garbage Creation (Object Churn)

One of the most effective ways to improve GC performance is to reduce the amount of garbage the application generates in the first place:

• Object Pooling: Reusing objects instead of creating new ones, especially for frequently used, short-lived objects.
• Immutability: Using immutable objects can reduce the need for defensive copying and the creation of temporary objects.
• Avoiding Excessive String Concatenation: Use StringBuilder or StringBuffer for building strings in loops to minimize the creation of intermediate String objects.
• Careful Use of Streams: While powerful, streams can sometimes create more intermediate objects than traditional loops. Profile to ensure efficiency.
• Primitive Types: Use primitive types instead of their wrapper objects when nullability is not required to reduce object creation.

7. Considering Off-Heap Memory

For certain use cases, especially those involving large datasets or caching, using off-heap memory (memory managed outside the JVM heap) can reduce the pressure on the garbage collector. Libraries like Ehcache, Hazelcast, and Chronicle Map provide off-heap storage solutions. However, managing off-heap memory requires careful attention to allocation and deallocation.

Best Practices for Advanced GC Tuning:

• Measure Before Tuning: Always establish baseline performance metrics before making any changes to GC settings.
• Tune Incrementally: Make small changes one at a time and monitor the impact.
• Use Realistic Load Tests: Ensure your testing environment accurately reflects production workload.
• Monitor in Production: Continuously monitor GC behavior in your production environment and adjust settings as needed.
• Understand Your Application’s Behavior: Different applications have different memory usage patterns, so there’s no one-size-fits-all GC configuration.
• Keep JVM Updated: Newer JVM versions often include improvements to garbage collection algorithms and performance.
• Disable Explicit GC (-XX:+DisableExplicitGC): Calls to System.gc() can interfere with the JVM’s own GC scheduling and often do more harm than good.

Advanced Java Garbage Collection tuning is an iterative process that requires a deep understanding of your application’s behavior, the available GC algorithms, and the various tuning parameters. By carefully monitoring and analyzing your application’s GC behavior, you can fine-tune the JVM to achieve optimal performance and stability.