kjkoster
30-09-2008, 15:42
Dear All,
Java-monitor has the ability to detect thread deadlocks (http://en.wikipedia.org/wiki/Deadlock). In this post I will show you how to interpret the results of a thread monitor deadlock.
Thread deadlocks are shown on the host's overview screen, as you can see in the screen shot below. This screen shot was taken from a little web application that is deadlocked using Sun's deadlock code example (http://java.sun.com/docs/books/tutorial/essential/concurrency/deadlock.html). The only difference is that I gave the threads meaningful names.
http://java-monitor.com/forum/picture.php?albumid=2&pictureid=2
Deadlocks are programmatic errors. As a system administrator there is really very little you can do to break the deadlock, other than restarting the context or even the entire application server. Your best course of action is to call in a developer to record the deadlock situation and have it resolved in a new version of the application.
The stack traces in the screen shot are clipped. Java-monitor will clip these to 10 lines of stack trace each, and up to 1024 characters in the entire message. This may hinder thread deadlock analysis a little. I believe that Java-monitor's role is to passively detect deadlocks. It is not a tool to analyse them in great depth. Instead, hook up JConsole to the stricken application and use that for detailed analysis. You will find a "detect deadlocks" button on the "Threads" tab in the JConsole that comes with Java 1.6.
Deadlocks are not a very common problem in Java. Java's concurrency model is based on monitors (http://www.artima.com/insidejvm/ed2/threadsynch.html), making it relatively easy to write non-deadlocking code. With the introduction of explicit locking primitives in Java 5 (http://www.javamex.com/tutorials/synchronization_concurrency_9_locks.shtml), the potential for developers to deadlock their feet has grown significantly. From a system administrator's perspective this is a problem, because Java 1.5's built-in thread deadlock detection facilities do not detect the deadlocks that programmers caused using the new concurrency classes. Java 1.6 solves this issue by adding a deadlock detection facility for the new Java concurrency classes. The upshot of this is that Java-monitor can only detect monitor deadlocks on Java 1.5 JVM's. Java-monitor can detect both monitor and programmatic deadlocks on Java 1.6 VM's.
During code reviews I did run into places where programmers used the really primitive locking classes, such as RentrantLock. Invariably they had used the primitive locking mechanism to reinvent utility classes that are available as library classes in Java. Most often they were attempting to rebuild Java's BlockingQueue implementation, with rebuilding the synchronized keyword a close second. In all cases we were able to rip out the primitive locks and replace the code with a much shorter, more readable and above all actually working library class.
Kees Jan
PS. If you get the message "javax.management.InstanceNotFoundException: com.javamonitor:type=Threading" in the thread deadlock field, download and deploy the newest version of the Java-monitor probe (http://java-monitor.com/lemongrass/java-monitor-probe.zip). That should fix the error.
Java-monitor has the ability to detect thread deadlocks (http://en.wikipedia.org/wiki/Deadlock). In this post I will show you how to interpret the results of a thread monitor deadlock.
Thread deadlocks are shown on the host's overview screen, as you can see in the screen shot below. This screen shot was taken from a little web application that is deadlocked using Sun's deadlock code example (http://java.sun.com/docs/books/tutorial/essential/concurrency/deadlock.html). The only difference is that I gave the threads meaningful names.
http://java-monitor.com/forum/picture.php?albumid=2&pictureid=2
Deadlocks are programmatic errors. As a system administrator there is really very little you can do to break the deadlock, other than restarting the context or even the entire application server. Your best course of action is to call in a developer to record the deadlock situation and have it resolved in a new version of the application.
The stack traces in the screen shot are clipped. Java-monitor will clip these to 10 lines of stack trace each, and up to 1024 characters in the entire message. This may hinder thread deadlock analysis a little. I believe that Java-monitor's role is to passively detect deadlocks. It is not a tool to analyse them in great depth. Instead, hook up JConsole to the stricken application and use that for detailed analysis. You will find a "detect deadlocks" button on the "Threads" tab in the JConsole that comes with Java 1.6.
Deadlocks are not a very common problem in Java. Java's concurrency model is based on monitors (http://www.artima.com/insidejvm/ed2/threadsynch.html), making it relatively easy to write non-deadlocking code. With the introduction of explicit locking primitives in Java 5 (http://www.javamex.com/tutorials/synchronization_concurrency_9_locks.shtml), the potential for developers to deadlock their feet has grown significantly. From a system administrator's perspective this is a problem, because Java 1.5's built-in thread deadlock detection facilities do not detect the deadlocks that programmers caused using the new concurrency classes. Java 1.6 solves this issue by adding a deadlock detection facility for the new Java concurrency classes. The upshot of this is that Java-monitor can only detect monitor deadlocks on Java 1.5 JVM's. Java-monitor can detect both monitor and programmatic deadlocks on Java 1.6 VM's.
During code reviews I did run into places where programmers used the really primitive locking classes, such as RentrantLock. Invariably they had used the primitive locking mechanism to reinvent utility classes that are available as library classes in Java. Most often they were attempting to rebuild Java's BlockingQueue implementation, with rebuilding the synchronized keyword a close second. In all cases we were able to rip out the primitive locks and replace the code with a much shorter, more readable and above all actually working library class.
Kees Jan
PS. If you get the message "javax.management.InstanceNotFoundException: com.javamonitor:type=Threading" in the thread deadlock field, download and deploy the newest version of the Java-monitor probe (http://java-monitor.com/lemongrass/java-monitor-probe.zip). That should fix the error.