java - Java 应用程序服务器是否能够销毁线程？如果是，如何？

Question

销毁线程在 Java 中已被弃用(并且未根据 javadoc 实现)，并且中断它只是一个建议，希望线程退出，但可能不会这样做。 (不提供任何方法来终止 JVM 内的线程是一个令人不安的设计，但我的问题与设计无关。)

Java应用服务器如何卸载应用程序？他们是否能够以某种方式破坏正在卸载的应用程序的线程？如果是，如何？如果不是，那么具有无限循环的已部署应用程序的单个线程可能会在没有任何干预可能性的情况下导致整个应用程序服务器崩溃？

抱歉，我不是为此编写测试用例，但我想知道那里到底发生了什么。

Answer 1

Not to provide any way to kill a thread inside the JVM is a disturbing design, but my question is not design related.

Since your real question has be answered, I'm going to address the quoted sentence above.

The history is that the Java designers originally did try to address the issue of killing and suspending threads, but they ran into a fundamental problem that they could not solve in the context of the Java language.

The problem is that you simply cannot kill safely threads that can mutate shared data in a non-atomic fashion or that can be synchronizing with other using a wait/notify mechanism. If you do implement thread killing in this context, you end up with partial updates to data structures, and other threads waiting for notifies that will never arrive. In other words, killing one thread may leave the rest of the application in an uncertain and broken state.

Other languages/libraries (e.g. C, C++, C#) that do allow you to kill threads suffer from the same problems I described above, even if the relevant specifications/text books do not make this clear.While it is possible to kill threads, you have to be really careful in the design and implementation of the entire application to do this safely. Generally speaking it is too hard to get right.

So (hypothetically) what would it take to make thread killing safe in Java? Here are some ideas:

• If your JVM implemented Isolates you could launch the computation that you might want to kill in a child Isolate. The problem is that a properly implemented isolate can only communicate with other isolates by message passing, and they would generally be a lot more expensive to use.

• The problem of shared mutable state could be addressed by banning mutation entirely, or by adding transactions to the Java execution model. Both of these would fundamentally change Java.

• The problem of wait/notify could be addressed by replacing it with a rendezvous or message passing mechanism that allowed the "other"thread to be be informed that the thread it was interacting with has gone away. The "other"thread would still need to coded to recover from this.

EDIT - In response to commments.

Mutex deadlock was not an issue for thread.destroy() since it was designed to release (break) all mutexes owned by the thread that was destroyed. The problem was that there were no guarantees that the data structure that was protected by the mutex would be in a sane state after the lock was broken.

If I understand the history of this topic correctly, Thread.suspend(), Thread.delete() and so on really did cause problems in real world Java 1.0 applications. And these problems were so severe, and so hard for application writers to deal with, that the JVM designers decided that the best course was to deprecate the methods. This would not have been an easy decision to make.

Now, if you are brave you can actually use these methods. And they may actually be safe in some cases. But building an application around deprecated methods is not sound software engineering practice.