A day in the life of a memory leak hunter

Excellent article, it was invaluable to me a couple of years ago when I was trying to find a memory leak that was placing a very large project in jeopardy.

As a mental exercise think how many people that call themselves "Java developers" would be able to troubleshoot the issues this guy encountered.<p>I love statements like "take a look the code below" followed by what appears to be perfectly normal code to me and then "the problem in the code above is obvious".

I read it, understood some of it -- and am now happy not to be this guy. And I do consider myself a "Java developer", even though I have not been working with Java lately.

Though he doesn't mention which Java version he's using, nowadays some core bundled facilities can make such diagnoses a lot quicker. 'jmap -histo' give you instance counts by class in a running JVM -- so over a period of unexpected memory retention, or the period just before an OOME, you can identify supspiciously overrepresented types. A binary heap dump and then browse with the 'jhat' tool can backtrace the exact reference chains causing objects to be retained. -- especially if you have the luxury of debugging a 16MB heap, rather than (say) a 2+GB heap.<p>The really annoying OOMEs in my experience are those that aren't really object heap exhaustion -- but other depletions that still get reported as OOME. Sometimes, increasing your object heap makes these worse (eg by allowing less space for non-heap JVM structures). At least starting in Java 6, these "other OOMEs" tend to have different messages.