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.

Shallow size is just an object's own footprint — for a HashMap, that's the header, the size field, the load factor, a handful of fields — genuinely tiny regardless of how many entries it holds, because the entries themselves live in a separate backing array of Node objects. Retained size is a different question entirely: if this one object were removed (the field set to null), how much memory becomes eligible for collection because nothing else keeps it alive? For a static cache that owns the only reference to thousands of entries, that number is enormous, because removing the map drags the entire backing array and every entry down with it. Sorting a dominator tree by shallow size buries the map under every large byte array in the heap; sorting by retained size puts it at the top, because it's the one small object silently holding a huge amount of memory hostage.