Java Garbage Collection Optimization Strategies and Case Studies

When a Java application cannot meet performance targets and all other tuning avenues are exhausted, adjusting the garbage collector (GC) becomes the final lever for improvement. GC algorithms are complex, with many tunable parameters that depend on the characteristics of the application, making GC optimization challenging.

This article presents a systematic approach to GC tuning, covering preparation, general strategies, and three concrete case studies. It begins with a brief review of JVM memory layout, generational GC concepts, and common collectors (Serial, Parallel, CMS, etc.).

Preparation : Readers should understand basic GC concepts (working principles, young/old generation, promotion, and log interpretation) and recognize that GC tuning is a last‑resort measure.

General workflow : Define optimization goals → apply tuning actions → track results.

Case 1 – Frequent Minor and Major GCs : A service experiences 100 Minor GCs per minute and a Major GC every 4 minutes, causing a 12.5% increase in request latency. By enlarging the young generation (Eden) threefold, Minor GC frequency drops by 60%, Minor GC pause grows by less than 5 ms, and latency percentiles improve by over 10 ms.

Case 2 – GC pauses during traffic peaks : CMS’s Remark phase takes 1.39 s, violating low‑latency requirements. The solution adds the -XX:+CMSScavengeBeforeRemark flag to force a Minor GC before Remark, eliminating pauses longer than 200 ms.

Case 3 – Full GC (STW) caused by PermGen expansion : Full GC pauses of 1.23 s are traced to PermGen growth. Fixes include fixing PermGen size at startup (setting -XX:PermSize and -XX:MaxPermSize equal) or enabling CMS to collect PermGen. The chosen approach fixes the size, preventing further STW events.

Across all cases, the key takeaways are: tune generation sizes according to object‑lifetime distribution, use dynamic age thresholds wisely, and leverage CMS‑specific flags to control pause times. Proper GC tuning should follow a deep understanding of collector internals rather than blind parameter changes.

The article concludes with a reminder that GC optimization is a complex, system‑level activity that should be pursued only after exhausting architectural and code‑level improvements.