The core of Java garbage collection tuning in low-latency scenarios is to reduce GC pause time and avoid frequent Full GC. 1. Choose a suitable garbage collector, such as ZGC (JDK 11) or Shenandoah (JDK 8u255 /JDK 15), suitable for low-latency scenarios; G1 is suitable for medium-sized systems; older versions of JDK are not suitable for response-sensitive services. 2. Reasonably set the ratio of heap memory and the new generation, keep the initial heap consistent with the largest heap, and appropriately increase the space of the new generation. The proportion of the old generation is recommended to be 3:7, such as -Xms4g -Xmx4g -Xmn1g. 3. Control the life cycle of the object, reduce temporary object creation, and optimize code through object pooling, ThreadLocal, and avoid creating objects in loops. 4. Monitor and analyze GC logs, enable parameters such as -XX: PrintGCDetails, and use tools such as jstat, GCViewer, Prometheus Grafana to assist in analysis and tuning.

The core of Java garbage collection tuning in low-latency scenarios is to reduce GC pause time and avoid frequent triggering of Full GC. The key points are to choose the right garbage collector, set the heap memory size reasonably, and control the object life cycle.

Choose a garbage collector that is suitable for low latency

Different versions of Java support different GC strategies, but if you are pursuing low latency, ZGC or Shenandoah is the first choice. They are all concurrent marking collation algorithms that can complete most of GC work in milliseconds without causing obvious pauses.

• ZGC (JDK 11) : Suitable for applications with heap memory from several hundred MB to TB, with a pause time usually within 10ms.
• Shenandoah (JDK 8u255, JDK 15) : It also focuses on low latency and is suitable for medium and large heap memory applications.
• G1 (Garbage First) : Although it is not as low latency as the previous two, it performs stably and has a more mature configuration in most medium-sized systems.

If you are using an old version of JDK, such as JDK 8, the default is the Parallel Scavenge Serial Old combination. This combination has high throughput but high latency and is not suitable for services that are sensitive to response time.

Reasonably set the heap memory and the new generation ratio

The larger the heap memory, the better, especially in low-latency scenarios. Too large will cause the GC to be longer, especially when Full GC occurs, where the pause time may soar.

Recommended practices:

• Set the initial heap (-Xms) and the maximum heap (-Xmx) to the same value to avoid performance fluctuations caused by dynamic capacity expansion during runtime.
• Appropriately increase the Ceponymous (-Xmn) so that short-lived objects can be recycled in the Eden area, reducing the number of objects promoted to the elderly.
• The proportion of the elderly is recommended to remain at around 3:7 , which means that the new generation accounts for about 30% of the entire heap, which can be adjusted according to the actual object life cycle.

For example: If your JVM total heap is set to 4G, you can consider -Xms4g -Xmx4g -Xmn1g , so that the Eden area can have about 600MB~800MB, which is enough to deal with most short-term objects.

Controls the frequency and life cycle of object creation

Many low-latency problems are actually not a problem with GC itself, but rather that programs frequently create temporary objects, resulting in frequent triggering of GC. This problem needs to be optimized from the code level.

Common practices include:

• Try to reuse objects, such as using object pools or ThreadLocal caches.
• Reduce unnecessary packing and unboxing operations to avoid temporary objects generated by automatic packing.
• Use WeakHashMap to manage cached data to avoid long-term memory occupancy.
• Avoid frequent creation of objects in the loop body.

For example, splicing the string log.info("user=" user) in the log output will generate a new String object every time, and replacing it with log.info("user={}", user) can effectively reduce GC pressure.

Monitoring and analyzing GC logs are the basis for tuning

Blindly tuning without reading the GC log is basically equivalent to guessing blindly. It is recommended to turn on the following parameters to record GC:

 -XX: PrintGCDetails -XX: PrintGCDateStamps -Xloggc:/path/to/gc.log

Some tools can also be used to assist in analysis, such as:

• jstat : View GC statistics in real time.
• GCViewer or GCEasy : Visualize analysis of log files.
• Prometheus Grafana : Used with JVM Exporter to implement monitoring alarms.

Through these methods, you can clearly see the time, frequency, and object allocation rate of each GC, thereby adjusting the parameters in a targeted manner.

Basically all this is it. Low-latency tuning is not something that can be achieved overnight. It requires comprehensive judgment based on business characteristics, GC behavior and code behavior.

The above is the detailed content of Java Garbage Collection Tuning for Low Latency. For more information, please follow other related articles on the PHP Chinese website!