Java app服务器能够销毁线程吗？ 如果有，怎么样？
销毁线程在Java中已弃用（并未根据javadoc实现），并且中断它只是在线程预期退出时的建议，但可能不会这样做。 （不提供任何方法来杀死J VM中的线程是一个令人不安的设计，但我的问题与设计无关。）
Java应用程序服务器如何卸载应用程序？ 他们能以某种方式破坏正在卸载的应用程序的线程吗？ 如果有，怎么样？ 如果不是，那么具有无限循环的已部署应用程序的单个线程可能会导致整个应用服务器无法进行干预？
对不起，我不是为此编写测试用例，但我想知道那里到底发生了什么。
您不能在ejb服务器中创建自己的线程。
在Web容器（例如tomcat）中生成线程并不常见，尽管您应该仔细考虑这样做 – 并确保管理这些线程的生命周期。
不提供任何方法来杀死J VM内部的线程是一个令人不安的设计，但我的问题不是设计相关。
由于您的真实问题已经得到解答，我将解决上面引用的句子。
历史是Java设计者最初尝试解决杀死和挂起线程的问题，但是他们遇到了一个他们无法在Java语言环境中解决的基本问题。
问题是你根本无法安全地杀死可以以非primefaces方式改变共享数据的线程，或者可以使用wait / notify机制与其他数据同步的线程。 如果您在此上下文中实现线程终止，则最终会对数据结构进行部分更新，而其他线程则等待通知永远不会到达。 换句话说，杀死一个线程可能会使应用程序的其余部分处于不确定和破坏状态。
允许你杀死线程的其他语言/库（例如C，C ++，C＃）遇到了我上面描述的相同问题，即使相关的规范/教科书没有说清楚。 尽管可以杀死线程，但在整个应用程序的设计和实现中必须非常小心，以便安全地执行此操作。 一般来说，要做对决太难了。
那么（假设）如何在Java中使线程查杀安全？ 以下是一些想法：
-
如果您的JVM实现了Isolates，您可以启动您可能想要在子Isolate中杀死的计算。 问题是正确实现的隔离只能通过消息传递与其他隔离通信，并且它们通常使用起来要昂贵得多。
-
共享可变状态的问题可以通过完全禁止变异或通过向Java执行模型添加事务来解决。 这两者都会从根本上改变Java。
-
等待/通知的问题可以通过用集合或消息传递机制替换它来解决，该机制允许“其他”线程被告知它正在与之交互的线程已经消失。 “其他”线程仍然需要编码才能从中恢复。
编辑 – 回应作品。
Mutex死锁不是thread.destroy()的问题，因为它旨在释放（中断）被破坏的线程拥有的所有互斥锁。 问题是，在锁被破坏之后，无法保证受互斥锁保护的数据结构将处于正常状态。
如果我正确理解了这个主题的历史， Thread.suspend() ， Thread.delete()等确实在现实世界的Java 1.0应用程序中引起了问题。 而且这些问题非常严重，应用程序编写者很难处理，JVM设计人员认为最好的方法是弃用这些方法。 这不是一个容易做出的决定。
现在，如果你很勇敢，你可以实际使用这些方法。 在某些情况下，它们实际上可能是安全的。 但围绕弃用方法构建应用程序并不是合理的软件工程实践。