Troubleshooting a problem over last weekend I ran into a classic memory leak. Yes, you can have memory leaks in Java! If you hold onto references to objects than the Java virtual machine cannot reclaim those objects. In my case, I was processing millions of records but not giving yielding and allowing an object cache to purge itself (my fault – IDE evidently didn’t copy over an updated config file because I didn’t make a code change). This problem led me to dig into Netbeans and profiling Java processes running as Windows’ services. While Netbeans is a great tool, it does a negative impact upon performance. Obviously a less intrusive tool is needed initially. Java 5 ships with jconsole which drills into a JVM and reports back on heap utilization, thread activity etc. JConsole connects to either local JVM or one on a remote machine. I have also used JConsole to track down a renegade thread that was caught in an IO loop as a result of security software checking for a buffer overrun.
To enable jconsole connectivity for an application simply adding the following VM parameters:
-Dcom.sun.management.jmxremote.port=8999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Launch your application and then launch jconsole (jconsole should be in your path).
Below you can see screenshots from my ‘classic’ leak:
Ryan Cuprak 
You must be logged in to post a comment.