Long time ago, I saved a sentence from a Java reference book: "Java has no mechanism to handle deadlock. it won't even know deadlock occurred." (Head First Java 2nd Edition, p.516)
So, what is about it? Is there a way to catch deadlock case in Java? I mean, is there a way that our code understands a deadlock case occurred?
Since JDK 1.5 there are very useful methods in the
java.lang.management
package to find and inspect deadlocks that occurs. See thefindMonitorDeadlockedThreads()
andfindDeadlockedThreads()
method of theThreadMXBean
class.A possible way to use this is to have a separate watchdog thread (or periodic task) that does this.
Sample code:
JDK 5 and 6 will dump held lock information in a full thread dump (obtained with kill -3, jstack, jconsole, etc). JDK 6 even contains information about ReentrantLock and ReentrantReadWriteLock. It is possible from this information to diagnose a deadlock by finding a lock cycle: Thread A holds lock 1, Thread B holds lock 2, and either A is requesting 2 or B is requesting 1. From my experience, this is usually pretty obvious.
Other analysis tools can actually find potential deadlocks even if they don't occur. Thread tools from vendors like OptimizeIt, JProbe, Coverity, etc are good places to look.
After so long, i am able to write the simplest example of Deadlock. Comments are welcome.
JConsole is able to detect deadlocks in a running application.
Deadlocks can be avoided if you follow a simple rule: have all threads claim and release their locks in the same order. In this way, you never get into a situation where a deadlock can occur.
Even the dining philosophers problem can be seen as a violation of this rule as it uses relative concepts of left and right spoon which result in different threads using different allocation orders of the spoons. If the spoons were numbered uniquely and the philosophers all tried to get the lowest numbered spoon first, deadlock would be impossible.
In my opinion, prevention is better than cure.
This is one of the two guidelines I like to follow to ensure threads work properly. The other is ensuring each thread is solely responsible for its own execution as it's the only one fully aware of what it's doing at any point in time.
So that means no
Thread.stop
calls, use a global flag (or message queue or something like that) to tell another thread you want action taken. Then let that thread do the actual work.In general java does not offer deadlock detection. The synchronized keyword and built in monitors make it somewhat more difficult to reason about deadlock than in languages with explicit locking.
I would suggest migrating to using java.util.concurrent.Lock locks and the like in order to make your locking schemes easier to reason about. In fact you could easily make your own implementation of the lock interface with deadlock detection. The algorithm is to basically traverse the lock dependency graph and look for a cycle.