cyclicbarrier 是为多线程提供“集体起跑线”的循环屏障机制，要求所有线程抵达后才同步进入下一阶段，支持阶段性同步、变量可见性控制、自动复用及异常恢复，适用于固定线程数的周期性协作场景。
CyclicBarrier 的任务栅栏机制，本质是为多线程提供一个“集体起跑线”——所有参与线程必须全部抵达同一同步点，才能一起迈入下一阶段。它不靠单方面等待，而是强调彼此约束与协同推进，从而保障执行节奏和数据状态的一致性。
阶段性同步：确保每轮操作步调统一
当任务被拆解为多个阶段（如采集→清洗→建模→上报），每个阶段内各线程独立工作，但必须等全部完成才可进入下一阶段。CyclicBarrier 在每阶段末尾设一个屏障点，调用 await() 表示“我已完成本阶段”，只有最后一个线程到达时，所有线程才被同时唤醒。
- 避免部分线程提前读取未写完的中间结果
- 天然支持固定线程数的流水线重复执行，无需每次重建对象
- 配合超时版 await(long, TimeUnit)，防止个别线程卡死拖垮整体进度
变量可见性与结果汇总：控制读写时机
屏障本身不自动保证变量可见性，但它提供了统一的“写完成”时刻。各线程应在 await() 调用前完成对共享变量（如 ConcurrentHashMap 或 volatile 字段）的更新；屏障打开后，所有线程看到的是已稳定的状态。
- 推荐将聚合、校验、广播等逻辑放在 barrierAction 中，由最后一个到达线程单点执行，规避并发竞争
- 若需跨阶段传递状态，可用 static 数组或 ThreadLocal 配合 barrierAction 做集中中转
- 注意遵循 JMM 规则：用 volatile、final、锁或原子类包装共享数据
自动复用与异常恢复：支撑长期协作
CyclicBarrier 的“循环”不是靠手动 reset 实现的，而是内在机制：最后一人触发屏障后，内部计数器自动恢复为初始 parties 值，下一轮 await() 可立即生效。
- 某轮因异常中断（如 BrokenBarrierException），可显式调用 reset() 恢复屏障，继续后续轮次
- 一旦屏障被破坏（broken=true），所有等待线程都会收到 BrokenBarrierException，便于整批中止或主动干预
- 适合固定参与者、周期性运行的场景，比如定时批处理、训练迭代、压测节点对齐
对比 CountDownLatch：选对工具很关键
两者都用于线程等待，但设计目标不同：
- CyclicBarrier 是“多对多”协作：线程互相等待，强调阶段同步与循环使用
- CountDownLatch 是“一对多”通知：主线程等待子任务完成，通常只用一次
- 计数方式相反：CyclicBarrier 是到达即减（加法语义），CountDownLatch 是触发即归零（减法语义）
