线程中断机制详解：如何优雅停止运行线程

Thread.interrupt()仅设置中断标志，线程是否响应取决于自身逻辑；需主动检查isInterrupted()或正确处理InterruptedException，阻塞方法被中断时抛出该异常并清空中断状态，shutdownNow()仅尝试中断运行线程并取消未执行任务。

Java 中 Thread.interrupt() 不会直接终止线程，它只是设个标志

很多人以为调用 interrupt() 就像按了“强制关机键”，线程立刻停住。实际不是：它只把线程的中断状态设为 true，至于线程是否响应、何时响应、怎么响应，完全取决于线程自己写的逻辑。

典型错误现象：interrupt() 调了，但线程还在跑，日志照打，CPU 占着不放——因为代码里根本没检查中断状态，也没处理 InterruptedException。

• 必须主动轮询 Thread.currentThread().isInterrupted()（推荐，不重置状态）或 Thread.interrupted()（会清空标志，慎用）
• 阻塞方法如 Thread.sleep()、Object.wait()、LockSupport.park() 等收到中断时会抛出 InterruptedException，且自动清除中断状态
• 如果捕获了 InterruptedException 却只打印日志然后继续循环，等于把中断“吞掉”了，线程无法退出

为什么 InterruptedException 是受检异常，而且必须处理

这不是 Java 故意为难人，而是强制你面对“线程可能被中断”这个现实。阻塞操作一旦被中断，语义上意味着“我本该等下去，但现在被要求放弃”，这个信号不能被忽略。

常见错误写法：catch (InterruptedException e) { e.printStackTrace(); } —— 这样中断状态丢了，外层逻辑再无从感知。

• 正确做法之一：在 catch 块末尾补上 Thread.currentThread().interrupt()，把中断“还回去”
• 另一种是明确决定终止当前任务，在 catch 里 break 或 return，不再继续执行后续逻辑
• 不要用 throws InterruptedException 一路往上抛，除非你真能保证上层会处理；很多框架（比如 Runnable 实现）根本不允许抛出该异常

ExecutorService.shutdownNow() 的真实行为：发中断 + 尝试取消未启动任务

shutdownNow() 不是“杀掉所有线程”，它做三件事：尝试中断所有正在运行的 worker 线程、取消所有尚未开始执行的 Future 任务、返回等待执行的任务列表。

关键点在于：“尝试中断” ≠ “线程一定停止”。如果线程没响应中断，它就继续跑；而那些已经进入 run() 方法、又没做任何中断检查的 Runnable，shutdownNow() 对它完全无效。

• 务必确保提交给线程池的任务是可中断的：检查中断状态、响应 InterruptedException、避免无限忙等（比如 while(true) { } 里没加中断判断）
• shutdownNow() 返回的 List 是尚未执行的任务，可用来做清理或重试，别直接丢弃
• 注意线程池状态：调用后线程池进入 STOP 状态，新任务会被拒绝，但已提交且未被中断的线程仍可能运行完

自定义可中断逻辑时，别漏掉非阻塞场景下的中断检查

中断不只是为 sleep/waits 准备的。计算密集型任务（比如遍历大数组、解析长 JSON、渲染图像）同样需要响应中断，否则用户点了“取消”，程序就卡死在那里。

容易被忽略的是：这些场景不会自动抛异常，必须手动插入检查点。

• 在长循环体内定期调用 if (Thread.currentThread().isInterrupted()) { break; }
• 避免把整个耗时操作包在一个 try-catch 外面，然后只在最后 check 一次中断——中间可能已跑了几分钟
• IO 操作（如 InputStream.read()）默认不响应中断，要用 java.nio.channels.InterruptibleChannel（比如 FileChannel）或配合 Selector 才行

中断机制本身很轻量，真正复杂的是你怎么把它织进自己的业务逻辑里。最常出问题的地方不是不会调 interrupt()，而是忘了在线程真正干活的地方看一眼那个标志位。