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:
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:
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):
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:
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!
Monitor Object Monitors with Eclipse Object Monitor Monitors
At 11:16 PM on Aug 29, 2005, R.J. Lorimer
wrote:
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
Debugview that shows you all of the active threads:Thread AandThread Bare 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 theDebugview where the threads are shown (as seen to the right):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
Debugview and selecting 'Suspend' as seen in this picture: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!
Until next time,
R.J. Lorimer
Contributing Editor -rj -at- javalobby.orgAuthor -http://www.coffee-bytes.comSoftware Consultant -http://www.crosslogic.com3 replies so far (
Post your own)
Re: Monitor Object Monitors with Eclipse Object Monitor Monitors
Not ridiculous, but really funny.Re: Monitor Object Monitors with Eclipse Object Monitor Monitors
Now that's a nice tipp, which could come very handy!Thanks
Re: Monitor Object Monitors with Eclipse Object Monitor Monitors
Good tip, thanks for posting ;]