我想在我们的应用程序中添加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应用程序的编程,可中断访问,我会全力以赴.)
最佳答案
原文链接:https://www.f2er.com/java/437903.html