该用 CyclicBarrier 而不是 CountDownLatch 时：需多线程反复等待彼此到达同步点，支持重用且每轮可执行回调；CountDownLatch 仅适用于单向、一次性等待。
什么时候该用 CyclicBarrier 而不是 CountDownLatch
当多个线程必须「反复等待彼此到达某个同步点」时，CyclicBarrier 是更自然的选择。它支持重用，而 CountDownLatch 一旦计数归零就不可重置。
典型场景：多线程分段计算后需汇总结果，且整个流程要执行多轮（比如模拟多轮游戏回合、迭代式数值算法、压力测试中的周期性屏障）。
-
CountDownLatch更适合「一个线程等其他线程完成任务」的单向等待，例如启动服务时等待所有子组件初始化完毕 -
CyclicBarrier内部使用独占锁 + 条件队列，每次await()都可能触发屏障动作（Runnable），适合需要每轮都做协调操作的场景 - 如果只用一次，两者都能实现，但
CyclicBarrier多了重入和回调开销，没必要
CyclicBarrier 的 await() 会抛什么异常？怎么安全处理
await() 可能抛出 InterruptedException 和 BrokenBarrierException，后者表示屏障已被破坏（比如某线程超时退出或被中断，导致其他线程无法继续）。
-
BrokenBarrierException出现后，所有未完成的await()调用都会立即抛出该异常，屏障进入永久失效状态 - 若需恢复，必须新建
CyclicBarrier实例；它不提供 reset 方法（虽然有reset()，但它是将屏障设为“已破坏”，不是重置计数） - 建议在循环中捕获这两个异常，并根据业务决定是否重试或终止流程
try {
barrier.await();
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
break;
} catch (BrokenBarrierException e) {
// 其他线程已失败，当前线程也应退出或降级处理
log.warn("Barrier broken, aborting round");
break;
}
带超时的 await(long, TimeUnit) 有什么实际影响
超时机制不是“等不到就跳过”，而是「主动破坏屏障」——第一个超时或中断的线程会让整个屏障进入 broken 状态，后续所有 await() 都立刻抛 BrokenBarrierException。
立即学习“Java免费学习笔记（深入）”；
- 这意味着超时是“全有或全无”的：要么全部线程按时到达，要么全部感知到失败
- 不要把它当成“软等待”；如果希望部分线程超时后继续运行，
CyclicBarrier不适用，应考虑Phaser或手动协调 - 超时值设得太小容易误触发破坏，尤其在线程负载不均或 GC 暂停较长时
为什么 Phaser 正在替代 CyclicBarrier 的部分用途
Phaser 是 Java 7 引入的更灵活的同步器，它支持动态注册/注销参与者、分阶段等待、可查询当前阶段号，且没有「破坏后不可恢复」的硬限制。
-
CyclicBarrier固定人数、固定行为；Phaser允许每阶段不同线程参与，适合工作流类场景（如 MapReduce 中的 shuffle 阶段） -
Phaser的arriveAndAwaitAdvance()行为类似await()，但它失败后可通过forceTermination()+ 新建实例来恢复，比CyclicBarrier.reset()更可控 - 不过
PhaserAPI 更复杂，简单固定协作场景下，CyclicBarrier语义更清晰、不易误用
真正容易被忽略的是：CyclicBarrier 的屏障动作（构造时传入的 Runnable）是在最后一个到达线程的调用栈中执行的——如果这个 Runnable 执行慢或阻塞，会拖住所有线程释放，甚至引发死锁。这点在压测或日志打点时特别容易踩坑。
