捕获 InterruptedException 后必须调用 Thread.currentThread().interrupt() 以恢复中断状态，否则上层无法感知取消信号；应避免误用 Thread.interrupted() 清除状态，且恢复操作仅限 catch 块内，不可放在 finally 中。
捕获 InterruptedException 后必须调用 Thread.currentThread().interrupt()
Java 中，InterruptedException 是一个受检异常，意味着你不能忽略它——要么处理，要么声明抛出。但很多人只做了 catch，然后空着或打个日志就完事，这会丢失线程的中断状态，导致上层逻辑无法感知“该停了”。中断不是错误，是协作式取消信号，丢掉它等于把刹车踩进了虚空。
常见错误现象：ExecutorService 提交的任务里 catch 了 InterruptedException 却没恢复中断，结果 shutdownNow() 失效；或者 while (!Thread.currentThread().isInterrupted()) 循环永远不退出。
- 只要你在
catch块里没打算立即终止当前逻辑（比如正在清理资源），就必须立刻执行Thread.currentThread().interrupt() - 不要用
Thread.interrupted()替代——它会清中断状态，且是静态方法，容易误判当前线程 - 如果方法签名不允许抛出
InterruptedException（如实现了某个不声明该异常的接口），恢复中断后可转为RuntimeException包装，但需确保调用方知情
什么时候该抛出 InterruptedException 而不是捕获它
如果你的方法本身是阻塞型操作的封装（比如自定义的带超时的队列取数、封装了 Object.wait() 的同步工具），那它应该把 InterruptedException 向上声明，而不是自己吞掉。这是对调用方的尊重：你没资格替别人决定“中断要不要生效”。
使用场景举例：BlockingQueue.poll(long, TimeUnit) 抛出 InterruptedException，所以你写的 safePoll() 方法若内部调用了它，就不该 catch，除非你有明确的重试/降级策略且能保证语义不变。
立即学习“Java免费学习笔记（深入）”；
- 方法体中调用了任何声明抛出
InterruptedException的 JDK 方法（如Thread.sleep()、Object.wait()、Lock.lockInterruptibly()、Condition.await()），且未做语义转换，就应直接 throws - 若方法已声明 throws
InterruptedException，就别在内部 try-catch —— 除非你要做原子性补偿（如释放锁 + 恢复中断） - 注意泛型接口限制：像
Runnable不允许 throws 受检异常，此时只能捕获并恢复中断，再考虑是否包装为RuntimeException
interrupt() 被调用后，为什么 isInterrupted() 有时返回 false
因为 Thread.interrupted()（静态方法）和 isInterrupted()（实例方法）行为不同。前者查询并清除状态，后者只查不清除。很多调试时发现“我明明 interrupt() 了，怎么 isInterrupted() 还是 false”，大概率是之前某处误用了 Thread.interrupted()。
性能影响很小，但语义混淆代价很高：中断状态被意外清除，后续循环或判断就失效。
- 在条件判断中始终用
Thread.currentThread().isInterrupted()，别用Thread.interrupted() -
Thread.interrupted()只应在需要“查询+清除”原子语义时使用，例如在 catch 块末尾做一次最终确认并清理，但此时你本该已经恢复过中断了 - 注意线程池中的任务线程可能被复用，中断状态不会自动重置，所以上一个任务遗留的中断可能影响下一个——这也是必须显式管理的原因
在 finally 块里恢复中断容易出错
有人觉得“反正要恢复，不如统一写在 finally”，结果代码在未触发中断时也执行了 interrupt()，反而污染了线程状态。中断恢复必须与捕获点严格对应，不能笼统兜底。
典型翻车现场：在 try 里调用 sleep()，catch 里记录日志但忘了恢复中断，finally 里又无条件 interrupt() —— 看似保险，实则让所有执行路径都中断了线程。
- 恢复中断只发生在真正捕获到
InterruptedException的catch块内，且仅在此处 -
finally里只做资源清理（关流、解锁等），绝不碰中断状态 - 如果清理过程本身可能阻塞（如
socket.close()在某些条件下会等），它也可能抛InterruptedException，这时得单独处理，不能指望外层 catch 覆盖
