java - (已弃用的)myThread.stop()的有效用例？

Question

今天，Java的盛行宗教严重禁止在stop() [1] [2] [3]上使用Thread实例方法。在official documentation中将其标记为(已弃用的)，并显示以下消息:

This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. [...]

甚至提供了一个 whole article，它会进一步详细介绍。 (特别是 ThreadDeath到达顶部时是无声的，即使您防护它，也无论如何也无法防护 Thread.stop(Throwable t)。)

总的来说，我同意该文章所担心的问题以及 related question on StackOverflow的答案-在世界上几乎所有的用例中，都有一种比 stop()更好的方法。但不是所有的。

这是一个用例，我正在努力寻找一种更好的方法。我邀请你的建议。

用例

我正在使用在Java之上运行的交互式控制台，该控制台允许用户以交互式解释的方式运行任意Java语句和调用Java的Python函数。 (有关屏幕截图，请参见 Jython console。)

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

当用户这样弄乱时，我需要给他们一个杀死线程的机会(使用按钮)， 挽救，这是他们在 session 中产生并存储在局部变量中的其余工作。

如果在线程上调用 interrupt()失败(例如，如果在陷入无限循环时从未进入等待状态)，那么我们将面临两个选择，我可以看到:(1)彻底杀死应用程序，或者(2)使用 stop()在错误的线程上，让用户抢救所有尚未损坏的内容。

是的，我知道某些物体可能已经损坏，无法正常工作。但是，我们谈论的是抢救所有可能处于有效状态的东西(除了一两个东西外，几乎所有东西都可以保留)。

有人能看到这个推理有什么问题吗？并且，如果这证明是一个有效的用例，那么这是否意味着不应该弃用该方法:)？

Answer 1

调用Thread.stop()是一个坏主意。故事结局。

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

听起来您正在寻找某人来确认您的用例以某种方式避免了JVM的风险。否，因此您不太可能得到这样的确认。如果您看不到问题会给您带来更大的力量，但是当它以莫名其妙或危险的方式失败时，请不要感到惊讶。

正如Peter Lawrey所建议的那样，您应该在一个隔离的JVM中运行此不受信任的代码，在JVM中，操作系统的进程管理可以支持杀死占用大量资源的进程。如果您无法做到这一点，因为您正在传递奇怪的资源，例如打开文件描述符，那就是您的问题。