OptimizeIt Profiler 5.0
Who said that Java does not have memory leaks? In fact I think that is a good question to ask new grads. Everyone knows that Java’s garbage collection will reclaim unreferenced objects. The problems is that some objects are still referenced even when they are no longer needed.
I been working on a memory problem and used OptimizeIt Profiler 5.0 to track it down. The version of OptimizeIt that I am using dates back to 2002 and unfortunately does not support Eclipse. I am almost sure that the latest release of OptimizeIt will support Eclipse. Without sounding too much like a commercial, OptimizeIt really helped in tracking down the static variable at fault.
OptimizeIt has a Heap view of your application. In my situation, the server had at one point 50,000 instances of one class alone. This class was not the root of the memory propblem since the class was small, but it did indicate that whoever held references to so many objects might be a place to start looking.
The Allocation Backtrace view shows where objects where created, I didn’t think this was all too useful. The Allocation Backtrace is pretty detailed and for a server object we created the allocation backtrace started all the way with TCPTransport$ConnectionHandler.run(). Even still, not that useful for what I was doing.
OptimizeIt has a great Instance Reference Graph. This feature was really helpful in tracking down who keeps references to objects thought to be disposed. The Instance Reference Graph breaks down to three tables. One table contains a ‘Reduced reference graph’, which is more of a tree than a graph, that breaks down who is holding references to objects for which you are interested. Once you navigate down the ‘Reduced reference graph’ the ‘Allocation at’ table will display a view that is reminiscent of a stack trace. The ‘Allocation at’ view will show class names and line numbers for which contain references that have references to your object of interest. Using the Instance Reference Graph I was able to narrow down the problem!
The Memory Leak Detector is great because you can create a snapshot of the heap at a moment in time so that you can compare your application’s memory usage at a later point in time. As you run your application, you may save the heap state to compare it with other saved heap states. Between two heap states, you can view the number of objects and re fences created for any class. Select a object instance and you can see a graph of objects that have references to the selected object.
As you can see, Java does have memory leaks! If your application is having memory problems you should look into using a Java profiler to analyze you application in action. I know that NetBeans 5.0 comes with a free NetBeans Profiler. I myself haven’t used NetBeans 5.0 or its NetBeans Profiler so I can’t say much about that. I am using a older version of OptimizeIt which I don’t think Borland will support so I should try to get familiar with NetBeans Profiler.
Using OptimizeIt I was astonished to discover that our application instantiates over 2 million objects from 7,000 classes. Whoa!