interruptedexception 是线程被中断时抛出的检查异常，需恢复中断状态或向上抛出，不可吞掉；它表示协作式中断通知，非线程终止信号。
InterruptedException 是线程被中断时抛出的检查异常，不是“线程已死”的信号
很多人一看到 InterruptedException 就立刻 catch 了事，甚至直接吞掉——这是最危险的做法。它本质是 JVM 在调用 Thread.sleep()、Object.wait()、Thread.join() 等阻塞方法时，检测到当前线程的中断状态（isInterrupted() == true）后主动抛出的提示：「你正在等的东西被外部要求中止了，该你来决定怎么收场」。
常见错误现象：
- catch
InterruptedException后只写个空块或打个日志，没重置中断状态 - 在业务逻辑里反复调用
sleep(1000)，但忽略中断，导致线程无法及时响应 shutdown 请求 - 把
InterruptedException当作运行时异常处理，不声明也不捕获，编译直接失败（因为它是 checked exception）
捕获后必须恢复中断状态，否则上层代码会“失联”
JVM 抛出 InterruptedException 的同时，会自动清空线程的中断标志（即 Thread.interrupted() 会返回 true，但之后再调就变 false）。如果你不手动恢复，上层调用者（比如一个线程池的 shutdownNow()）就再也感知不到这个中断意图了。
正确做法只有两种，选其一：
立即学习“Java免费学习笔记（深入）”；
- 在 catch 块末尾调用
Thread.currentThread().interrupt()，把中断状态“还回去” - 明确决定本次操作要彻底退出，并向上抛出
InterruptedException（适用于你写的工具方法）
反例：
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// ❌ 错误：什么都没做，中断标志丢失
}
正例：
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // ✅ 恢复中断状态
return; // 或 throw new RuntimeException(e);
}
不要在 finally 里调用 interrupt()，那会覆盖真实意图
有些人在 try-catch-finally 结构里，为了“保险”，在 finally 块中强行调用 thread.interrupt()。这会导致两个问题：
- 如果线程本来没被中断，你硬给它标上中断，可能干扰正常流程（比如后续的
wait()突然被唤醒） - 如果线程本已被中断，你又 interrupt 一次，虽然不会报错，但掩盖了原始中断发生的位置和上下文
中断请求应由发起方（如主线程调用 workerThread.interrupt()）发出，响应方只需尊重并传递它，而不是在收尾时“代劳”。
ExecutorService.shutdownNow() 发送中断，但你的任务必须能响应
调用 shutdownNow() 并不等于所有任务立即停止。它只是对每个活跃线程调用 interrupt()，真正能否退出，取决于任务内部是否正确处理了 InterruptedException 和中断状态。
典型陷阱：
- 任务里用了
while (!Thread.currentThread().isInterrupted()) { ... }，但循环体中调用BlockingQueue.take()—— 这个方法会响应中断并抛异常，但如果你没捕获，线程就直接终止，while 条件根本没机会再判断 - 任务里用
Thread.sleep()做轮询延时，却没在 catch 后恢复中断，导致shutdownNow()后线程还在傻等下一轮
所以，凡是涉及阻塞调用的任务，都得把 InterruptedException 处理链串起来，不能断在中间。
复杂点在于：中断不是“强制杀线程”，而是协作式通知。只要有一处没响应，整条链就卡住。这点容易被忽略，直到压测或运维时发现线程池关不干净。
