在失控的GroovyShell服务器线程上调用Thread.stop是否风险太大？

Question

我想在我们的应用程序中添加groovy-shell-server.我们最近遇到了几个生产问题,内部API的调用可以加快诊断速度,甚至可以提供短期修复.Groovy-shell-server提供了一种实现这一目标的好方法.

但实际上在生产中使用它会带来潜在的复杂性.让我们说,尽管经过仔细的同行评审,我们还是会执行一个固定CPU的脚本,或者陷入无限循环.我需要一些方法来杀死那个线程,发音!所以我在考虑增强groovy-shell-server以支持正在运行的Groovy客户端线程的可选硬件停止().

我知道Thread.stop()本质上是不安全的 ; 之前在StackOverflow上讨论过它.我的问题是,您认为这种情况下的好处可能超过风险吗？使用Thread.stop()作为一种失控的GroovyShell服务器线程的"紧急制动"是一种实用的选择吗？或者将对象置于不一致状态的可能性太高了？

(或者,如果某人有更好的方式来提供对正在运行的java应用程序的编程,可中断访问,我会全力以赴.)

Answer 1

我认为通常使用已弃用的 API 是不好的，特别是不建议使用Thread.stop().

但没有无例外的规则。我认为是这样的。根据我的经验，Thread.stop()有效并且确实停止了线程。很多年前我在针对 Netscape 的小程序中使用过它。它的一些版本支持得不好Thread.interrupt()。

我能想到的唯一替代解决方案是使用单独的流程。但在这种情况下，您必须实现一些进程到进程的传输来进行数据传输。我不知道你的任务细节，但通常价格太高。

所以，如果我是你，我会使用Thread.stop()非常大的道歉评论。