Mandy Chung's Blog

Thread Dump and Concurrency Locks

Thread dumps are very useful for diagnosing synchronization related problems such as deadlocks on object monitors. Ctrl-\ on Solaris/Linux or Ctrl-Break on Windows has been a common way to get a thread dump of a running application. On Solaris or Linux, you can send a QUIT signal to the target application. The target application in both cases prints a thread dump to the standard output and also detects if there is any deadlock involving object monitors.

jstack, a new troubleshooting utility introduced in Tiger (J2SE 5.0), provides another way to obtain a thread dump of an application. Alan Bateman has a nice blog about jstack and its several improvements in Mustang (Java SE 6). Mustang jstack works like a remote Ctrl-\ or Ctrl-Break if you are on Windows.

jconsole is JMX-complaint GUI tool which allows you to get a thread dump on the fly. The "Using JConsole to Monitor Applications" article gives you an overview of the Tiger monitoring and management functionality.

Mustang extends the thread dump, jstack, and jconsole to support java.util.concurrent.locks to improve its diagnosability. For example, the Threads tab in the Mustang jconsole now shows which synchronizer a thread is waiting to acquire when the thread is blocked to lock a ReentrantLock and also which thread is owning that lock.

In addition, it has a new "detect deadlock" button (in the bottom). When you click on the "detect deadlock" button, it will send a request to the target application to perform the deadlock detection operation. If the target application is running on Mustang, it finds deadlocks involving both object monitors as well as the java.util.concurrent.locks. If the target application is running on Tiger, it finds deadlocks involving object monitors only. Each deadlock cycle will be displayed in a separate Deadlock tab.

Click here to see a wider form of this screenshot.

JDK 6 has a nice demo FullThreadDump under $JDK_HOME/demo/management/FullThreadDump where JDK_HOME is the location of your JDK 6. This demo has been included in JDK 5.0 and is updated to use the new Mustang API. It demonstrates the use of the java.lang.management API to get the thread dump and detect deadlock programmatically.

Comments

• There are times when it is impossible to get a JVM to respond via CTRL-\ or kill -3 so I'm very happy to learn about jstack. Thank you.
  

  Posted by: markswanson on November 23, 2005 at 08:04 PM

• Rock! It's nice Sun's made a tool that comes bundled with the SDK to find deadlocks!

  Posted by: phlogistic on November 25, 2005 at 07:45 AM

• That's a pretty nice tool, Mandy, thank you for sharing it with a wider developer audience. Is there something like planet.classpath.org for Sun's J2SE engineers blogs?

  cheers,
  dalibor topic

  Posted by: robilad on November 30, 2005 at 02:23 PM

• Mark Reinhold has set up planetjdk.org which lists Sun's J2SE bloggers as well as those who contribute to Mustang. Check it out! Thanks to Mark.

  Posted by: mandychung on November 30, 2005 at 02:41 PM

• hi there,

  is there a way to automatically have all java processes automatically have the JCONSOLE parameters so that any ant target java processes are also JCONSOLE enabled on java 5 ?

  I currently have a hanging junit test which hangs only while launched from our ant build. I'm wondering how to get a stack trace of this junit test by attaching into JConsole. if there was a way for me to set a parameter such that all java programs use/set the JCONSOLE params, then it'll be cool.

  Thank you,

  BR,
  ~A

  Posted by: anjanb2 on November 30, 2005 at 03:01 PM

• StackTrace can start the JConsole agent even when the JVM is already running. This way you should be able to attach JConsole to the junit tests when necessary.
  The tool can get thread dumps from JKD 1.3 and 1.4 VMs too.
  

  Posted by: tmitevski on December 01, 2005 at 12:15 AM

• A deadlck detector is really useful. So is jstack. Sun needs to talk more about such tools that ship with the jdk.

  Posted by: bharathch on December 01, 2005 at 01:17 AM

• thank you ver much, mandy! It's planetjdk.org and it's very nice.

  cheers,
  dalibor topic

  Posted by: robilad on December 01, 2005 at 06:20 AM

• Hi anjanb2,

  Mustang (Java SE 6) no longer requires the application to be started with -Dcom.sun.management.jmxremote option to be connected by JConsole on the same machine.

  Alan Bateman implemented the new attach-on-demand feature in Mustang that enables JConsole to start to a running application and start the JMX agent. Check out his weblog.

  For JDK 5, you can set a JAVA_TOOL_OPTIONS variable which is defined in
  JVM Tool Interface to "-Dcom.sun.management.jmxremote". The variable value will be processed at VM startup.

  Posted by: mandychung on December 01, 2005 at 10:39 AM

This work is licensed under a Creative Commons License.