interrupt() 不会立即停止线程，仅设置中断标志；需配合 isinterrupted()、interrupted() 和阻塞方法的 interruptedexception 响应，且捕获异常后须重设状态或主动退出，否则中断信号丢失。
interrupt() 不会立即停止线程，它只是设个标志
很多人看到 thread.interrupt() 就以为线程会立刻退出，结果发现 while 循环还在跑、IO 还卡着、sleep 也没醒——这是因为 interrupt() 只是给线程打了个「中断请求标记」，具体响不响应、什么时候响应，全看线程自己有没有检查这个标记。
Java 提供了三个关键配套机制来配合这个标记：
-
Thread.currentThread().isInterrupted()：查当前线程是否被中断（不清除状态） -
Thread.interrupted()：查当前线程是否被中断（并清除状态） - 阻塞方法（如
Thread.sleep()、Object.wait()、LockSupport.park()）在检测到中断时会抛出InterruptedException
捕获 InterruptedException 后必须重设中断状态或显式退出
这是最常踩的坑：在 catch (InterruptedException e) 里只打印日志或什么都不做，线程继续跑，中断信号就丢了。
正确做法只有两种，二选一：
立即学习“Java免费学习笔记（深入）”；
- 在 catch 块里调用
Thread.currentThread().interrupt()把中断状态恢复回去（让上层代码还能感知） - 直接 return 或 break 出循环，主动结束当前逻辑
反例：
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
System.err.println("被中断了"); // ❌ 状态丢失，后续 isInterrupted() 返回 false
}
while (!Thread.currentThread().isInterrupted()) 循环不是万能的
这个写法适合纯计算型循环，但一旦线程在阻塞操作里（比如读网络、等锁、wait），它根本进不了循环头去检查标志，就会一直挂起。
真正健壮的循环结构要兼顾「主动检查 + 阻塞响应」：
- 循环体内部要定期调用
isInterrupted() - 所有可能阻塞的地方（
sleep、wait、join、BlockingQueue.take()等）都得包在 try-catch 里 - 避免在 synchronized 块里长时间执行，因为
wait()虽可被中断，但monitorenter本身不可中断
ExecutorService.shutdownNow() 的实际效果很有限
调用 shutdownNow() 本质就是对所有存活工作线程调一遍 interrupt()，但它不能终止正在运行的 CPU 密集型任务，也不能强制杀掉 native 调用或死循环。
它的作用范围仅限于：
- 已提交但尚未开始执行的任务：从队列中移除并返回
- 正在阻塞中的任务：靠
interrupt()唤醒（前提是它们响应中断） - 正在执行的非阻塞任务：什么也不会发生，除非你自己写了中断检查逻辑
所以，依赖 shutdownNow() 实现“优雅停止”，前提是每个任务都遵循中断协议——否则你关的只是个空壳。
真正难的不是调那个方法，而是确保每条执行路径都尊重 isInterrupted() 和 InterruptedException。漏一处，整条链就卡住。
