cyclicbarrier 的核心作用是让多个线程在多个阶段中“齐步走”，每个阶段结束时统一停顿、确认就绪再一起进入下一阶段；它支持分阶段同步、屏障动作执行、循环复用，并需配合 volatile 或 atomic 等机制保障变量可见性。
CyclicBarrier 的核心作用是让多个线程在多个阶段中“齐步走”，每个阶段结束时统一停顿、确认就绪，再一起进入下一阶段——整个过程可自动重复，无需重建对象。
分阶段同步：靠 await() 统一卡点
每个线程执行完本阶段任务后，调用 await() 进入等待。CyclicBarrier 内部计数器递减，只有当指定数量的线程全部到达，所有线程才同时被唤醒，继续执行下一段逻辑。
- 不依赖外部触发，所有参与者平等协作，谁最后到谁触发释放
- await() 返回值是线程在本轮中的到达序号（0 表示第一个，parties-1 表示最后一个），可用于区分角色
- 若某线程提前退出或抛异常，其他等待线程会收到 BrokenBarrierException，避免静默挂起
屏障动作：在阶段切换时集中处理
构造时传入的 Runnable barrierAction，会在所有线程到达后、释放前由最后一个到达的线程执行。这是做汇总、校验、状态检查或准备下一阶段资源的理想位置。
- 例如：三线程各自算出局部结果，barrierAction 中把三个结果合并并存入共享 map
- 该动作执行期间，其他线程仍在 await() 中阻塞，保证操作独占且时机可控
- 若 barrierAction 抛异常，所有线程都会收到 BrokenBarrierException，便于整体失败回滚
循环复用：一次初始化，多轮生效
CyclicBarrier 的“循环”不是靠手动 reset() 实现的，而是内在机制——屏障被触发后，计数器自动恢复为初始值，下一轮 await() 可立即使用。
- 适合固定线程数、重复执行的流水线，比如每轮跑采集→清洗→分析→上报四步
- 即使某轮因超时或中断失败，也可调用 reset() 主动恢复，后续轮次不受影响
- 与 CountDownLatch 不同：后者计数归零即失效，必须新建实例；CyclicBarrier 天然支持“一轮接一轮”
变量同步与线程安全提醒
屏障本身只控制执行时机，不保证变量可见性。阶段间传递数据时需额外保障：
- 共享变量建议用 volatile 或 Atomic 类修饰，或放在 final 容器中（如 ConcurrentHashMap）
- 若在 barrierAction 中读取各线程的局部变量，确保这些变量已在 await() 前完成写入
- 避免在 await() 后直接读取未同步的普通字段，否则可能看到旧值或部分更新状态
