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<runnable></runnable>是尚未执行的任务，可用来做清理或重试，别直接丢弃 - 注意线程池状态：调用后线程池进入
STOP状态，新任务会被拒绝，但已提交且未被中断的线程仍可能运行完
自定义可中断逻辑时，别漏掉非阻塞场景下的中断检查
中断不只是为 sleep/waits 准备的。计算密集型任务（比如遍历大数组、解析长 JSON、渲染图像）同样需要响应中断，否则用户点了“取消”，程序就卡死在那里。
容易被忽略的是：这些场景不会自动抛异常，必须手动插入检查点。
- 在长循环体内定期调用
if (Thread.currentThread().isInterrupted()) { break; } - 避免把整个耗时操作包在一个 try-catch 外面，然后只在最后 check 一次中断——中间可能已跑了几分钟
- IO 操作（如
InputStream.read()）默认不响应中断，要用java.nio.channels.InterruptibleChannel（比如FileChannel）或配合Selector才行
interrupt()，而是忘了在线程真正干活的地方看一眼那个标志位。 
