Comprehensive Guide to Java CMS Garbage Collection Issues and Optimization

This article provides an in-depth analysis of Java HotSpot CMS (Concurrent Mark‑Sweep) garbage collection, covering its fundamentals, common problem scenarios, root‑cause analysis, and practical optimization strategies.

1. Overview of GC

GC is a core technology for automatic memory management in Java. The article explains basic concepts such as GC, mutator, TLAB, card table, and the three classic algorithms (Mark‑Sweep, Mark‑Compact, Copying).

2. JVM Memory Layout

It describes the heap structure (Young, Old, MetaSpace) and how CMS operates on the Old generation while using a generational approach.

3. Common CMS Problem Scenarios

Dynamic space expansion/shrinkage ("Space Shock")

Explicit System.gc calls

MetaSpace OOM

Premature promotion ("Premature GC")

Frequent CMS Old GC

Long‑lasting CMS Full GC (Mark‑Sweep‑Compact)

Memory fragmentation and collector degradation

Direct (off‑heap) memory OOM

JNI‑induced GC pauses (GCLocker)

4. Code Examples

Example of GC cause conversion:

const char* GCCause::to_string(GCCause::Cause cause) { switch (cause) { case _java_lang_system_gc: return "System.gc()"; case _full_gc_alot: return "FullGCAlot"; /* ... other cases ... */ default: return "unknown GCCause"; } ShouldNotReachHere(); }

CMS collector decision logic (simplified):

bool CMSCollector::shouldConcurrentCollect() { if (_full_gc_requested) return true; if (!UseCMSInitiatingOccupancyOnly) { if (stats().time_until_cms_start() == 0.0) return true; } if (_cmsGen->should_concurrent_collect()) return true; if (heap->incremental_collection_will_fail(true)) return true; if (CMSTriggerInterval >= 0) { if (stats().cms_time_since_begin() >= (CMSTriggerInterval / MILLIUNITS)) return true; } return false; }

5. Diagnosis and Root‑Cause Analysis

The article recommends a systematic workflow: define performance thresholds, retain heap dumps and GC logs, perform temporal correlation, probability analysis, experiment verification, and reverse‑causality checks. Tools such as jstat, jcmd, jmap, MAT, JProfiler, GCeasy, HeapHero, and FastThread are suggested.

6. Optimization Strategies

Stabilize heap size (set -Xms = -Xmx) to avoid frequent resizing.

Adjust CMS parameters: -XX:CMSInitiatingOccupancyFraction, -XX:+UseCMSInitiatingOccupancyOnly, -XX:CMSFullGCsBeforeCompaction, -XX:+CMSClassUnloadingEnabled.

Resize Young/Old generations based on observed survivor size and promotion rate.

Enable parallel reference processing (-XX:+ParallelRefProcEnabled) and concurrent class unloading (-XX:+ExplicitGCInvokesConcurrent).

Monitor and limit direct memory usage (track java.nio.Bits.totalCapacity, Netty's DIRECT_MEMORY_COUNTER).

Disable explicit GC only when safe (-XX:+DisableExplicitGC) and prefer -XX:+ExplicitGCInvokesConcurrent.

Upgrade to newer collectors (G1, ZGC) when appropriate.

7. Practical Tips

Use -XX:+PrintReferenceGC and -XX:+PrintJNIGCStalls to pinpoint reference‑related pauses.

Leverage Native Memory Tracking (NMT) with jcmd VM.native_memory detail to locate off‑heap leaks.

Apply the “5 Whys” method and the provided fishbone diagram to isolate root causes.

8. Summary

Effective GC tuning requires understanding both JVM internals and application behavior. By following the outlined diagnostic flow, controlling variables during experiments, and applying targeted JVM flags, most CMS‑related performance issues can be resolved or mitigated.