1

我有一个长时间运行的过程，由于错误，一个琐碎/可消耗的线程与我想继续的线程死锁，以便它可以执行一些难以以另一种方式重现的最终报告。

当然，为以后的运行修复错误是正确的最终解决方案。当然，任何线程的任何此类强制中断/终止/停止本质上都是不安全的，并且可能导致其他不可预知的不一致。（我熟悉所有标准警告及其原因。）

但是，由于唯一的选择是终止 JVM 进程并经历一个更冗长的过程，这将导致最终报告不太完整，因此混乱/弃用/危险/有风险/一次性技术正是我想要的尝试。

JVM 是 Ubuntu 上 Sun 的 1.6.0_16 64 位，消耗线程正在等待锁定对象监视器。

定向到确切线程的 OS 信号能否在可消耗线程中创建 InterruptedException？

附加gdb，直接篡改JVM数据或调用JVM过程，是否可以强制释放消耗线程持有的对象监视器？

Thread.interrupt()来自另一个线程的 a会InterruptedException从等待锁定帧中生成 a 吗？（通过一些努力，我可以将任意 beanshell 脚本注入到正在运行的系统中。）

Thread.stop()是否可以通过 JMX 或任何其他远程注入方法发送已弃用的？

任何想法表示赞赏，越“危险”越好！而且，如果您的建议在类似情况下的个人经验中起作用，那就最好了！

4

2 回答 2

2

定向到确切线程的操作系统信号可以InterruptedException在消耗线程中创建一个吗？

不。

附加gdb，直接篡改JVM数据或调用JVM过程，是否可以强制释放消耗线程持有的对象监视器？

理论上是的。在实践中，您需要深入了解 JVM 的内部结构才能获得成功。所以，实际上没有。

Thread.interrupt()来自另一个线程的 a会InterruptedException从等待锁定帧中生成 a 吗？（通过一些努力，我可以将任意 beanshell 脚本注入到正在运行的系统中。）

理论上是的。实际上，beanshell 脚本需要找到Thread要中断的线程的对象。这可能涉及遍历ThreadGroup对象树等。另一个问题是被中断的线程是否会正常运行。例如，很多人编写他们的等待/通知代码来捕获/忽略InterruptedException并重试。如果你这样做了，中断可能不会有任何好处。

可以通过 JMX 或任何其他远程注入方法发送已弃用的 Thread.stop() 吗？

如果可以调用Thread.interrupt()，则可以使用相同的方法调用Thread.stop()。通常情况下，我会说不要这样做。但在这种情况下，它可能值得一试。

但从这一切中得到的真正教训是，一个可能需要数天或数周才能产生答案的应用程序应该实现一个检查点/恢复机制来处理这种可能性，比如电源故障、硬件故障、机器重启、等等

于 2010-05-06T04:06:40.827 回答
0

忘了它。在最好的情况下，您可以通过一些看门狗计时器检测到死锁，忽略被卡住的线程，并创建新线程以继续工作。不是很满意。您无法解锁所涉及的锁，并且有两个锁被持有（或更多）。你不能让“消耗性”线程释放它持有的锁。

有一个相当简单的方法来检测潜在的死锁：为每个锁分配一个从 1 向上的级别。执行规则“在持有锁时，线程只能获取较低级别的锁”。如果您发现违反规则，请修复编号。如果它无法修复，那么你就有一个潜在的死锁，如果运气不好，它可能会变成一个真正的死锁。更改您的代码。

于 2014-02-24T23:11:58.303 回答