In which we eat red herrings

Java memory leaks can be much more insidious than anyone has so far led me to believe. The conventional wisdom goes like this:

"Well, the garbage collector is going to take care of it for you. Nothing to worry about, just make sure you aren't holding on to references unless you need them. Watch your static collections and singletons, and you can't go wrong."

We ran into a nice situation where we had a process that ran continuously and upon request, would open a Swing dialog to do some work. You fiddle around in the dialog, close it, and it goes back to sleep until it's needed again.

Using JProbe, we got into there and saw that there were no differences in object counts between iterations.

"Great," we thought, "we're all set." Closed the bug. Then during verification time, we saw that in Task Manager the memory consumption was increasing with every iteration.

"This sucks in a mighty, mighty way," we said. Reopened the bug. Using Process Explorer from Sysinternals (great tool, download immediately), we saw that the handle count for the process kept going up. So although the object counts were constant, more and more native memory kept being allocated. Finally, we tracked it down to a place where we were creating JDialog objects and never calling dispose() on them.

The moral of the story, children, is that memory management is always important, whether there's a garbage collector involved or not. Heed it well.