interrupt() 是协作式中断信号而非强制终止，仅设置中断标志或在阻塞方法中抛出 InterruptedException 并清标志，需线程主动响应。
interrupt() 不是“强制杀死线程”，而是发一个协作信号
很多人一看到 interrupt() 就以为能立刻停掉线程，结果发现线程还在跑、isInterrupted() 返回 false、甚至抛出的 InterruptedException 被吞了也没反应——根本原因是没理解它的设计意图：它只是一个“建议线程该考虑退出了”的标志位，不带强制性。
真正起作用的是线程自己怎么响应这个信号。JVM 只在少数阻塞方法（如 Thread.sleep()、Object.wait()、LockSupport.park()）中检查中断状态，并主动抛出 InterruptedException；其余时候，全靠你手动轮询 Thread.currentThread().isInterrupted()。
- 阻塞中被中断 → 抛
InterruptedException，同时自动清除中断状态（isInterrupted()变成false） - 非阻塞中调用
interrupt()→ 仅设置中断标志，不抛异常，也不影响执行流 - 手动捕获
InterruptedException后，若没重设中断状态（比如没调Thread.currentThread().interrupt()），上层就收不到信号了
在 while 循环里怎么安全响应中断
绝大多数自定义线程逻辑都写在 while (!Thread.currentThread().isInterrupted()) 这类循环里，但光这么写不够——如果循环体里有阻塞操作，得处理好异常传播和状态恢复。
典型错误是把 InterruptedException 捕获后空着，或者只打日志不重设中断。这会导致外层调用者永远等不到线程结束。
立即学习“Java免费学习笔记（深入）”；
- 阻塞操作（如
queue.take()、socket.read()）必须放在 try-catch 中 - catch 块里不要直接 return，优先调用
Thread.currentThread().interrupt()恢复中断状态 - 循环条件别用
!Thread.interrupted()（它会清标志），改用!Thread.currentThread().isInterrupted()
while (!Thread.currentThread().isInterrupted()) {
try {
String task = queue.poll(1, TimeUnit.SECONDS);
if (task != null) process(task);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 关键：恢复中断状态
break;
}
}
ExecutorService.shutdownNow() 为什么有时停不掉任务
调用 shutdownNow() 本质就是遍历所有活跃线程并对其调用 interrupt()。它停不掉，说明任务内部没响应中断——常见于：用了死循环+无中断检查、阻塞 I/O 没封装成可中断形式、或用了第三方库的不可中断操作（比如老版本 java.net.Socket 的 InputStream.read()）。
-
shutdownNow()返回未执行的Runnable列表，不是“已停止的任务列表” - 如果任务正在执行 CPU 密集型计算且没主动检查中断，
interrupt()完全无效 - 某些 NIO 操作（如
SocketChannel.read()）可被中断，但传统 BIO 不行；替换成AsynchronousSocketChannel或加超时更可靠
中断和 volatile boolean stopFlag 该怎么选
两者都能实现线程协作退出，但语义和场景不同：interrupt() 是标准协议，自带对阻塞 API 的集成支持；而 volatile boolean 更轻量，适合纯计算型、无阻塞逻辑的简单场景。
混用容易出问题：比如同时检查 stopFlag 和 isInterrupted()，但没统一退出路径，导致一部分清理逻辑被跳过。
- 有调用任何可能抛
InterruptedException的方法 → 必须用interrupt()，否则无法唤醒阻塞 - 纯 while + 计算 + 无阻塞调用 →
volatile boolean足够，代码更直白 - 不要在同一个线程里既依赖
interrupt()又依赖自定义 flag 做退出判断，选一个并贯彻到底
中断机制的复杂点不在 API 本身，而在于它要求你把“退出”这件事拆解到每一处可能阻塞或长耗时的地方。最容易被忽略的是：捕获 InterruptedException 后忘记重置中断状态，或者在 finally 块里做了耗时清理却没再检查一次中断。
