YGC is too frequent and the solution

Frequent Young GC (YGC) usually reflects problems with JVM's young generation memory configuration or object allocation mechanism. The following are targeted troubleshooting and optimization solutions:

1. Quickly locate the bottleneck

Real-time monitoring of indicators

# Gather GC data every 2 seconds (replace PID)jstat -gcutil &lt;pid&gt; 2000

# Interpretation of key indicators:- YGCT: Young GCTotal time consumption
- YGC: Young GCfrequency
- EU/S0/S1: Eden/SurvivorArea usage rate

Normal situation: The time to take a single YGC should be <50ms, and the number of YGCs within 1 minute is <5 times.

GC log analysis

Start parameter append:

-Xlog:gc*=debug:file=:time,uptime,level,tags:filecount=5,filesize=100m

useGCeasyOnline analysis of logs, focusing on:

Object promotion rate（Promotion Rate）
GC is triggered by allocation failure（Allocation Failure）

2. Core optimization strategy

A. Memory structure adjustment

parameter	Typical scenarios	Calculation formula
-XX:NewRatio=3	The ratio of the older generation to the younger generation is 3:1	NewSize=Heap/(NewRatio+1)
-XX:SurvivorRatio=8	Eden to a single Survivor area ratio 8:1:1	Eden = Young/(SurvivorRatio+2)

Dynamic computing tools:

useJVM Heap CalculatorVisual adjustments

B. Allocation rate optimization

1. Object pooling

Use object pooling for frequently created short lifecycle objects (such as DTO):

// Use Apache Commons PoolGenericObjectPool&lt;Request&gt; pool = new GenericObjectPool&lt;&gt;(new BasePooledObjectFactory&lt;&gt;() {
    @Override public Request create() { return new Request(); }
});

2. Heap out-of-memory

Use DirectByteBuffer for large temporary data:

ByteBuffer buffer = (1024 * 1024); // 1MB off-heap

C. Collector special optimization

G1 Tuning(Recommended JDK8+)

-XX:+UseG1GC 
-XX:MaxGCPauseMillis=200        # Target pause time-XX:G1NewSizePercent=30        # The minimum proportion of young generation-XX:G1MaxNewSizePercent=60     # The largest proportion of young generations

ZGC low latency solution（JDK15+）

-XX:+UseZGC -XX:ZAllocationSpikeTolerance=5.0

3. Exception scene processing

Case 1: Premature Promotion

Phenomenon: Survivor area frequently overflows, and the object enters the old age too early

solve：

-XX:TargetSurvivorRatio=60   # Control Survivor space utilization-XX:+NeverTenure             # Direct promotion is prohibited（G1Available）

Case 2: Memory Leak

Heap dump analysis

jmap -dump:live,format=b,file= <pid>

Check with MAT toolRetained HeapThe largest object

Weak reference monitoring

WeakReference&lt;Object&gt; ref = new WeakReference&lt;&gt;(largeObj);
if (() == null) ("Object has been recycled");

4. Ultimate emergency plan

When the code cannot be modified immediately,Memory first aid measures：

# Temporary expansion of young generation (no restarting JVM)jcmd &lt;pid&gt; VM.set_flag -XX:NewSize=512m
jcmd &lt;pid&gt; VM.set_flag -XX:MaxNewSize=512m

# Force-start Full GC recycling for the elderly (use with caution)jcmd &lt;pid&gt;

Optimize verification process：

Use JMH to do GC stress test
Comparison before and after optimizationjstatYGC frequency drop ratio
Observe business TPS fluctuations through APM tools (Arthas)

Through the above methods, the YGC frequency can usually be reduced by 50%-90%. If there are still exceptions, the memory allocation path analysis needs to be performed in combination with specific business code.

Summarize

The above is personal experience. I hope you can give you a reference and I hope you can support me more.