interruptedexception 是线程协作信号而非错误，捕获后必须调用 thread.currentthread().interrupt() 恢复中断状态，否则线程将失去响应能力。
InterruptedException 不是异常，是线程协作的信号
Java 中 InterruptedException 的本质不是“出错了”，而是当前线程被其他线程调用了 interrupt()，且它正阻塞在 wait()、join()、sleep() 或某些 java.nio 操作上。JVM 强制你处理它，因为这是唯一能安全退出阻塞状态的契约。
常见错误现象：catch (InterruptedException e) { e.printStackTrace(); } —— 这等于丢弃中断信号，后续调用 Thread.currentThread().isInterrupted() 会返回 false，线程失去响应能力。
- 必须在捕获后恢复中断状态：调用
Thread.currentThread().interrupt() - 不要用
throw new RuntimeException(e)包装后往上抛，除非你明确不负责中断传播 - 如果当前方法声明了
throws InterruptedException，优先选择直接抛出，而非吞掉
在 Runnable / Callable 中正确响应中断
线程任务主体（比如 ExecutorService 提交的 Runnable）往往没有声明抛出 InterruptedException，所以不能直接 throw，必须自己处理中断逻辑。
使用场景：后台轮询任务、长耗时计算中需支持优雅停止。
立即学习“Java免费学习笔记（深入）”；
- 检查
Thread.currentThread().isInterrupted()作为循环退出条件，尤其在 while(true) 中 - 捕获
InterruptedException后，立即设标志位或 break 循环，再调用Thread.currentThread().interrupt() - 避免在 catch 块里继续执行业务逻辑（如发 HTTP 请求、写日志），这会让中断延迟生效
while (!Thread.currentThread().isInterrupted()) {
try {
doWork();
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
break; // 退出循环
}
}
sleep / wait / join 调用前是否要检查中断？
不需要提前检查。这些方法本身就会在进入阻塞前检测中断状态，并立即抛出 InterruptedException。提前调用 isInterrupted() 是冗余的，还可能漏掉“检查后、阻塞前”被中断的窗口。
但要注意：这些方法抛出异常后，**中断状态会被自动清除**（即 isInterrupted() 返回 false），所以必须手动恢复。
-
sleep(1000)抛出InterruptedException→ 当前线程中断状态已清零 -
wait()和join()行为一致，同样清中断状态 - 所有阻塞调用后的
catch块里，第一句应为Thread.currentThread().interrupt()
Future.cancel(true) 为什么有时不生效？
Future.cancel(true) 的 “true” 表示“尝试中断执行任务的线程”，但它只对处于阻塞态（如 sleep/wait/join）或主动检查 isInterrupted() 的线程有效。如果任务正在执行纯 CPU 计算且无中断检查点，中断信号不会终止它。
性能影响：频繁检查 isInterrupted() 几乎无开销；但放在 tight loop 内部（如每毫秒一次）可能轻微影响吞吐，实际中极少成为瓶颈。
- 确保任务逻辑中有明确的中断检查位置，比如循环体头部或每次 I/O 前
- 不要依赖
Future.cancel(true)强制杀线程 —— Java 没有stop()，强行终止会导致资源泄漏或状态不一致 - 若任务封装在第三方库中（如某 SDK 的同步调用），需查阅其文档是否响应中断；不响应就只能靠超时或外部 kill 进程
真正难的是把中断贯穿整个调用链：从顶层 ExecutorService.shutdownNow()，到中间层 Future.cancel(true)，再到最底层每个 sleep 和每个循环判断。漏掉任意一环，中断就卡住了。
