Java线程中断本身不自动触发响应或建立happens-before关系，真正建立该关系的是中断状态的volatile写（interrupt()）与后续volatile读（isInterrupted()、interrupted()或阻塞方法抛出InterruptedException）之间的同步。
Java 中线程中断本身不自动触发任何“响应处理”，happens-before 关系也不会因调用 interrupt() 而直接建立。真正建立 happens-before 的，是中断状态的写入与后续对中断状态的读取（如 isInterrupted()、Thread.interrupted() 或被阻塞方法抛出 InterruptedException）之间的同步动作。
中断状态变更写入建立 happens-before 边界
当线程 A 调用 threadB.interrupt() 时，JVM 会原子地将 threadB 的中断标志设为 true。这个写操作对其他线程可见的前提，依赖于 Java 内存模型中对 volatile 变量的语义保证——Thread 内部的中断状态字段是 volatile 的。因此：
- 该写操作构成一个同步点，对中断状态的后续读取（在正确同步下）能看到该值；
- 它不保证 threadB 中其他非 volatile 变量的写入立即对 A 可见，但能确保中断状态本身的可见性；
- 这满足 happens-before 规则中的 “volatile write → volatile read” 链路。
被阻塞方法抛出 InterruptedException 是关键响应点
很多阻塞方法（如 Object.wait()、Thread.sleep()、LockSupport.park()、BlockingQueue.take()）在检测到中断状态为 true 时，会：
- 清除中断状态（即设为 false）；
- 抛出
InterruptedException； - 这个异常抛出动作，隐含一次对中断状态的 volatile 读，并与之前的 interrupt() 写构成 happens-before 关系。
这意味着：在 catch 到 InterruptedException 后，你看到的程序状态（包括其他 volatile 变量或 synchronized 块中的共享变量），一定能看到 interrupt() 调用前已发生的操作（只要它们也遵循正确的同步规则）。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
手动检查中断状态需显式读取才能建立链路
如果线程未进入阻塞态，而是通过轮询方式响应中断（例如在 long-running 计算循环中），必须主动调用 Thread.currentThread().isInterrupted() 或 Thread.interrupted()：
-
isInterrupted()是 volatile 读，与之前任意线程执行的interrupt()（volatile 写）构成 happens-before； -
Thread.interrupted()也是 volatile 读，且会清中断状态； - 仅靠“中断发生”本身不会让代码暂停或跳转——响应逻辑（如 break、return、throw）必须由你显式编写。
常见误区：中断 ≠ 立即停止，≠ 自动清理资源
中断只是协作式信号，不是强制终止指令：
- 不会打断正在执行的普通字节码（比如密集计算循环），除非你插入检查点；
- 不会自动释放 synchronized 锁、关闭文件、回滚事务等——这些都需在响应中断后手动处理；
- 若忽略
InterruptedException（如空 catch），或重置中断状态后未传播，就破坏了中断语义，可能导致调用方永远等不到响应。
不复杂但容易忽略：happens-before 不是靠“中断”这个事件自动生效的，而是靠 volatile 读写配对 + 正确的响应代码共同完成的。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
