如何调试不明原因的线索中断在Java中

我越来越从詹金斯，堆栈跟踪的相关部分的InterruptedException：如何调试不明原因的线索中断在Java中

java.lang.InterruptedException 
    at java.lang.Object.wait(Native Method) 
    at hudson.remoting.Request.call(Request.java:127) 
    at hudson.remoting.Channel.call(Channel.java:646) 
    at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) 
    at $Proxy33.join(Unknown Source) 
    at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:861)

该中断是意外，至今原因不明。我几乎不可能在调试器的情况下做到这一点，它只发生在生产使用的CI上，而且很少发生，在Jenkins工作执行的1％以下。梳理各种日志到目前为止还没有产生任何有用的提示。远程Jenkins节点当时似乎没有断开连接。

问题：如何找出InterruptedException或其他可能有用的原因，并使用上述约束？

任何其他想法追查这种异常的原因也欢迎！也许是Jenkins/Hudson所特有的，不包括在this earlier question（这里的答案在这里并不真正有帮助）。

来源

2013-02-12 hyde

当您等待条件成立时，您应该调用Object :: wait。如果你被打断了，情况仍然是错误的，那就是一种虚假的唤醒。回到等待模式。 http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#wait%28%29 – 2013-02-12 08:40:33

@RKajaMohideen是的，除了它不是我的等待，所以看起来像是bug报告时间。 – hyde 2013-02-12 09:59:58

是的。如果图书馆等待一些目的。它必须预见到这种情况会被打断，并且应该处理要么再次等待，要么失败，而不是向客户抛出异常。 – 2013-02-12 10:11:43

InterruptedException看起来很正常。检查Jenkins源代码我发现它被处理（它们关闭catch块中的资源），然后重新抛出。开箱即用，我不明白为什么他们这么做（首先等待）。

在评论等待看前：

// I don't know exactly when this can happen, as pendingCalls are cleaned up by Channel, 
// but in production I've observed that in rare occasion it can block forever, even after a channel 
// is gone. So be defensive against that. 
wait(30*1000);

我要说的是有人加入等待克服“永远阻挡的难得的机会”，并在同一时间推出了死亡的中断从等待。

最好的办法是检查Jenkins问题跟踪器，并提交一份报告，指出您的工作失败，因为等待会不时中断，并取消远程调用。我想他们应该回到等待，如果他们想花这么多时间等待或继续，但不会在这一点上失败。

来源

2013-02-12 08:48:14 toomasr

不幸的是，它也没有很好的强调，而是等待一个条件最好的办法是通过编写代码，例如：

而（条件<>真）{

try { 
    wait(1000L); 
    //do something 
} 
catch (InterrruptedException e) { 
}

}

你必须警惕虚假的中断和代码。

来源

2013-10-04 05:35:06 inder

什么是“虚假中断”？我听说过（依赖于平台）虚假唤醒，但从来没有听说过虚假中断。反过来，共识是你至少应该设置中断标志（通过调用Thread.currentThread（）。interrupt（））来捕获一个InterruptedException，并且在任何情况下都不应该按照你的方式吞下它提议。 – laszlok 2017-08-30 15:03:09

如何调试不明原因的线索中断在Java中

回答

相关问题