InterruptedException 不表示线程被终止，仅说明阻塞中收到中断请求；JVM 会自动清除中断标志并抛出异常，需在 catch 中调用 interrupt() 恢复标志位，否则中断信号丢失。
InterruptedException 不是线程被“杀掉”了
Java 中抛出 InterruptedException，不代表线程已经终止或被强制停止——它只是说明「当前线程在阻塞状态（如 sleep()、wait()、join()）时收到了中断请求」。JVM 会自动清除线程的中断标志位，并抛出异常，这是设计使然，不是 bug。
常见错误现象：
- 捕获 InterruptedException 后只写了个空 catch 块，导致中断信号彻底丢失
- 以为 catch 住就完事了，没重设中断状态，上游逻辑无法感知本次中断意图
- 必须在
catch块中调用Thread.currentThread().interrupt()来恢复中断标志位，除非你明确决定“吃掉”这个中断 - 如果方法声明了
throws InterruptedException，就别自己 catch；让调用方处理，否则容易破坏协作契约 - 非阻塞代码（比如纯计算循环）不会自动响应中断，得手动轮询
Thread.interrupted()判断并退出
interrupt() 和 interrupted() / isInterrupted() 的区别
这三个东西常被混用，但语义和副作用完全不同：
-
thread.interrupt()：对目标线程发起中断请求（设置其中断标志位），若该线程正阻塞，则触发InterruptedException -
Thread.interrupted()：静态方法，**查询且清空**当前线程的中断标志位 —— 注意“清空”这个副作用，连续调用两次，第二次总会返回false -
thread.isInterrupted()：实例方法，仅查询指定线程的中断状态，**不改变标志位**
典型误用：
- 在 while 循环里写 if (Thread.interrupted()) break; 看似合理，但如果循环体里其他代码也调用了 interrupted()，你就可能漏判中断
建议场景：
- 循环中判断中断 → 用 Thread.currentThread().isInterrupted()（安全、无副作用）
- 想“消费一次”中断并退出 → 可用 Thread.interrupted()，但确保这是你最后一次检查
为什么 sleep() 被中断后要重置 interrupt 标志
因为 sleep()、wait()、join() 这些方法在抛出 InterruptedException 前，JVM 已经帮你调用了 clearInterrupted()。也就是说，异常抛出那一刻，中断标志位已经是 false 了。
如果不手动重置：
- 外层逻辑（比如线程池的 shutdownNow()）依赖中断来清理资源，就会失效
- 自定义的取消逻辑（如 while (!Thread.currentThread().isInterrupted())）会继续跑下去
正确做法示例：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 关键：恢复中断状态
return; // 或 throw new RuntimeException(e);
}
线程池中处理中断容易忽略的点
用 ExecutorService 提交任务时，shutdownNow() 会尝试对所有活跃线程调用 interrupt()，但它**只对阻塞中的线程有效**。
- 如果任务在执行 CPU 密集型计算，没有主动检查中断，
shutdownNow()几乎没用 - 使用
Future.cancel(true)也是同理：只中断阻塞，不终止正在运行的代码 - 线程池默认拒绝策略（如
AbortPolicy）不会触发中断，需自行包装任务做中断感知
真正可靠的取消，永远需要任务自身配合：在循环中定期检查 Thread.currentThread().isInterrupted()，并在合适位置退出或释放资源。
中断不是“远程 kill”，它是协作式通知机制。漏掉一次重置、少查一次标志位，整个取消链路就断了。
