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 做“主线程等子任务结束”，那是职责错位
