Java线程中断需主动检查状态、及时清理并传递信号：阻塞方法自动抛InterruptedException并清标志，应捕获后恢复中断或上抛；非阻塞循环须轮询isInterrupted()；清理资源放finally中，避免忽略或误重置中断。
Java 中正确响应线程中断，核心在于：主动检查中断状态 + 及时清理 + 不屏蔽中断信号。interrupt() 是协作式中断请求，不是强制终止；isInterrupted() 用于查询当前线程是否被中断，但不会清除中断标志；而 Thread.interrupted() 会清除标志。关键不是“怎么调用”，而是“在哪儿查、怎么处理、怎么退出”。
在可中断的阻塞操作中自然响应
很多 JDK 方法（如 Thread.sleep()、Object.wait()、LockSupport.park()、BlockingQueue.take() 等）本身支持中断：一旦线程在这些方法中被 interrupt()，会立即抛出 InterruptedException，并自动清除中断状态（即 isInterrupted() 随后返回 false）。这时你不需要手动调 isInterrupted()，而是要捕获异常并决定如何退出。
- 不要空 catch InterruptedException（比如只写 catch (InterruptedException e) {}），这等于丢弃中断信号
- 通常做法是：恢复中断状态（Thread.currentThread().interrupt()）后 return 或 throw，让调用方知道“我被中断了”
- 如果当前方法声明 throws InterruptedException，可直接向上抛出
在长时间运行的非阻塞循环中主动轮询
当线程执行的是纯计算、IO 循环或自定义等待逻辑（没调用上述阻塞方法）时，JVM 不会自动触发中断响应，必须手动检查中断状态。
- 在循环条件中加入 !Thread.currentThread().isInterrupted()，让循环自然退出
- 避免使用 while(true) + break，应写成 while (!Thread.currentThread().isInterrupted()) { ... }
- 注意：isInterrupted() 不会清标志，适合反复检查；而 interrupted() 是静态方法，会清标志且只对当前线程有效，慎用
清理资源与保证原子性
收到中断请求不等于立刻停止——要先完成必要的清理（如关闭文件、释放锁、回滚事务），再退出。否则可能留下不一致状态。
立即学习“Java免费学习笔记（深入）”；
- 把清理逻辑放在 finally 块或 try-with-resources 中，确保无论是否中断都会执行
- 若清理过程也可能阻塞（如 close() 内部有 IO），需再次检查中断或捕获其抛出的 InterruptedException
- 避免在 finally 中调用可能长时间阻塞且不可中断的方法（如无超时的 socket.read()）
不要重置中断状态除非你明确负责传递
Thread.currentThread().interrupt() 的作用是“重新设置中断标志”，常用于捕获 InterruptedException 后又无法立即退出时（比如需要先清理），把中断信号“还给”上层。误用会导致中断丢失。
- 只在你捕获了 InterruptedException 且决定继续执行（而非退出）时才调 interrupt()
- 如果方法已决定退出（return / throw），无需再 interrupt()
- 永远不要在 catch (InterruptedException e) { /* 忽略 */ } 后调 interrupt() —— 这样做毫无意义
中断机制本质是协作协议。没有魔法，也没有强制力。真正起作用的是开发者是否在关键位置检查、是否尊重异常、是否妥善收尾。写多线程代码时，把“这里会不会被中断？”当成和“这里会不会空指针？”一样日常的问题来思考，就离正确不远了。
