The road is long and arduous, but keep moving to reach your goal.
This article explains why fixing G1's young generation size with -Xmn or percentage flags often harms performance, and demonstrates how to tune young GC by analyzing pause targets, Eden sizing, TLAB/PLAB logs, and object promotion patterns to let G1's adaptive sizing balance throughput and latency.
This article teaches how to analyze G1 GC logs beyond simple pause times by breaking down phase timings, heap changes, GC causes, and concurrent marking overhead, then mapping log signals like high Update RS or Object Copy to concrete code-level issues such as excessive reference writes, humongous allocations, or weak reference abuse.
Humongous objects in Java's G1 collector are large allocations that require a contiguous set of heap regions, bypass the young generation, inflate old‑generation usage, trigger frequent Young, Mixed or Full GCs, and can dominate CPU and pause time unless the code is refactored or the region size is tuned.
Mixed GC in G1 only reclaims a portion of the Old generation that fits within the pause‑time budget, so seeing the Old region size stay high after a mixed pause does not mean G1 has failed, but rather reflects collection cost, survival rates, and budgeting constraints.
The article explains how to safely adjust JVM parameters for large‑scale e‑commerce events by first calculating the total container memory usage, using targeted G1GC tweaks, validating changes with load tests and metrics, and preparing a detailed gray‑release and rollback plan.
During a major sales promotion, a sudden P99 latency jump can tempt teams to tweak JVM settings, but this article shows how to build a three‑layer evidence chain—GC logs, JFR, business and container metrics—to confirm whether the JVM is truly at fault before making any parameter changes.
