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

Question

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

但实际上在生产中使用它会引入潜在的复杂性。比方说，尽管经过仔细的同行评审，我们还是执行了一个占用 CPU 的脚本，或者陷入了无限循环。我需要一些方法来杀死那个线程，pronto!因此，我正在考虑增强 groovy-shell-server 以支持正在运行的 Groovy 客户端线程的可选 hard stop()。

我知道Thread.stop() is inherently unsafe ;这是discussed on StackOverflow before .我的问题是，您认为在这种情况下 yield 是否大于风险？使用 Thread.stop() 作为失控的 GroovyShell 服务器线程的一种“紧急刹车”是一种务实的选择吗？或者让对象处于不一致状态的可能性太高？

(或者，如果有人有更好的方法来提供对正在运行的 Java 应用程序的程序化、可中断访问，我会洗耳恭听。)

Answer 1

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

但是没有规则没有异常(exception)。我认为是这样的。根据我的经验，Thread.stop() 有效并真正停止了线程。很多年前，我在针对 Netscape 的小程序中使用过它。它的某些版本不能很好地支持 Thread.interrupt()。

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

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