[concurrency-interest] Deadlock detection

Brian Goetz brian at quiotix.com
Fri Apr 6 16:47:53 EDT 2007


Scanning for deadlocks with JMX is reactive; what you want is to 
identify the causes of deadlock, which is inconsistent lock ordering. 
One approach, which requires run-time weaving with aspects, is here:

http://www-128.ibm.com/developerworks/java/library/j-jtp08226.html

Sam Berlin wrote:
> Hi Oliver,
> 
> JMX features provide the ability to scan through all locks for
> deadlocked code.  I can't quite tell by reading the link you provided
> if this is what you're looking for.  It doesn't provide the ability to
> know ahead of time if acquiring a given lock would produce a deadlock
> (that would be a neat JVM switch -- I wonder how slow it would make
> things), but it will tell you afterwards if you've encountered a
> deadlock.  (It will even correctly report a trio of threads, where the
> third is waiting on something the first two have deadlocked in.)
> There's no ability to rollback any deadlocks, but that is always
> fraught with peril anyway.  For an example of using the JMX features,
> see the following deadlock detection class:
> <https://www.limewire.org/fisheye/browse/limecvs/gui/com/limegroup/gnutella/gui/DeadlockSupport.java?r=1.3>
> .  That class is written to work best on Java 1.6, but also work
> well-enough on Java 1.5.
> 
> Sam
> 
> On 4/6/07, Oliver Zeigermann <oliver at zeigermann.de> wrote:
>> Folks!
>>
>> I plan to write some code for deadlock detection for Java programming
>> using the concurrent package introduced in Java 1.5.
>>
>> The code is intended for a new version of
>>
>> http://jakarta.apache.org/commons/transaction/
>>
>> and there to replace the old code which is described in
>>
>> http://jakarta.apache.org/commons/transaction/locks/deadlock.html
>>
>> I doubt that the idea and code described there are especially good and
>> would be pleased if anyone could point me to a better direction.
>>
>> I was especially concerned about
>>  *  whether a check for a deadlock with potentially every locking
>> request really is a good idea or if it is smarter to let an additional
>> thread check for deadlocks from time to time, and
>>  * if there is any algorithm that does not have to check the whole
>> dependency graph for cycles, and
>>  * a more elegant version of the existing code could be written that
>> does not have the drawback of potentially rolling back both threads
>> that are part of a deadlock (one should be enough)
>>
>> That code has been written by me, so if you want to comment, please do
>> not be polite ;)
>>
>> Thanks for any hints in advance and cheers
>>
>> Oliver
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at altair.cs.oswego.edu
>> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


More information about the Concurrency-interest mailing list