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

前端之家收集整理的这篇文章主要介绍了java – 在失控的GroovyShell服务器线程上调用Thread.stop是否风险太大?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

我想在我们的应用程序中添加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应用程序的编程,可中断访问,我会全力以赴.)

最佳答案
我认为使用已弃用的API通常是不好的,特别是不建议使用Thread.stop().

但是没有例外的规则.我想是这样的.根据我的经验,Thread.stop()工作并真正停止线程.我在很多年前在针对Netscape的applet中使用过它.它的一些版本不支持Thread.interrupt().

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

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

原文链接:https://www.f2er.com/java/437903.html

猜你在找的Java相关文章