cyclicbarrier 主要解决“并行执行→同步等待→聚合结果”闭环，专注在每轮结束时确保所有子线程完成后再统一触发汇总动作；它不负责任务分发或结果存储，而是通过 barrieraction 由最后一个线程执行轻量聚合，支持多轮复用，异常时进入 broken 状态需 reset 恢复。
CyclicBarrier 在任务拆分中主要解决“并行执行 → 同步等待 → 聚合结果”这一闭环流程。它不负责任务分发或结果存储，而是专注在每个计算周期结束时，确保所有子线程完成各自工作后，再统一触发汇总动作，并为下一轮准备就绪。
如何配合任务拆分实现分段计算
典型做法是将大任务（如数组求和、批量数据处理）按线程数均分，每个线程处理一个独立子集。关键点在于：
- 用共享容器（如原子数组、线程安全的List）保存各线程的局部结果，避免写冲突
- 每个线程完成子任务后立即调用 barrier.await()，进入等待状态
- 最后一个到达的线程会执行 barrierAction（如有），完成结果聚合、状态更新或日志记录
- 所有线程从 await() 返回后，可继续下一批处理或退出
屏障动作（barrierAction）的设计要点
这个 Runnable 由最后一个到达的线程独占执行，是聚合逻辑的核心位置：
- 必须轻量：耗时过长会导致其他线程长时间阻塞，影响整体吞吐
- 适合做“只读+单次写入”操作，例如合并 10 个局部 sum 到全局 total
- 不能依赖其他线程的中间状态（因它们尚未从 await() 返回，状态可能未完全稳定）
- 若需异常恢复，应在 barrierAction 内捕获处理，避免抛出导致屏障破损
应对异常与屏障破损的实用策略
CyclicBarrier 对中断、超时或线程死亡较敏感，一旦发生，屏障会进入 broken 状态：
- 所有等待线程会收到 BrokenBarrierException，已到达的线程也会被唤醒但抛异常
- 后续 await() 调用直接失败，除非显式调用 reset()
- 建议在主线程中监控 isBroken()，必要时重建 barrier 或终止任务
- 避免在 barrierAction 中抛异常；若必须，可用 try-catch 包裹并记录，再主动 reset()
与 CountDownLatch 的关键区别（选型参考）
两者都用于线程同步，但适用场景不同：
- CountDownLatch 是一次性计数器，适合“一个线程等多个线程完成”，不可重用
- CyclicBarrier 是循环计数器，适合“多个线程彼此等待，反复同步”，天然支持多轮协作
- 任务拆分若涉及多阶段迭代（如每轮训练 + 每轮评估），CyclicBarrier 更简洁；若仅需一次汇总，CountDownLatch 也够用
- barrierAction 提供了比 CountDownLatch 更自然的聚合入口点
