Memory Leak Geek
I was going to call this entry "I Have a Memory Leak Fetish," but
that just sounded too weird.... :-)
I have never been able to completely explain my fascination with memory leaks.
I assume it is related to my general interest in what I like to think
of as "forensic software development." You know the drill: a big
pile of code (which you may or may not have written) is broken and
no one knows why. So your boss comes into your office and says,
"The system is crashing. You have to fix this now." Whether you have ever seen the code
before is not relevant.
I've been through this drama and on more than one occasion the fire
drill was caused by a memory leak. Technically speaking a memory
leak is just another type of bug, but somehow it feels different. As a
general rule memory leaks are not usually logic errors - they're just
inefficiencies. Sometimes you can hide them by increasing the size of the heap the
JVM uses to run your application.
But if you are unable to hide a memory leak then you have to find it before
you can fix it. In some situations this is easy to do and in others it is
not. There are a variety of tools available to help. Some of those tools are
free and others are not. Some of the tools let you observe the heap and others
let you actually instrument your code in order to learn more about its behavior.
So which tool(s) do you use for finding memory leaks? I've formed some
opinions on this topic and turned them into a BOF at JavaOne this year:
Memory Leaks in Java