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()进行非常大的道歉评论. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |