Java中处理InterruptedException必须调用Thread.currentThread().interrupt()恢复中断状态，因为JVM抛出该异常时会自动清除中断标志，否则上层无法检测中断意图，导致线程无法安全退出、资源泄漏或违反协作中断契约。
Java中处理InterruptedException不是“捕获完事”，而是要尊重中断意图、恢复中断状态，并配合业务逻辑安全退出。核心在于：中断是协作信号，不是强制杀线程；异常抛出时JVM已清除中断标志，不手动重置就等于丢掉通知。
为什么必须调用Thread.currentThread().interrupt()
当Thread.sleep()、BlockingQueue.take()等可中断方法被中断时，JVM会：
- 立即抛出
InterruptedException； - 自动将线程的中断状态设为
false（即isInterrupted()返回false）。
如果不调用Thread.currentThread().interrupt()，上层代码（如线程池的shutdownNow()、任务调度器或自定义循环条件）就无法通过isInterrupted()检测到中断意图，可能导致：
- 工作线程持续运行，线程池无法真正关闭；
- 资源未释放、计数器未递减、超时逻辑失效；
- 违反JDK协作中断契约，影响整个并发组件链路。
标准三步响应模式
在catch块中推荐按顺序执行：
立即学习“Java免费学习笔记（深入）”；
- 完成必要清理：关闭文件流、释放锁、回滚临时状态；
- 调用
Thread.currentThread().interrupt()恢复中断标志； - 明确退出当前逻辑：用
return、break或抛出自定义运行时异常（如RuntimeException(e)）。
示例：
Thread.sleep(1000);
} catch (InterruptedException e) {
closeResource(); // 清理
Thread.currentThread().interrupt(); // 恢复中断
return; // 安全退出
}
循环任务中的中断检查要点
纯计算型循环不会自动触发InterruptedException，必须主动轮询中断状态：
- 用
Thread.currentThread().isInterrupted()判断（非静态interrupted()，避免误清状态）； - 检查点放在循环开头，防止一次迭代耗时过长而延迟响应；
- 阻塞操作前/后都应检查，尤其在
catch中恢复中断后立即break。
反例：只在sleep里处理中断，但循环体中密集运算几十秒——用户请求取消后仍需等待很久才退出。
Runnable / Callable 中的特殊注意事项
实现Runnable.run()时不能声明抛出InterruptedException（编译报错），所以必须在catch中恢复中断并退出；
而工具方法若声明throws InterruptedException，则无需手动恢复中断——由调用方负责处理，这是JDK标准做法（如CountDownLatch.await()）。
注意：不要把InterruptedException包装成RuntimeException再抛出，除非你确定上层能识别并重新中断；更不要在finally块中无条件调用interrupt()，这会覆盖真实中断上下文。
