为何处理InterruptedException时应重新中断而非调用interrupted()？

首先得明确一个容易被忽略的关键细节：当JVM抛出InterruptedException时，会自动清除当前线程的中断标志。这就是重新中断操作的核心意义——你得把这个中断信号“恢复”出来，让上层代码能感知到中断请求的存在。

咱们拆解下问题里的疑问和误区：

为什么重新中断是正确实践？ #

中断本质是线程间的协作信号，不是强制终止命令。假设你的线程执行链是：上层业务逻辑 -> 你的方法 -> 阻塞API（比如sleep/wait）。当阻塞API抛出InterruptedException时，JVM已经清掉了中断标志，如果不在catch块里重新设置，上层业务逻辑就完全不知道“有人要中断这个线程”这件事，会继续执行，直接违背了中断的初衷。

举个实打实的例子：

public void run() {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            // 调用阻塞方法
            Thread.sleep(1000);
            doBusinessWork();
        } catch (InterruptedException e) {
            // 如果这里不重新中断，下一次循环的isInterrupted()会返回false，循环继续执行
            // Thread.currentThread().interrupt(); // 正确做法：重新设置中断标志
            log.error("睡眠被中断", e);
        }
    }
    // 清理资源并退出
    cleanup();
}

如果catch块里不重新中断，哪怕外部调用了线程的interrupt()，循环也会一直跑下去——因为isInterrupted()拿不到中断信号。而重新中断后，下一次循环检查就会发现中断标志为true，从而退出循环并执行清理逻辑。

为什么不能用interrupted()清除标志？ #

首先，interrupted()是静态方法，它的作用是清除当前线程的中断标志，并返回清除前的状态。这和我们需要的“恢复中断信号”完全相反：

• 当你捕获到InterruptedException时，中断标志已经被JVM清了，此时调用interrupted()只会返回false，毫无意义；
• 如果在其他场景滥用interrupted()清除标志，会直接把上层传递的中断信号吞掉，导致线程无法正确响应终止请求。

你给出的示例代码：

if (Thread.interrupted()) {
    throw new InterruptedException();
}

这是另一种场景——主动检查中断标志并抛出异常，通常用在非阻塞的业务逻辑里，让方法能向上传递中断信号。但这和“捕获已抛出的InterruptedException后处理”是两回事，不能混为一谈。

总结 #

处理InterruptedException时，重新中断线程的核心目的是保留中断信号的传递链，让线程执行栈的上层代码能感知到中断请求，从而做出正确的终止或处理逻辑。而调用interrupted()清除标志会破坏这个信号链，导致线程无法正确响应中断。

内容的提问来源于stack exchange，提问作者Sriharsha g.r.v