CyclicBarrier 的核心价值在于分阶段协同推进，通过屏障动作实现轻量协调、多轮重用及健壮性保障，与 CountDownLatch 在协作模式和语义上严格分工。

CyclicBarrier 的核心价值不在“等齐”，而在“分阶段协同推进”——它让多线程像一支训练有素的队伍，每完成一阶段就整队、校准、再出发。

屏障动作：轻量协调，不可阻塞

屏障动作（barrier action）是 CyclicBarrier 区别于其他同步工具的关键设计。它不是附加功能，而是由最后一个到达的线程直接执行的一次性协调任务，在所有线程 await() 返回前、唤醒他人之前立即运行。

• 适合做汇总局部结果、更新共享标志位、广播下一阶段参数等无状态、低开销操作
• 绝对避免耗时操作（如远程调用、文件写入）或可能抛异常的逻辑（如空指针解引用、校验失败 throw new RuntimeException）
• 一旦 barrier action 抛出未捕获异常，整个屏障即被标记为 broken，后续所有 await() 都会立即抛 BrokenBarrierException
• 它不运行在新线程中，也不参与计数，只服务于本轮同步的“交接时刻”

多轮分阶段同步：重用性才是重点

CyclicBarrier 的 “Cyclic” 不是修饰词，而是设计原点。它天然适配需要反复同步的迭代型任务，比如 Jacobi 数值迭代、图像分块处理、模拟仿真步进等。

• 每轮执行：各线程独立计算 → 全部调用 await() 到达屏障 → barrier action 合并/校验/初始化 → 所有线程携带新上下文进入下一轮
• 无需手动 reset()，屏障在放行后自动重置，下次 await() 即可开始新计数
• 若需提前终止某轮（如检测到全局错误），可显式调用 reset()，使正在等待的线程收到 BrokenBarrierException 并退出

健壮性保障：超时与状态监控不可少

生产环境里，单个线程卡住会导致整组线程永久挂起。CyclicBarrier 提供了内置机制应对这类风险。

• 优先使用带超时的 await(long, TimeUnit)，例如 await(5, TimeUnit.SECONDS)，超时后该线程抛 TimeoutException，屏障自动 broken
• 调用 getNumberWaiting() 可实时查看当前有多少线程还在屏障处阻塞，便于定位卡顿线程
• 通过 isBroken() 检查屏障状态，结合日志快速判断是否因中断、超时或 barrier action 异常导致失效

和 CountDownLatch 的分工要清晰

两者都解决“等待”，但角色完全不同，混用容易引发语义混乱。

• CyclicBarrier 是“对等协作”：所有参与者既是等待者也是被等待者，强调集体行动一致性
• CountDownLatch 是“主从等待”：一个或多个线程等待其他 N 个线程完成，关注的是“完成信号”的传递
• CyclicBarrier 支持 barrier action 和自动重用；CountDownLatch 一次性、无回调、不可重置
• 不要用 CyclicBarrier 替代 CountDownLatch 做“主线程等子任务结束”，那是职责错位