Memory leak diagnosissenior8+ years

Eclipse MAT's Leak Suspects Report ranks a `HashMap` instance as the #1 candidate in one heap dump, and finds nothing obviously wrong in a second dump where the actual leak turns out to be eight separate `ArrayList` instances, each individually unremarkable. Why would the same kind of tool succeed on one and miss the other, and what would make it catch both?

The tool succeeds on the HashMap because MAT's algorithm is built to find exactly that shape: a single object whose retained size — everything that would be freed if it became unreachable — is a disproportionately large fraction of the whole heap. It can miss the eight ArrayLists because none of them individually looks unusual; each is small on its own, and 'biggest single object' ranking finds nothing to flag. What actually catches both cases is that MAT runs a second, separate check alongside the first: grouping objects of the same class (or the same allocation stack trace) and summing their retained size across the whole group before ranking, which is how eight unremarkable-looking ArrayLists, each retaining a slice of a much bigger total, get flagged as a group — an accumulation point — even though no single instance would ever earn a mention on its own.

The lesson behind it →