Crash Course: Java SE Monitoring, Management and Troubleshooting
By dannycoward on Mar 10, 2006
(Pardon the pun...)
At a meeting of Java developers earlier this week, I was struck by the convergence of three things. Just about everyone appeared thoroughly expert in the Java Platform, most were developing on Java SE 5, engaged in commercial product development of some sophisticated nature. Yet surprisingly few were familiar with our toolbox of management, monitoring and troubleshooting tools in Java SE 5 (and 6!).
You see, lurking under the surface of your application as it buzzes along may be a number of issues that can difficult to diagnose by reading your code alone. Causing seemingly non-deterministic behaviors (yes, those elusive intermittent bugs that cannot be reliably repeated) and performance degredations in your application, these issues are usually caused when you forget to dereference objects which squat unhelpfully in memory, or two or more of your threads clash and sit in perpetual stalemate, or other such esoterica. Left untended for long periods of time, they can even bring down an otherwise stable VM.
So cast aside the crystal balls, divining rods, tarot cards, or calls to Dionne Warwick that you may use currently to guess at memory leaks, thread deadlocks, dirty references, infinite loops, garbage collector histories: I'm going to give you all a crash course in the management and troubleshooting tools lurking in the /bin directory of your JDK.
Picture = 1k words
First thing, is to get into the habit of starting JConsole as you test your application - its (literally) your window into what's going on and is as good looking as all get out:-
You may just get into watching your application all day long, or JConsole may in fact solve your problem, it will certainly be apparent with use that there is a problem, especially if a memory leak or thread management issue. You may figure it out from here, or you may want to delve a little deeper into the command line tools...come with me...
Where's my VM ?
The jps tool. Roll call of all the names and numbers of all the Java processes on your machine. You'll need this for the other command line tools, as they need to know which Java process you want to look at.
Anyone seen my memory ?
Ahh, jmap and jhat, the forensic experts of memory diagnosis. jmap's role in life is to take a detailed 'photograph' of what's going on in memory at any one point in time, and jhat is the forensic expert that will help you interpret it. If you have a wonky application that's causing VM crashes, you can even set a VM option to have jmap take a farewell picture of memory state as the VM comes down. I must say that in looking though the neat website that jhat creates based on a jmap memory 'photograph', my inner geek was crying for joy to see the memory usage and instance counts of my classes that I could have it slice and dice every which way.
Threads in a tangle ?
Our friend for diagnosing thread problems is jstack who takes a 'photograph', on demand, of all the threads and what they are up to in their own stack frames. This includes the information from the traditional CTRL-Break or CTRL -\\. jconsole arranges this rather output well, and check out the new button for detecting deadlocks !
Time to lift up the hood
Last stop on our tour is jstat. Really for the hardcore troubleshooters amongst you that want to see into the gizzards of the HotSpot dynamic compiler and garbage collectors. Very handy in a large number of situations where performance is suffering because memory is not being reclaimed like you think ought to be.
OK, that really was a whirlwind tour, but I hope you get a flavor if you are new to this area. All of the above is current in Java SE 6, and most true for Java SE 5. For SE 6 we made it using the tools 'hands-free' (i.e. no special VM options), we added more information within the tool outputs, and we co bundled jhat.
For those interested in more, stay in touch with the Java SE experts on this - Alan, Kelly, Mandy and Sundar.
And if THAT'S not enough, and you want to write your own monitoring and management tools, either for Java SE, or your application that runs on it, you really should talk to Eamonn.