（不推荐使用的）mythread.stop（）的有效用例？

Question

这种方法本质上是不安全的。使用thread.stop停止线程会导致它解锁已锁定的所有监视器（这是未经检查的threaddeath异常沿堆栈向上传播的自然结果）。如果以前由这些监视器保护的任何对象处于不一致的状态，则损坏的对象将对其他线程可见，从而可能导致任意行为。[...]

甚至有一整篇文章提供了更详细的。（尤其是ThreadDeath在到达顶部时是静默的，即使您防范它，也无法防范Thread.Stop(Throwable t)。）

总的来说，我同意这篇文章所担心的问题，并同意StackOverflow相关问题的答案--在世界上几乎所有的用例中，都有一种比stop()更好的方法。但不是全部。

这里有一个用例，我正在努力为它想出更好的方法。我请你提建议。

我正在使用一个运行在Java之上的交互式控制台，它允许用户以交互式解释的方式运行调用Java的任意Java语句和Python函数。（有关截图，请参阅Jython控制台。）

现在，用户可以编写任意函数。其中一些方法可能会调用Java方法，导致无限循环，打印大量输出，几乎使系统饱和，从而使系统响应变得非常慢。

是的。我知道有些物体可能已经损坏，不能正常工作了。但是我们正在讨论的是挽救任何可能被留在有效状态的东西（这可能是几乎所有的东西，除了一两件东西）。

有没有人觉得这个推理有什么问题？如果这是一个有效的用例，那么这是否意味着该方法不应该被弃用：）？

Answer 1

调用thread.stop()是个坏主意。故事结束了。

它可能在实践中起作用，但您在此过程中牺牲了JVM的大部分并发性保证。您的整个程序本质上运行的是未定义的行为。可能损坏的不仅仅是线程或线程中的数据，而是当线程被杀死时恰好处于易受攻击状态的JVM的任何部分。

这听起来像是您在寻找一个人来确认您的用例以某种方式避免了JVM的风险。它不是，所以你不太可能得到这样的确认。如果你没有看到问题对你更大的力量，但当它以莫名其妙或危险的方式失败时，不要感到惊讶。