Code10x
Garbage collectionmedium3-5 years

A service's G1 GC log shows frequent young collections tagged `(G1 Humongous Allocation)`, and separately, over a few hours, GC time climbs toward 100% of wall-clock time with each collection recovering almost nothing. Are these the same problem? What's the fix for each?

No — they're two different failure shapes that happen to both show up in a GC log, and confusing them leads to the wrong fix. Humongous allocation is about object size: G1 divides the heap into equal-sized regions, and any single object half a region or larger — a big byte array, a large JSON string, a resized hash table — skips the young generation entirely and goes straight into contiguous old-generation regions, which can trigger a young collection just to make room and fragments the old generation over time. A GC storm is about the live set being too close to the heap's total capacity: nearly everything survives every young collection, the old generation fills, a full collection runs and frees almost nothing, and the next one starts almost immediately — GC time approaches 100% of wall time. Humongous objects are fixed by a bigger region size or by streaming instead of buffering large data; a GC storm is fixed by finding what grew the live set (an unbounded cache, a leak, or genuinely more data than the heap was sized for) — a bigger heap only postpones a storm by the size of the increase, it doesn't fix the cause.

The lesson behind it →
PreviousA code review comment says "this method allocates a small, short-lived object every call in a hot loop — that's going to hurt GC." Is that always true in Java, and what would you actually check before rewriting the code to avoid the allocation?Next G1's young collections only scan eden and survivor spaces, not the whole heap — that's how they stay fast. But an object in eden can be kept alive by a reference sitting in the old generation. How does a 'partial' collection find that reference without scanning the old generation on every single pause?
More on Garbage collection
G1's young collections only scan eden and survivor spaces, not the whole heap — that's how they stay fast. But an object in eden can be kept alive by a reference sitting in the old generation. How does a 'partial' collection find that reference without scanning the old generation on every single pause?