该用 CyclicBarrier 而不是 CountDownLatch 的情况是：需多次复用同一组线程协同点、各线程逻辑不同但须同步至检查点、或需在全部到达时自动执行汇总逻辑。
什么时候该用 CyclicBarrier 而不是 CountDownLatch
CyclicBarrier 的核心价值是「重复使用」和「所有线程互相等待到达某一点」。如果你的场景需要多线程协作完成一个阶段后，再一起进入下一阶段（比如分批处理、迭代计算、模拟步进式并发测试），它比 CountDownLatch 更合适——后者只能触发一次，且通常由主线程等待子线程，不强调“彼此等彼此”。
典型误用：用 CountDownLatch 实现多线程齐步走，结果得反复 new 新实例、手动重置计数，反而破坏了语义清晰性。
- 需要多次复用同一组线程协同点 → 选
CyclicBarrier - 各线程执行逻辑不同但必须同步到某个检查点（如：加载数据 → 校验 → 合并）→
CyclicBarrier的Runnable回调很自然 - 希望某个线程在全部到达时自动执行一次汇总/清理逻辑 → 利用构造函数里的
Runnable参数
CyclicBarrier 的 await() 为什么可能抛 BrokenBarrierException
这不是异常处理疏漏，而是设计上的显式失败信号：只要任一参与者在 await() 期间被中断、超时、或所在线程因异常退出，整个屏障就被认为“已损坏”，后续所有 await() 都会立即抛 BrokenBarrierException。
这意味着你不能简单 catch 住就完事——必须判断是否真要继续执行。常见错误是忽略这个异常，导致后续线程卡死或逻辑错乱。
立即学习“Java免费学习笔记（深入）”；
- 调用
await()前确保线程未被中断（检查Thread.interrupted()） - 若业务允许部分失败，需在
catch (BrokenBarrierException e)后主动调用reset()（注意：这会唤醒所有阻塞线程并清空状态） -
reset()不是线程安全的“重置开关”，它会强制打破当前所有等待，并让下一次await()重新开始计数——慎用于高并发写场景
如何避免 CyclicBarrier 引发的线程饥饿或假死
最隐蔽的问题不是代码写错，而是线程生命周期与屏障生命周期不匹配。例如：某个工作线程提前退出（没调用 await()），其他线程就会永远阻塞在 await()；又或者屏障等待超时后，部分线程继续执行，另一些却还在等，造成状态不一致。
关键不是加 try-catch，而是控制参与者的确定性。
- 确保每个参与线程都**一定会**调用且**只调用一次**
await()（放在 finally 块里不保险，因为await()本身可能抛异常） - 设置合理超时：
await(long timeout, TimeUnit unit)比无参版更可控；超时后应明确后续动作（如放弃本轮、重试、通知监控） - 避免在
Runnable回调里做耗时操作（如 I/O、锁竞争），否则会拖慢所有线程进入下一阶段
public class BarrierExample {
private final CyclicBarrier barrier = new CyclicBarrier(3, () -> {
// 这里只做轻量汇总，不要 sleep() 或 synchronized(this)
System.out.println("All 3 threads reached barrier");
});
<pre class='brush:java;toolbar:false;'>public void doWork() throws InterruptedException {
try {
barrier.await(10, TimeUnit.SECONDS); // 显式超时
} catch (TimeoutException e) {
System.err.println("Barrier timeout, aborting this round");
barrier.reset(); // 主动恢复，但注意 reset() 的副作用
}
}}
和 Phaser 对比：什么情况下该升级？
当你的协作规模动态变化（比如线程可注册/注销）、需要分阶段嵌套等待、或想避免 BrokenBarrierException 的全局污染时，Phaser 是更现代的选择。但它代价更高：内部状态更复杂，调试难度上升。
CyclicBarrier 适合固定人数、阶段清晰、失败可接受重启的场景；一旦出现“可能增减参与者”或“多个屏障嵌套”，就该考虑 Phaser。
- 人数固定（如 4 个消费者处理一批消息）→
CyclicBarrier足够 - 需要支持运行时注册新线程（如弹性 worker pool）→ 直接用
Phaser - 一个大流程包含多个同步点（A 点等 3 人，B 点等 5 人）→
Phaser可用arriveAndAwaitAdvance()分阶段控制
别为了“新”而换，CyclicBarrier 的简洁性本身就是优势——只要人数不变、失败能兜住、没有嵌套需求，它就是最直接的解法。
