CODEWITHSUNDEEP
javamultithreading
GAlexMES
GAlexMES

Reputation: 355

Is there really no way to forcefully kill a Thread in Java?

Intro:

Since Thread.stop() is deprecated the only way (as far as I know) to stop a Thread is to interrupt it.

The javadoc says, that interrupting a Thread means, that the thread's interrupt status will be set.

But doesn't that mean, that a Thread that is ignoring the interrupt flag will never terminate? I guess in most cases the application developer is also developing the Runnable, that is executed inside the Thread. So ignoring the interrupt flag is basically his own fault and I am totaly fine with this.

But:

What about the Edge case? What about Applications, that use a custom plugin mechanism for example. Maybe you want to load a jar and let in run inside a newly created thread. Then the application itself loses all the power to manage the thread. It totally depends on the goodwill of the plugin developer, that he or she provides some way to stop the code (using the Reflection API and custom Annotations or whatever).

I also have other examples in mind, where it might be necessary to kill a Thread.

My Conclusion

I am totally aware why killing a Thread using Thread.stop is not the best idea. But I am kind of confused, why this option should be removed completely. I also had a look inside the concurrent API and I couldn't find a stop equivalent there neither.

Please share your thoughts about this.

Upvotes: 2

Views: 624

Answers (1)

Stephen C
Stephen C

Reputation: 719259

Is there really no way to forcefully kill a Thread in Java?

There is really no way safe way to forcefully kill a single Thread in Java.

Thread.stop() has been deprecated since Java 1.2 because it is inherently unsafe.

Some of the related methods have actually been removed, but countFrames(), pause(), resume() and stop() are still there.

It would be really nice if there was a safe way to stop a thread that isn't cooperating, but the Java designers realized a long time ago that Thread.stop:

  1. potentially leaves objects in an indeterminate state, and
  2. potentially leaves other threads waiting for notifications and condition variable changes that will never happen.

These mean that stopping a thread is liable to cause the rest of the application to behave unpredictably. Furthermore, designing an application to recover from a stopped thread is (in general) impractical.

Unfortunately, there really is no solution to this in the confines of the Java thread model.

(You would need an alternative model where threads can only communicate by passing messages, and cannot share mutable state. You could then code an application to be resilient in the face of threads being stopped or crashing. However, this change would require a rewrite of the vast majority of existing Java code. It was not possible in 1998. It is even less possible now.)

For more details on the reasons for deprecation, read the javadoc and Java Thread primitive deprecation technical note.

But doesn't that mean, that a Thread that is ignoring the interrupt flag will never terminate?

Correct1. That is a bug, either:

  • in the code that is not paying attention to the flag, or
  • in the application that allows untrustworthy plugin code (that ignores the flag) to run.

1 - But not completely correct. The application could also call System.exit if a thread refused to die, or it could rely on an external monitor or human intervention: ^C, kill -9. This is how you would deal with the problem in practice.

I am also aware about that article. As I said, I know about the problems of Thread.stop(). Just because it is a bad way to do it and could result in side effects isn't a reason to forbid it completely.

It is not completely forbidden. It is deprecated.

Treat it as very strong advice.

Upvotes: 4

Related Questions