BrokenBarrierException 表示屏障已破损，所有 await() 必然失败；它不携带失败原因，barrierAction 不会执行；回滚须由各线程用 AtomicBoolean 协同完成，reset() 需由单一协调线程在无 await 时调用。
CyclicBarrier 的 BrokenBarrierException 不是失败信号，而是屏障已失效的明确通知。它不表示“某个子任务失败”，而表示“同步契约已被破坏，后续 await() 必定失败”。想靠它触发回滚，必须先理解：它本身不携带失败原因，也不区分是中断、超时还是 reset 导致——所有路径都归为同一异常类型。
BrokenBarrierException 出现时，所有线程都已失去同步保障
一旦任一线程在 await() 中抛出 BrokenBarrierException，说明屏障进入破损状态（isBroken() 返回 true），此时：
- 所有仍在等待的线程会立即被唤醒并抛出该异常
- 后续任何线程调用
await()都会立刻抛出该异常，不会阻塞 -
reset()可以恢复屏障，但不会自动重试或补偿已失败的线程逻辑
回滚动作不能放在 barrierAction 里执行
很多人误以为在构造 CyclicBarrier 时传入的 barrierAction 能用于统一回滚，这是错的：
-
barrierAction只在所有线程成功到达时才执行；一旦有线程抛出BrokenBarrierException，barrierAction根本不会运行 - 它没有访问其他线程局部状态的能力，无法感知谁失败、失败到哪一步
- 它运行在线程池中某个随机线程上，不适合做跨线程资源清理
真正可行的回滚结构：每个线程自己负责自己的补偿
由于 CyclicBarrier 本身不提供失败传播机制，回滚必须由业务线程主动承担。典型做法是：
- 用共享的
AtomicBoolean rollbackTriggered = new AtomicBoolean(false)标记是否已启动全局回滚 - 每个线程在
try块中执行核心任务，在catch (BrokenBarrierException | InterruptedException)中尝试 CAS 设置该标记 - 若成功设置，则执行本地回滚逻辑（如数据库事务回滚、临时文件删除、缓存清除）；若失败，说明其他线程已触发，跳过重复操作
- 主线程或协调者需监听所有任务完成（例如用
CompletableFuture.allOf()），检查是否有任意任务因异常退出，再决定是否发起最终一致性修复
示例关键片段：
AtomicBoolean rollbackTriggered = new AtomicBoolean(false);
CyclicBarrier barrier = new CyclicBarrier(3);
for (int i = 0; i {
try {
doCriticalWork(); // 如写DB、发MQ
barrier.await(); // 同步点
} catch (BrokenBarrierException | InterruptedException e) {
if (rollbackTriggered.compareAndSet(false, true)) {
rollbackLocalChanges(); // 真正的回滚动作
}
Thread.currentThread().interrupt();
}
});
}
容易被忽略的复杂点：屏障破损后 reset() 的时机与竞争
reset() 是危险操作：
- 它会强行释放所有等待线程并抛出
BrokenBarrierException，但不会等待这些线程处理完异常——可能和你的回滚逻辑并发执行 - 如果多个线程同时检测到破损并尝试
reset()，会引发IllegalMonitorStateException（内部锁未持有） - 正确方式是：只由一个协调线程（如主线程或专用 watcher）在确认全部任务已退出后再调用
reset()，且必须确保此时无线程正在调用await()
换句话说，CyclicBarrier 本身不支持“自动失败转移”，它的职责只是同步；回滚是业务层必须显式编排的独立流程。
