cyclicbarrier 通过“集体就位、统一放行”机制实现多线程同步，要求固定数量线程全部调用 await() 后才共同继续，支持自动重置与多轮复用，并可指定 barrieraction 执行协调逻辑，具备超时和异常处理保障。
CyclicBarrier 通过“集体就位、统一放行”的机制保障多线程步调一致——不是谁先做完谁先走，而是所有线程必须全部到达屏障点，才一起继续执行下一步，且这个过程可重复多次。
固定参与者 + 集体等待
创建 CyclicBarrier 时指定参与线程数（parties），例如 new CyclicBarrier(3) 表示每轮必须有且仅有 3 个线程调用 await()。每个线程完成自身任务后主动调用 await()，即宣告“我已就位”；此时线程挂起，不推进后续逻辑。只有当第 3 个线程调用 await() 使计数归零，屏障才被触发，所有等待线程被同时唤醒，进入下一步。
- 少于指定数量调用 await() → 剩余线程永久阻塞（除非超时或中断）
- 同一轮中多次调用 await() → 可能提前触发或抛 BrokenBarrierException
- 推荐配合 FixedThreadPool 使用，避免线程生命周期混乱
自动重置 + 多轮复用
与 CountDownLatch 不同，CyclicBarrier 在所有线程通过后，内部计数器自动恢复为初始 parties 值，无需重建对象即可投入下一轮同步。这天然适配周期性协作场景：
- 电商对账：每批订单→查库→比对→写差异，循环执行
- 训练框架：每个 epoch 同步梯度，复用同一个 barrier 实例
- 模拟压测：每轮用户请求初始化→并发施压→结果采集，反复进行
屏障动作统一协调
构造时可传入 Runnable 作为 barrierAction，由最后一个到达的线程在释放其他线程前串行执行。这是集中做关键协调操作的安全位置：
- 合并各线程的局部结果（如 sum、count）
- 校验整体状态，决定是否终止后续轮次
- 刷新共享指标或写入中间快照
- 动作需轻量（毫秒级），避免成为瓶颈；不可抛未捕获异常，否则屏障破损
超时与异常保障健壮性
使用 await(long, TimeUnit) 可防止单个线程卡死拖垮全局：
- 超时触发 → 抛 TimeoutException，屏障进入 broken 状态
- 某线程中断退出 → 其他线程收到 BrokenBarrierException
- broken 状态下所有 await() 立即失败；需显式调用 reset() 恢复（注意会唤醒并异常化所有等待线程）
- 实际编码中必须捕获 InterruptedException 和 BrokenBarrierException 并合理处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
