真的没有办法强制杀死Java中的线程吗？

Question

简介：

（据我所知）Thread.stop()被弃用到stop的唯一方法是，线程将其中断。

javadoc说，中断线程意味着the thread's interrupt status will be set。

但这不是意味着，忽略中断标志的线程永远不会终止吗？我猜在大多数情况下，应用程序开发人员也在开发Runnable，该Runnable在Thread中执行。因此，忽略中断标志基本上是他自己的错，对此我完全可以接受。

但是：

Edge外壳怎么样？那么使用自定义插件机制的应用程序呢？ 也许您想加载一个jar并在新创建的线程中运行。然后，应用程序本身失去了管理线程的所有功能。这完全取决于插件开发人员的信誉，即他或她提供了某种停止代码的方法（使用Reflection API和自定义注释或其他方法）。

我还想到了其他示例，在这些示例中可能有必要杀死线程。

我的结论

我完全知道为什么使用Thread.stop杀死线程不是最好的主意。但是我有点困惑，为什么应该完全删除此选项。我还查看了并发API的内部内容，在那儿也找不到停止等价物。

请分享您对此的想法。

Answer 1

  

真的没有办法强行杀死Java中的线程吗？

实际上没有安全方法来强制杀死Java中的单个线程。

从Java 1.2开始，

Thread.stop()已被弃用，因为它本质上是不安全的。

实际上已经删除了一些相关方法，但是countFrames()，pause()，resume()和stop()仍然存在。

如果有一种安全的方式来停止不合作的线程，那将非常好，但是Java设计人员很久以前就意识到了Thread.stop：

1. 可能使对象处于不确定状态，并且
2. 可能使其他线程等待通知和条件变量更改，这些更改将永远不会发生。

这意味着停止线程可能导致应用程序的其余部分行为异常。此外，设计应用程序以从停止的线程中恢复通常是不切实际的。

不幸的是，在Java线程模型的范围内，确实没有解决方案。

（您将需要一个替代模型，其中线程只能通过传递消息进行通信，并且不能共享可变状态。然后，您可以对应用程序进行编码，使其在线程停止或崩溃时具有弹性。但是，此更改将需要重写了绝大多数现有的Java代码。这在1998年是不可能的，现在已经不可能了。）

有关弃用原因的更多详细信息，请阅读javadoc和Java Thread primitive deprecation技术说明。

---

  

但这不是意味着忽略中断标志的线程永远不会终止吗？

正确的 ¹ 。那是一个错误，或者：

• 代码中未关注该标志的位置，或
• 在允许不可信插件代码（忽略该标志）的应用程序中运行。

^{1-但不完全正确。如果线程拒绝死亡，则应用程序也可以调用System.exit，或者可以依赖外部监视器或人为干预：^C，kill -9。这是您在实际中}

处理问题的方式。

---

  

我也知道那篇文章。如我所说，我知道Thread.stop()的问题。仅仅因为这是一种不好的方法并且可能导致副作用，并不是完全禁止它的理由。

这不是完全禁止的。已弃用。

将其视为非常有力的建议。