Code10x
Memory and OOMeasy0-2 years

`jstat -gcutil` on a struggling service shows the old generation climbing over hours: 20%, 40%, 60%, and now full GCs are starting. A teammate says "that just means the heap is too small, bump -Xmx." How do you tell a leak from an undersized heap from this kind of trace, and why does the fix matter?

The tell is the floor, not the peak: watch the old generation's lowest point right after each collection, not how high it gets between collections. A busy but healthy service can touch 90% before a collection and still be fine, as long as it comes back down afterward — that's a sawtooth. A leak's floor never comes back down; it rises collection after collection, and full GCs start appearing and reclaiming nothing, because everything they're looking at is still reachable. An undersized heap looks similar for a moment but the floor settles at a stable, if uncomfortably high, level rather than climbing forever. The fix matters because they need opposite responses: a bigger heap fixes an undersized one, but for a real leak it only buys time before the same crash, and it makes each full GC pause longer while doing it — a leak that used to crash in three days now crashes in six and pauses for four times as long.

The lesson behind it →
Next A heap dump's dominator tree ranks a `Map` object at the top by retained size, but its own shallow size is 48 bytes — smaller than almost everything else in the heap. A teammate is confused: "how can something that small be the leak?" Walk through what retained size means and why sorting by it, not shallow size, is what actually finds the root cause.
More on Memory and OOM
A heap dump's dominator tree ranks a `Map` object at the top by retained size, but its own shallow size is 48 bytes — smaller than almost everything else in the heap. A teammate is confused: "how can something that small be the leak?" Walk through what retained size means and why sorting by it, not shallow size, is what actually finds the root cause.