我想将groovy-shell-server添加到我们的应用程序中。我们最近遇到了几个生产问题，内部API的调用可以加快诊断速度，甚至可以提供短期修复。 Groovy-shell-server提供了一种实现这一目标的好方法。
但实际上在生产中使用它会带来潜在的复杂性。让我们说，尽管经过仔细的同行评审，我们还是会执行一个固定CPU的脚本，或者陷入无限循环。我需要一些方法来杀死那个线程，发音！所以我在考虑增强groovy-shell-server以支持正在运行的Groovy客户端线程的可选硬件停止（）。
我知道Thread.stop() is inherently unsafe;它是discussed on StackOverflow before。我的问题是，您认为这种情况下的好处可能超过风险吗？使用Thread.stop（）作为一种失控的GroovyShell服务器线程的“紧急制动”是一种实用的选择吗？或者将对象置于不一致状态的可能性太高了？
（或者，如果某人有更好的方法来提供对正在运行的java应用程序的编程，可中断访问权限，那么我会全力以赴。）
答案 0 :(得分：4)
我认为使用弃用的API通常不好，特别是不建议使用Thread.stop()。
但是没有例外的规则。我想是这样的。根据我的经验Thread.stop()工作并真正停止线程。我在很多年前在针对Netscape的applet中使用过它。它的某些版本不支持Thread.interrupt()。
我能想到的唯一替代解决方案是使用单独的流程。但在这种情况下，您必须实现一些进程到进程的传输以进行数据传输。我不知道你的任务的细节，但通常价格太高。
所以，如果我是你，我会使用Thread.stop()非常大的道歉评论。