Java线程中断本身不抛异常，仅在可中断阻塞方法中抛InterruptedException，该异常是内存可见性的同步点，构成happens-before关系；需正确处理中断状态以维持JMM语义。
Java 中线程中断本身（如调用 thread.interrupt()）不会直接抛出异常，只有当被中断的线程在可中断的阻塞方法中（如 Thread.sleep()、Object.wait()、LockSupport.park()、BlockingQueue.take() 等）时，才会抛出 InterruptedException。这个异常的抛出与 happens-before 关系密切相关——它不仅是控制流信号，更是内存可见性的同步点。
中断状态写入与异常抛出构成 happens-before 链
根据 Java 内存模型（JMM），当线程 A 调用线程 B 的 interrupt() 方法时：
- A 对 B 中断状态的写入（设置
interrupted标志位）对 B 是可见的； - 该写入操作与 B 后续检测到中断并抛出
InterruptedException之间，存在隐式的 happens-before 关系； - 更关键的是：抛出
InterruptedException的那一刻，JVM 保证该异常发生前所有对共享变量的写入（由 A 或其他线程完成），对 B 在异常处理块中读取这些变量是可见的。
正确响应中断才能维持 happens-before 语义
仅仅捕获 InterruptedException 并不自动建立同步效果——必须配合规范的中断处理逻辑：
-
不要忽略中断：空 catch 块（
catch (InterruptedException e) {}）会丢失中断状态，破坏 happens-before 的传递性； -
恢复中断状态：在无法继续抛出该异常的场景（如 Runnable 实现），应调用
Thread.currentThread().interrupt()重置标志位，使上层代码能感知中断； - 在 finally 或 cleanup 中依赖中断状态做决策时，需确保读取发生在异常抛出之后——此时 JMM 保障了之前写操作的可见性。
与 volatile 和 synchronized 的协同作用
中断机制本身不替代显式同步，但可与其它同步原语组合强化 happens-before：
- 若线程 B 在
synchronized块中被中断，抛出InterruptedException时，已持有的锁会被正常释放，且释放动作与异常抛出之间存在 happens-before； - 若共享变量声明为
volatile，A 修改该变量后中断 B，则 B 在catch块中读该变量，无需额外同步即可看到 A 的写入——因为中断事件触发的异常抛出，与 volatile 读之间也通过 JMM 的“中断 happens-before”规则建立了传递链。
实际编码建议
要让中断真正满足 happens-before 约束，记住三点：
- 阻塞方法调用必须放在 try-catch 中，并在 catch 里恢复中断或向上抛出；
- 非阻塞的循环逻辑应主动检查
Thread.interrupted()，并在退出前确保关键状态已刷新； - 避免在中断处理中引入竞态：比如在 catch 块里修改共享对象时，仍需考虑是否需要加锁或使用原子类，因为中断只保证“异常发生点”的内存可见性，不保证整个处理过程的原子性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
