Performance Zone is brought to you in partnership with:

Pierre-Hugues Charbonneau (nickname P-H) is working for CGI Inc. Canada for the last 10 years as a senior IT consultant and system architect. His primary area of expertise is Java EE, middleware & JVM technologies. He is a specialist in production system troubleshooting, middleware & JVM tuning and scalability / capacity improvement; including processes improvement for Java EE support teams. Pierre - Hugues is a DZone MVB and is not an employee of DZone and has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Java STOP Thread? Think Again!

  • submit to reddit


When facing a stuck Thread problem, a common question is how can I dynamically kill the observed stuck Threads in order to quickly recover my middleware environment?
This is a question I’m getting quite often from my work colleagues and clients.
This short article will provide you with background on why this is not a good idea and not possible with current Java specifications and high level strategies to prevent stuck Threads at the first place.
Stuck Thread – What is it?
Stuck Thread problems are very common and can be hard to solve. A stuck Thread is basically a Thread which is hanging and / or has stopped its current assigned tasks for various reasons:
·         Thread waiting on a blocking IO call ex: hanging operation ·         Thread waiting to acquire a lock on an Object monitor (synchronized) ·         Thread forced to go in the wait() state ex: waiting to acquire a free JDBC Connection from a pool etc. ·         Thread involved in a real deadlock scenario e.g. Thread A waiting on Object monitor held by Thread B, Thread B waiting on Object monitor held by Thread A ·         Thread hanging on a disk IO operation ·         Thread hanging / paused due to excessive garbage collection going on ·         More scenarios…

Exactly the problem I’m facing, please tell me how I can kill these stuck Threads
The simple answer is that you cannot. Earlier Java specifications used to have Thread.stop(). This method was originally designed to destroy a thread without any cleanup:
·         Any monitors it held would have remained locked. However, the method was never implemented. If it were to be implemented, it would be deadlock-prone in much the manner of suspend(). ·          If the target thread held a lock protecting a critical system resource when it was destroyed, no thread could ever access this resource again. ·         If another thread ever attempted to lock this resource, deadlock would result. Such deadlocks typically manifest themselves as "frozen" processes.
You can also consult the official Oracle documentation on this subject.
As you can see, because of the above risk scenarios, such Thread stop mechanism is not implemented which does not allow your middleware vendor to expose any Thread stop button / functionality to the end user / middleware administrator.
In order to terminate stuck Threads, you have to bring down the entire JVM.
Any proposed solution?
Your best strategy is to prevent stuck Threads at the first place as much as possible and to properly perform root cause analysis & Thread Dump analysis post stuck Thread related incidents. As you can see in the above scenarios, typical stuck Thread problems are just “symptoms” of other problems so solutions include:
·         Proper timeout implementation to prevent forever hanging stuck Thread on blocking IO calls. Most communication API out there properly expose timeout methods allowing you to cap in seconds how long you are allowing your Threads to wait on remote resources (Web Services etc.) ·         Application code should be reviewed and optimized in order to eliminate wrong synchronized usage ·         Proper capacity planning of your environment is a must in order to prevent overload of key infrastructure components such as an Oracle DB which can trigger slow running queries and stuck Thread on middleware side ·          Deadlock scenarios are usually symptoms of code problem / code not Thread safe ex: re-using the same JDBC Connection object between 2..n Threads ·         Excessive IO / disk access can trigger stuck Threads, again symptoms of application problem(s) performing too much IO / class loading calls etc. ·         Lack of tuning, capacity planning and / or Java Heap memory leak may lead to excessive garbage collection and inevitably to stuck Threads; again symptoms of a bigger problem which requires proper Java Heap tuning and Heap Dump / application memory footprint analysis   I hope this article has helped you understand why you cannot and should not rely on Thread.stop() to fix your stuck Thread problems and strategies to prevent these problems at the first place.
Please don’t hesitate to post any comment or question about any stuck Thread problem you are currently facing.
Published at DZone with permission of Pierre - Hugues Charbonneau, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Michael Faes replied on Tue, 2012/12/25 - 9:26am

"The simple answer is that you cannot. Earlier Java specifications used to have Thread.stop(). This method was originally designed to destroy a thread without any cleanup: Any monitors it held would have remained locked. However, the method was never implemented."

No. Thread.stop() exists, it unlocks every monitor held by the thread and it is implemented. Deprecated, but implemented.

Vitalii Tymchyshyn replied on Sun, 2012/12/30 - 5:19pm

There is Thread.interrupt. I don't advocate using it much, it's another long story, but the article is not complete without mentioning it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.