Java Thread Dump Analyser
understand thread dumps by looking at a thread dump
Java Thread Dump Analyser is a tool for quickly summarizing lengthy Java thread dumps.
This tool groups threads together which have the same stack trace and allows you to only show threads which are in particular states (e.g. RUNNABLE or BLOCKED).
This makes it a bit quicker to find the interesting threads amongst the tens or hundreds of JBoss threads which spend most of their time waiting for work at the same place in the code and therefore all have the same stack trace
A Java thread dump is a way of finding out what every thread in the JVM is doing at a particular point in time. This is especially useful if your Java application sometimes seems to hang when running under load, as an analysis of the dump will show where the threads are stuck.
You can generate a thread dump under Unix/Linux by running kill -QUIT <pid>, and under Windows by hitting Ctl + Break.
To make it easier to understand the contents of a Java thread dump you can use the Java Thread Dump Analyser. All you have to do is copy/paste your thread dump text into the input tab and press the Analyse button.
Here is an example of the output which is generated.
2011-08-19 17:46:25
Full thread dump Java HotSpot(TM) Client VM (20.0-b11 mixed mode, sharing):
As the name suggests thread dump is a dump of all the threads in a Java virtual machine. It contains the current execution state of both application and the JVM specific threads. The above thread dump snippet shows two application threads [Thread-0 and Thread-1] and JVM specific threads such as “Signal Dispatcher”, “Finalizer” etc. For the purpose of this article we will focus only on application threads.
Thread dumps are extremely useful in the following situations
- To get a holistic view of what is happening in the application at that particular moment
- To expose glaring issues such as
- portions of code which seem to be invoked almost always
- portions of code where the application seems to be hung
- locking and thread synchronization issues in an application
- Additionally they are invaluable in production environments where sophisticated profiling tools cannot be easily attached
Format of thread dumps
The format of thread dump has been changing with JSE versions. Sun or any other vendors inform users that the format will change between versions. However one thing which hasn’t changed is the level of information contained in a thread dump. As mentioned above thread dumps is a snapshot of the JVM state listing all the application and system level threads and monitor states.
Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing):
"Thread-1" prio=5 tid=0x00a995d0 nid=0x1300 in Object.wait() [0x02d0f000..0x02d0fb68] at java.lang.Object.wait(Native Method) - waiting on <0x22aaa8d0> (a org.tw.testyard.thread.Drop) at java.lang.Object.wait(Unknown Source) at org.tw.testyard.thread.Drop.take(Drop.java:14) - locked <0x22aaa8d0> (a org.tw.testyard.thread.Drop) at org.tw.testyard.thread.Consumer.run(Consumer.java:15) at java.lang.Thread.run(Unknown Source)
"Thread-0" prio=5 tid=0x00a88440 nid=0x6a4 waiting on condition [0x02ccf000..0x02ccfbe8] at java.lang.Thread.sleep(Native Method) at org.tw.testyard.thread.Producer.run(Producer.java:24) at java.lang.Thread.run(Unknown Source)
In the thread dump snippet above you can observe the following
- The thread dump starts with “Full thread dump”, followed by a list of threads currently being executed.
- There are 2 application threads called Thread-1 and Thread-0. These are the default names which the JVM handed over to the threads.
- “Thread-1″ is waiting for a notification after it called Object.wait() on the Drop object.
- Similarly, “Thread-0″ is sleeping on a condition after it called Thread.sleep
- At this particular instant, there are no threads in the runnable state and hence the application isn’t doing any real work.
Although thread dumps also lists the state of the system threads we are not going to look deeper into system threads.
How to take thread dumps
Thread dumps can be generated by the users as well as the system in unusual situations. The users can generate thread dumps by explicitly sending a signal to the JVM or programatically by calling java.lang.Exception.printStackTrace(). Calling printStackTrace() method will only cause the stack trace of the current thread to be printed.
On windows environment thread dumps can only be generated when the process is running in the fore ground and is associated with a command line console. Thread dumps can be generated by hitting the key combination Ctrl + \ (Back slash). On unix / linux enviroments thread dumps can be generated by the command kill -QUIT <process id of jvm> or kill -3 <process id of jvm>. Thread dumps are generally logged to the stderr. Depending on your start up commands you may find the thread dumps in some other log files. Please consult your system administrator for details. Taking thread dumps by either of the 2 strategies doesnt cause the application to terminate, the JVM dumps the execution state and continues.
Although very rare the JVM can also generate a thread dump when a thread causes the JVM to crash. The amount of information which gets logged is again implementation specific. Typically you will find information about the thread which caused the JVM to crash.