Deadlock - Monitor Object Monitors with Eclipse Object Monitor Monitors

Ok, so the title is ridiculous, but I had to do it, didn't I? Ok, maybe not - but I hope it got your attention anyway.

Why is it that deadlocks are so easy to create, and yet so hard to get rid of? Heck, I've been known to create them on accident (not quite infallible). When it comes to deadlocks, any help is valuable.

To illustrate Eclipse's monitor-tracking capabilities - I have created this example class which is bound to trigger a deadlock situation:

package com.javalobby.tnt.threads;

public class ThreadTest {

	private static final Object lockA = new Object();
	private static final Object lockB = new Object();

	public static void main(String[] args) {
		Thread threadA = new Thread(getRunnableA(), "Thread A");
		Thread threadB = new Thread(getRunnableB(), "Thread B");		
		threadA.start();
		threadB.start();
	}
	private static Runnable getRunnableB() {
		return new Runnable() {
			public void run() {
				synchronized(lockA) {
					try {
						Thread.sleep(500);
					}
					catch(InterruptedException e) { }
					synchronized(lockB) {
						System.out.println("Retrieved lock B and lock A");
					}
				}
			}
		};
	}
	private static Runnable getRunnableA() {
		return new Runnable() {
			public void run() {
				synchronized(lockB) {
					try { 
						Thread.sleep(500);
					}
					catch(InterruptedException e) { }

					synchronized(lockA) {
						System.out.println("Retrieved lock A and lock B");
					}
				}
			}
		};
	}	
}

It's pretty easy to see in this case where the deadlock is going to happen - but most deadlocks are vedy vedy sneaky. In any case, I'm not here to show off new and clever ways to create deadlocks, but rather, how to dissemble them.

When you are debugging an application in Eclipse, you get a stack of icons in the Debug view that shows you all of the active threads:

[img]http://www.javalobby.org/images/postings/rj/eclipse_threads/1.gif[/img]

This screenshot shows the program above running on my environment. We know based on the code that Thread A and Thread B are in contention. While often times you won't know exactly where the deadlock comes from (otherwise techniques like the one I am describing here would be pointelss), you can often make an educated guess on which threads it is coming from. To find what threads are locked, and what they are locked waiting for, all you have to do is to: a.) turn on 'Show Monitors' - this is done by clicking on the drop-down icon for the Debug view where the threads are shown (as seen to the right):

[img]http://www.javalobby.org/images/postings/rj/eclipse_threads/2.gif[/img]

and then b.) suspend the threads you believe are in contention for a lock - this is done by right clicking on the threads in the Debug view and selecting 'Suspend' as seen in this picture:

[img]http://www.javalobby.org/images/postings/rj/eclipse_threads/3.gif[/img]

Now, in this final screenshot you can see very clearly that Thread A is waiting on a lock that is owned by Thread B, and Thread B is waiting on a lock that is owned by Thread A. Also notice that Eclipse has made the contention bright red. Doesn't get much more clear than that!

[img]http://www.javalobby.org/images/postings/rj/eclipse_threads/4.gif[/img]

Until next time,