JVM外部因素能否中断Process.waitFor()方法调用？

先贴出出现问题的核心代码：

try {
    int exitCode = myProcess.waitFor();
    // do things with this code
} catch (InterruptedException ie) {
    // log stuff here including thread name, but otherwise swallow the exception
}

这套处理外部进程的工具代码已经稳定运行十余年，近期客户遇到异常：main线程被中断，导致外部进程执行中断、无法获取正确退出码。目前已排除主动中断逻辑（除关机场景外没有相关代码）。

我梳理了两种可能的触发原因：

• 线程进入waitFor()之前就已经被中断
• waitFor()执行期间被其他因素中断

前置代码未发现异常，打算通过调用Thread.interrupted()来排查并临时规避第一种情况，但目前有个核心疑问：是否存在JVM外部因素会导致第二种情况发生？

我自己做了测试：执行一个等待30秒的外部脚本，尝试各种方式终止它，Java Process都能返回正确的退出码，完全复现不了外部中断waitFor()的场景。谷歌搜了一圈也只找到中断的处理方法，没找到引发中断的外部因素相关内容，所以来提问。

另外补充：虽然全面重构处理这个问题更规范，但改动量大且没法测试，而Thread.interrupted()调用没什么负面影响，还能帮我们定位潜在问题，所以更倾向用这个方案。

针对核心疑问的解答 #

通常来说，JVM外部因素无法直接触发Java线程的中断，因为Java的线程中断是JVM内部机制，中断标志是线程的内部状态，操作系统或外部程序没法直接修改这个状态。不过有几种间接关联的外部场景需要排查：

1. 操作系统信号触发：如果JVM进程收到了SIGINT（比如Ctrl+C）、SIGTERM这类操作系统信号，JVM可能会通过中断线程来响应。比如客户环境里有人手动给JVM发了信号，或者系统管理工具触发了信号发送，这种情况通常会伴随JVM退出或其他信号处理的痕迹，需要查系统日志。
2. 容器/编排环境干预：如果应用跑在Docker、Kubernetes这类容器环境里，当容器被重启、资源不足被驱逐时，容器 runtime 可能会给JVM发信号，进而引发线程中断。
3. 第三方工具介入：客户环境如果有监控、调试或安全类的第三方工具，这些工具如果通过JVM Attach API接入JVM，理论上有可能触发线程中断，但这种情况非常少见，而且一般会有操作日志可查。

关于Thread.interrupted()方案的合理性 #

这个方案完全可行：

• Thread.interrupted()会清除线程的中断标志，避免后续进入waitFor()时直接抛出异常，同时可以通过记录它的返回值，确认是不是存在前置中断的情况，帮你定位问题。
• 改动量极小，没有副作用，适合当前没法大规模改代码和测试的场景。

额外排查建议 #

• 拉取客户环境的JVM日志、操作系统系统日志，看看有没有信号传递、进程异常相关的记录。
• 加细日志：在进入waitFor()前后记录线程的中断状态，以及外部进程的PID、执行状态，方便后续出问题时定位。

内容的提问来源于stack exchange，提问作者Bobby