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