CyclicBarrier 的 broken 状态是不可逆的屏障失效标记，一旦触发所有 await() 调用立即抛 BrokenBarrierException；其由中断、超时、barrierAction 异常或 reset() 设置，且无法自动恢复，必须重建实例。
CyclicBarrier 的 broken 状态不是“临时故障”，而是一种**不可逆的屏障失效标记**。一旦触发，所有正在等待或后续调用 await() 的线程都会立即抛出 BrokenBarrierException——哪怕其他线程一切正常、也未中断。
broken 状态是怎么被设置的
当任意一个参与线程在 await() 过程中因以下任一原因退出等待，CyclicBarrier 内部的 broken 标志位就会被设为 true：
- 线程被
interrupt()中断（进入await()后被中断，或调用前已带中断状态） - 带超时的
await(timeout, unit)超时返回（注意：超时本身不抛异常，但会触发 broken） - 屏障动作（
barrierAction）执行时抛出未捕获异常 - 手动调用
reset()（重置操作会强制置 broken 为 true，再清空等待队列）
为什么一个线程中断会影响全部
CyclicBarrier 设计上是“全有或全无”的同步点：它不区分“谁先到、谁后到”，只关心“是否凑齐”。只要有一个线程无法完成抵达（比如被中断），就说明本轮同步已不可能达成。此时继续让其余线程傻等，既无意义又易引发死锁或资源泄漏。因此，JDK 直接将屏障标记为 broken，并唤醒所有等待者，统一抛出 BrokenBarrierException，迫使调用方主动处理失败场景。
broken 后的状态不可自动恢复
broken 是一个只写不自动清除的状态：
-
isBroken()返回true后，该 CyclicBarrier 实例即宣告“报废” -
await()不再阻塞，而是立即抛异常 - 即使调用
reset()，也只是重置计数器并清空等待队列，不会自动修复 broken 状态；reset 本身会先置 broken 为 true，再重建内部状态 - 真正恢复可用，必须新建实例，或在 reset 后确认
!isBroken()
实际编码中怎么应对
关键不是避免中断，而是让中断成为可预期、可收敛的控制信号：
- 在
catch(InterruptedException)块中，优先调用Thread.currentThread().interrupt()恢复中断状态，便于上层感知 - 在
catch(BrokenBarrierException)中，应视为本轮协同失败，通常需清理资源、记录日志、决定是否重试或降级 - 若业务允许部分失败，可改用
CountDownLatch或自定义协调逻辑，而非强依赖“全员抵达”语义 - 避免在 barrierAction 中做 I/O、锁竞争或可能抛异常的操作；如必须，应在内部
try-catch并吞掉异常（否则直接导致 broken）
