interruptedexception 是线程协作中断的明确信号，必须显式处理：响应中断（清理资源后退出）或恢复中断状态后向上抛出，禁止忽略或仅打印日志。
InterruptedException 不是普通错误，而是线程协作中断的明确信号。处理它的核心不是“吞掉”或“掩盖”，而是尊重中断意图：要么立即响应并退出，要么恢复中断状态让上层决定。
必须捕获并显式处理
它属于受检异常（checked exception），编译器强制要求处理。不能用空 catch 块忽略，也不能只打印日志就继续执行。
- 空 catch（
catch (InterruptedException e) {}）会丢失中断语义，线程可能无限阻塞或无法及时关闭 - 仅
e.printStackTrace()而不恢复中断状态，等于告诉系统“我收到了中断，但假装没看见” - 正确做法：在 catch 块中做两件事——清理资源 + 明确表态（响应或传播）
两种主流处理策略
选择哪一种，取决于当前方法是否适合承担“中断响应者”的职责。
- 响应中断（推荐用于业务线程/任务主体）：在 catch 中释放锁、关闭流、取消正在进行的操作，然后 return 或 break 出主循环，让线程自然终止
-
恢复中断并向上抛出（推荐用于工具方法/库代码）：调用
Thread.currentThread().interrupt()重置中断标志，然后直接throw e或声明throws InterruptedException。这样调用链上游能统一决策
常见阻塞点的典型写法
对 sleep、wait、join、CountDownLatch.await、BlockingQueue.take 等，都需按相同逻辑处理：
- 不要用
Thread.interrupted()检查后自行 sleep —— 它会清中断标志，后续再进阻塞方法仍可能抛异常 - 正确模板示例：
try {<br> Thread.sleep(1000);<br>} catch (InterruptedException e) {<br> Thread.currentThread().interrupt(); // 恢复<br> return; // 或 throw new RuntimeException(e)<br>} - 若方法签名已声明
throws InterruptedException，通常不应自己 catch，除非你要做原子性补偿（如释放锁后再恢复中断）
和 InterruptedIOException 的协同处理
当代码同时涉及线程等待和 IO（比如网络请求中 sleep 等待重试），两者中断语义一致：
- 捕获
InterruptedIOException后，同样应调用Thread.currentThread().interrupt() - 关闭 socket、channel、stream 等资源，避免泄漏
- 不建议把
InterruptedException包装成RuntimeException向上抛，否则上层无法区分“线程被中断”和“其他运行时故障”
