

A day in the life of a memory leak hunter - hollywoodcole
http://www.szegedi.org/articles/memleak.html

======
huherto
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.

------
cstejerean
As a mental exercise think how many people that call themselves "Java
developers" would be able to troubleshoot the issues this guy encountered.

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".

~~~
bayareaguy
This guy definitely deserves credit for focusing on the problem. Most java
developers I know would have tried some cheezy workaround like periodically
restarting the process. As a consequence things like this go unsolved for
years.

This is actually a common issue whenever you have long-lived processes which
suck in third-party code. Half the complaints I see about browsers these days
is that they leak memory.

I remember a similar problem in C++ years ago with a poorly coded initializer.
One of the core dumps of an X application I looked into had over 50 megabytes
of copies of the string "Helvetica".

------
asmosoinio
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.

------
gojomo
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.

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.

