cyclicbarrier的核心作用是让固定数量的线程在多阶段任务中同步等待、齐步推进；它支持自动复用、阶段性变量同步、循环协作，适用于并行批处理、分布式模拟、资源检查及多线程训练等场景。
CyclicBarrier 的核心作用，是让固定数量的线程在多个阶段中“齐步走”——每轮都必须全部到达同一个屏障点，才能一起进入下一阶段。它不是一次性开关，而是可自动复用的协作契约，特别适合需要阶段性同步、状态传递、反复执行的任务。
阶段性变量同步：统一读写时机
多个线程各自更新局部变量（比如计算结果、处理条数、状态标记）后，不能随意读取或合并，否则容易读到旧值、空值或中间态。CyclicBarrier 通过 强制所有线程调用 await()，确保写操作全部完成，再统一推进到读取或汇总逻辑。
- 每个线程在阶段末尾更新自己的变量（如
localSum、successCount） - 全部调用
barrier.await()后，才进入下一阶段；此时所有变量已稳定 - 若设置了
barrierAction，可由最后一个到达的线程集中读取全部变量，做校验、聚合或写入共享缓存
循环使用：天然支持多轮协作
CyclicBarrier 的“循环”不是靠手动 reset 实现的，而是内在机制：当最后一线程触发屏障打开，内部计数器自动恢复为初始 parties 值，下一轮 await() 可立即生效。
- 无需重建对象，线程、屏障、共享容器均可复用
- 适合固定参与者、重复执行的流水线，例如四阶段任务（采集→清洗→建模→上报），跑完一轮直接开始下一轮
- 若某轮因异常中断（如抛出
BrokenBarrierException），可显式调用reset()恢复，继续后续轮次
典型适用场景
以下情况优先考虑 CyclicBarrier 而非其他同步工具：
- 并行批处理流水线：N 个 worker 分批次处理数据块，每批必须全部完成清洗，才统一触发特征提取
- 分布式模拟/测试协同：多个线程模拟不同服务节点，在“启动完成”“配置加载完毕”“压测开始”等关键节点强同步
- 阶段性资源检查：各线程初始化本地连接池、加载配置后，在屏障点汇总健康状态，任一失败则整批中止
- 多线程训练中的 epoch 同步：每个 worker 完成本 epoch 计算后等待，由
barrierAction触发梯度平均与模型更新
注意变量可见性与线程安全
屏障本身不解决变量可见性问题。如果阶段间通过普通字段传递状态，需额外保障：
- 用
volatile修饰简单状态标志 - 共享对象字段需加锁或使用线程安全容器（如
ConcurrentHashMap） - 避免在
barrierAction中修改被多个线程并发读写的非线程安全对象
