Java 中 CyclicBarrier 怎么保障多线程任务执行的步调一致

CyclicBarrier 本质上是一个“集体就位、统一放行”的同步工具。简单来说，它不看你谁先做完，而是要求所有线程必须在同一个屏障点集合完毕，然后一起出发。而且这个过程可以反复执行，这才是它名字里“Cyclic”的由来。

固定参与者 + 集体等待

在使用 CyclicBarrier 时，你需要事先确定参与协作的线程数量。比如 new CyclicBarrier(3)，意思就是每一轮必须有且仅有 3 个线程调用 await()。每个线程干完自己的活儿后，主动调用 await() 说“我到了”，然后自己挂起等待。直到最后一个线程也调用了 await()，计数器归零，屏障被触发，所有等待线程才会被同时唤醒，一起进入下一步。

这里有几个值得注意的细节：

• 如果调用了 await() 的线程数少于指定数量，那么剩余线程会一直阻塞——除非设置了超时或者有人中断。
• 同一个线程在同一轮里多次调用 await() 很危险，要么提前触发屏障，要么抛出 BrokenBarrierException。
• 实践中推荐搭配 FixedThreadPool 来管理线程，避免线程生命周期混乱导致计数对不上。

自动重置 + 多轮复用

CyclicBarrier 和 CountDownLatch 最大的不同就在这里——它支持自动重置。当所有线程通过屏障后，内部计数器会自动恢复成初始值，不需要你重新 new 一个对象，直接就能投入下一轮同步。这个特性让它在周期性协作场景中格外好用：

• 电商对账系统：每批订单过来，查库、比对、写差异，循环执行，同一个 barrier 搞定。
• 机器学习训练框架：每个 epoch 同步梯度，反复用同一个实例。
• 模拟压力测试：每轮初始化用户请求、并发施压、采集结果，周而复始。

屏障动作统一协调

CyclicBarrier 还允许你传入一个 Runnable 作为 barrierAction，由最后一个到达屏障的线程（在释放其他线程之前）串行执行这个动作。这个位置非常适合做集中式的协调操作：

• 合并各个线程的局部结果（比如求和、计数）。
• 校验整体状态，决定是否提前终止后续轮次。
• 刷新共享指标或写入中间快照。

需要注意的是，这个动作一定要轻量，毫秒级完成，否则会成为瓶颈。另外，它不能抛出未捕获的异常，否则屏障会直接破损。

超时与异常保障健壮性

现实中的线程可能因为各种原因卡住，所以 CyclicBarrier 提供了带超时的 await(long, TimeUnit) 方法：

• 超时触发后，抛出 TimeoutException，屏障进入 broken 状态。
• 如果某个线程被中断退出，其他等待线程会收到 BrokenBarrierException。
• 在 broken 状态下，所有后续 await() 调用会立即失败。你需要显式调用 reset() 来恢复，但要注意 reset() 会唤醒所有等待线程，并让他们抛出异常。
• 实际编码中，InterruptedException 和 BrokenBarrierException 必须捕获并合理处理，否则程序容易跑飞。