Is there a way to detect and break the deadlock

[Om Tejas]

Hi,

Deadlock is very common in Java. Is there a way to break the deadlock using any APIs.

[Ulf Dittmer]

Deadlock is very common in Java.

That's news to me. What are you basing this statement on?

Deadlocks don't occur for a particular language, they occur for particular code. Are you talking about specific code that exhibits deadlocks?

[Om Tejas]

Yes for a specific code. For example when using java threads.

class A {

   public synchronized void processA() {
            B b = new B();
            synchronized(b){
            }

   }

}

class B {
   
   public synchronized void processB() {
            A a = new A();
            synchronized(a){
            }
   }

}

If I am not wrong, the above is a potential deadlock scenario. Is there a way to break this deadlock, apart from Ctrl+c etc. Any APIs

[Ulf Dittmer]

Not sure how you think a deadlock could occur, given that the threads synchronize on different objects. If the code in processB synchronized on A.class, and vice-versa, then you'd have a potential deadlock:

class A {
   public synchronized void processA() {
            synchronized (B.class) {
...
            }
   }
}

class B {   
   public synchronized void processB() {
            synchronized (A.class){
...
            }
   }
}

The way to avoid deadlocks is not to write code that exhibits http://en.wikipedia.org/wiki/Deadlock#Necessary_conditions. This is true for all code running in multi-threaded environments, irrespective of the language it's written in.

[Om Tejas]

The link and wiki gives information on necessary condition, prevention, avoidance and detection. My question what to do after deadlock is dectected. I have come across some articles which say that ThreadMxBean can be used to detect the deadlock threads. What I am trying to find out is there a way to move the threads in deadlock out of deadlock state once deadlock is detected.

[Stephan van Hulst]

Not within the same program, or it wouldn't be deadlock.

[Ulf Dittmer]

Stephan van Hulst wrote:Not within the same program, or it wouldn't be deadlock.

There could still be live threads, even if some other ones are deadlocked.

Killing threads and then resuming execution would be dangerous, as the application could be in an instable or inconsistent state (see the explanation of the Thread.destroy() method). Some high-end databases can detect deadlocks, select one thread for termination and let the others proceed, but that's a special case as the app can tell exactly what a thread is doing (by looking at the SQL it executes).

[Mike Simmons]

If the threads involved are each using the synchronized keyword to lock on (or attempt to lock on) the various monitors involved, then once deadlock occurs, there's no way out other than maybe Thread.destroy(), as Ulf said.

However, since JDK 5 it's been possible to use java.util.concurrent.locks.Lock instead of the synchronized keyword. The resulting code is more verbose but has many more options for handling locks. In particular, if you never use the lock() method, but instead use lockInterruptibly() or tryLock(), then it becomes possible to write code that gets out of a prospective deadlock. Which technically means it wasn't a deadlock if you can get out of it. But you can get out of situations that would have otherwise been deadlocks if using synchronization. Writing such code would still be rather complex; I don't have a ready quick example. But at least it's possible.

Oh, and java.util.concurrent.locks.ReentrantLock has additional methods that could be useful. Things like getOwner(), getQueuedThreads(), isLocked(), isHeldByCurrentThread(), etc. Lots of possibilities there.

[Henry Wong]

Generally, deadlocks are avoided, instead of "detected and broken". Even if deadlock detection is simple (and it isn't), the task of undoing what you did so far isn't easy. In order to break a deadlock, you need to undo operations, which means that you need to support some sort of transaction system -- which requires that databases, and everything you use, support transactions too.

And the most common way to avoid deadlocks is to establish a locking hierarchy -- when lots of related locks are needed, locks need to be grabbed in a certain order. It makes it much more coarse, but it will avoid deadlocks.

Henry