8

I'd like to kill threads that are stuck in deadlock state. First, we can detect thread ids in deadlock state using the findDeadlockedThreads() method of the ThreadMXBean class in java.lang.management.

Then, I'd like to kill the threads by thread ids, and thus I have two related questions:
(1) How to get the control of a thread by thread id?
(2) How to kill a blocked thread? I think that invokting interrupt() method will give an exception to the thread and will kill the thread.

Community
  • 1
  • 1
Sangmin
  • 415
  • 1
  • 6
  • 15
  • 4
    Fixing the code so that the threads don't deadlock in the first place should be what you're trying to do. – Chris Dec 04 '09 at 22:22
  • Like Chris said I think you should devise a plan to avoid deadlocks in the first place. – Alfred Dec 04 '09 at 22:32
  • 1
    The only reasonably safe way to do what you want is System.exit()... and I'm only partially joking. – PSpeed Dec 04 '09 at 22:59
  • Yes, detecting and fixing a deadlock is the first option, if I am writing a concurrent program. But, I am planning to write a deadlock detector by checking user threads in runtime. :) – Sangmin Dec 04 '09 at 23:16

3 Answers3

6

The java.util.concurrent.Lock.lockInterruptibly() method is interruptable, the far more common synchronized locking is not. As mentioned in the documentation, the ability to enumerate deadlocked threads is intended as a debugging aid and not as a means to recover in a production environment.

In production it is probably safer to exit the whole process and restart.

Mark Thornton
  • 1,885
  • 1
  • 12
  • 4
3

From the root threadgroup, you can have the Thread class enumerate all running threads. Then you can call Thread.stop on the one that matches your ID.

Having said that, this is highly dangerous due to the potential to leave objects in an inconsistent state. I don't believe that the interrupt method will cause a thread to be freed up that is stuck in waiting on a synchronization lock, so the (evil) stop methods

See also: "Java Thread Primitive Deprecation".

jsight
  • 27,819
  • 25
  • 107
  • 140
  • 3
    The badness of this can't be emphasized enough. Better to write the code to avoid the deadlock in the first place. – bmargulies Dec 04 '09 at 22:21
  • Enumerating all running threads is an interesting article, so I'll definitely use it later. Thanks. – Sangmin Dec 05 '09 at 00:22
  • 2
    The Thread.stop() approach does not seem to work in Java 1.5. The deadlocked threads remain in the BLOCKED state. For me, I'm trying to write a unit test for a deadlock detector and I can't get rid of my intentionally-deadlocked threads! :-) – Chris Dolan May 10 '10 at 20:05
3

Even Thread.stop() is unable to stop thread deadlocked on intrinsic lock.If a thread is blocked waiting for an intrinsic lock, there is nothing you can do to stop it short of ensuring that it eventually acquires the lock and makes enough progress that you can get its attention some other way. It works with Lock.lock() through.

Mike
  • 20,010
  • 25
  • 97
  • 140