2

The Java Docs for Thread.stop() make it sound like the world will end if you ever call Thread.stop().

Deprecated. This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait. For more information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?.

If, for example, I'm running a method in a 3rd party, closed source library and I need to guarantee it ends in 5 minutes or less, is there any other way? What are the real-world consequences of using Thread.stop() and how can I identify if they happen?

bradvido
  • 2,743
  • 7
  • 32
  • 49
  • 1
    One consequence is that a deprecated method may be removed from a future release, rendering your code uncompilable/unrunnable. – Oliver Charlesworth Sep 22 '14 at 22:09
  • 7
    Short answer: NEVER. – Alexander Pogrebnyak Sep 22 '14 at 22:10
  • Look up thread.interupt. That is the method that replaced stop. – TheBat Sep 22 '14 at 22:12
  • 4
    @TheBat. Interrupt did not replace `stop`. It was there from the beginning – Alexander Pogrebnyak Sep 22 '14 at 22:15
  • 1
    see http://stackoverflow.com/questions/16504140/thread-stop-deprecated – Leo Sep 22 '14 at 22:16
  • 3
    @bradvido about stopping third party libraries: you can create separate process – turbanoff Sep 22 '14 at 22:18
  • 4
    *"I need to guarantee it ends in 5 minutes or less"* there is no way to "guarantee" this functionality. *"What are the real-world consequences of using Thread.stop() and how can I identify if they happen?"* that's the problem! there is no way to know as the functionality is undefined. It could leave other threads running,mist could leave resources open, it might maintain strong references to objects which won't be garbage collected, there's just no way to know, that's why you shouldn't use it... – MadProgrammer Sep 22 '14 at 22:20
  • Another real-world consequence: It could leave library objects in an unusable state. If they're global objects, then it will leave the entire library unusable. – Solomon Slow Sep 22 '14 at 22:22
  • Does this 3rd party, closed source library provide any way to shut it down? – David Conrad Sep 22 '14 at 22:33
  • 1
    @OliverCharlesworth There is no precedent for that assertion since at least 1.1. – user207421 Sep 22 '14 at 22:40
  • @AlexanderPogrebnyak Every javadoc and tutorial I have read indicates that interrupt should be used instead of stop, so certainly it may not have replaced it directly api wise, however it is the method that can be used to have the closest behavior. I'm sorry my original comment should have said: That is the method that SHOULD replace stop. – TheBat Sep 23 '14 at 15:18
  • Why does the method even exist? Was there ever a time in a prev. release when its use was acceptable and didn't cause the world to end? – bradvido Sep 23 '14 at 18:56

1 Answers1

5

Never!

Under no circumstances should you use Thread.stop().

If you think you need to call Thread.stop() don't! It will be wrong.

Thread.stop() should not be called under any circumstances.

Please do not call Thread.stop() - even if you are being threatened with death.

I donate this answer to community wiki please - others - join me in admonishing those heathens for the crime of calling Thread.stop() by editing this answer and adding your prayer that no mortal should call Thread.stop().

If you really want a process to be killed after 5 minutes - use a Process that can be destroyed. This will protect the main JVM from any potential corruption that might occur if a thread is terminated using Thread.stop(). However, this may leave files in a corrupted state, if the child Process was in the middle of I/O. One way to defend against that situation is to make the Process the client of a database that can roll back in-progress transactions.

In general, terminating something uncooperatively and safely is very, very difficult.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
  • 2
    Difficult, but not impossible. OS's such as Z/OS do it. Transaction monitors such as CICS do it. DBMS systems such as DB/2 do it. In all cases, because the admins of those systems NEED the functionality of killing a runaway process cold. – Erwin Smout Dec 03 '14 at 12:13