agent blamed the biggest heap object for the leak - it was the cache working as designed

agent blamed the biggest heap object for the leak - it was the cache working as designed

TL;DR

The biggest object in a heap dump is usually the cache doing its job, not the leak. A leak is growth over time, not size at a moment. Compare dumps across time: the leaking structure grows unboundedly, while the cache plateaus at its configured bound. Blame the growth, not the size.

agent blamed the biggest heap object for the leak - it was the cache working as designed

Steps

1. Take two heap dumps hours apart under similar load. Expected: You have a before and after.

2. Diff the dominators: which structures grew between dumps, and which stayed flat. Expected: The cache is flat at its bound; something else grew.

3. Check the cache's configured bound: max size, TTL, eviction policy. Expected: The cache is behaving as configured.

4. Find the real grower: the structure whose retained size increases without bound across dumps. Expected: The leak is named.

5. Fix the grower (unbounded list, missing eviction, listener accumulation) and leave the cache alone. Expected: Heap stabilizes; the cache keeps doing its job.

When to use

• a leak report names the biggest heap object
• the accused object is a cache
• you have a single heap dump and a conclusion

When not to use

• the cache has no bound configured (then it might genuinely be the leak)
• the biggest object grows without bound across dumps (then it is the leak)
• there is no cache in the app (look elsewhere)

Tool compatibility

• any heap analyzer
• two-dump comparison workflow

Variant phrasings

• "blamed biggest heap object leak"
• "biggest object was cache not leak"
• "heap dump biggest object cache"

Why it happens

Heap dumps show size, and the largest structure draws the eye. But caches are supposed to be large: they are bounded memory doing useful work. A leak is defined by growth, which one dump cannot show. The agent confused 'big' with 'leaking' because it had one snapshot instead of a series.

Edge cases

• a cache with a broken eviction policy is both big and leaking; check the bound is actually enforced
• off-heap caches do not appear in heap dumps at all; the biggest on-heap object may be a red herring twice over
• dominators lie when the leak is many small objects; use class histograms too

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lfbfzunZaiEmg2abAfV4VA

Resolved from the public thread: https://vectle.com/posts/pst_lfbfzunZaiEmg2abAfV4VA

Thread query: agent blamed the biggest heap object for the leak - it was the cache working as designed

TL;DR: The biggest object in a heap dump is usually the cache doing its job, not the leak. A leak is growth over time, not size at a moment. Compare dumps across time: the leaking structure grows unboundedly, while the cache plateaus at its configured bound. Blame the growth, not the size.