CyclicBarrier不能替代CountDownLatch因其语义不同：前者是“全部到达后一起继续”且可重用，后者是“倒计数为零后释放等待线程”且不可重用；误用会导致串行、卡死或BrokenBarrierException。
为什么 CyclicBarrier 不能直接替代 CountDownLatch
因为语义完全不同：CyclicBarrier 是“等所有线程都到达某个点再一起往下走”，而 CountDownLatch 是“等倒数到零后，其他线程才能继续”。如果你在分阶段任务里误用 CountDownLatch，会发现阶段之间串行、无法复用、甚至卡死——它天生不支持“多轮同步”。
典型错误现象：BrokenBarrierException 频繁抛出，或某一轮之后所有线程永远阻塞在 await()。这往往是因为某个线程在上一轮异常退出，没重置屏障，或者你误把它当一次性开关用了。
-
CyclicBarrier构造时指定的是“参与线程数”，不是“要等几次” - 每次所有线程调用
await()后，屏障自动重置，下一轮可立即复用 - 如果某线程被中断或超时，整个屏障会被打破，后续
await()全部抛BrokenBarrierException
怎么用 CyclicBarrier 实现三阶段同步执行
比如：10 个线程先并发执行预处理（阶段一），全部完成才一起进计算（阶段二），算完再统一写结果（阶段三）。关键不是“等完就结束”，而是“每阶段末尾集体卡一下”。
实操建议：
- 初始化时传入线程总数：
new CyclicBarrier(10)，别写成10 - 1或动态算 - 每个线程在阶段交接处调用
barrier.await()，不要漏掉任何一阶段的等待点 - 避免在
await()前做耗时操作（如 IO、锁竞争），否则会拖慢整组线程进入屏障的时间 - 可选传入
Runnable作为“屏障动作”，比如记录阶段开始时间：new CyclicBarrier(10, () -> log.info("Stage 2 start"))
示例片段（简化）：
for (int i = 0; i < 10; i++) {
new Thread(() -> {
stage1(); // 预处理
barrier.await(); // 等全部完成
stage2(); // 计算
barrier.await(); // 再等全部完成
stage3(); // 写结果
}).start();
}
CyclicBarrier.await() 的超时和异常怎么处理
不加超时的 await() 一旦有线程挂掉或卡住，其余线程就永久阻塞。生产环境必须设超时，且必须处理两种异常：TimeoutException 和 BrokenBarrierException。
常见错误现象：只 catch InterruptedException，结果 TimeoutException 没捕获导致线程直接退出，屏障被破坏，其他线程全抛 BrokenBarrierException。
- 用带超时的
await(long timeout, TimeUnit unit)，例如barrier.await(5, TimeUnit.SECONDS) - 必须显式检查返回值或异常：超时后当前线程应主动清理资源并退出，避免污染后续阶段
-
BrokenBarrierException表明屏障已失效，此时不要再调用await()，也不该尝试reset()——除非你确定所有线程都已脱离屏障逻辑
多个 CyclicBarrier 嵌套或混用时容易踩什么坑
没有“嵌套屏障”的概念。如果你在一个线程里先后 await 两个不同 CyclicBarrier 实例，它们完全独立；但若多个线程交叉 await 不同屏障，极易因线程调度顺序引发死锁或阶段错乱。
典型场景：主线程等子线程注册完再启动，子线程又等主线程发号施令——这时用一个 CyclicBarrier 就够了，别拆成两个。
- 一个任务流只用一个
CyclicBarrier实例，按阶段调用多次await() - 不要在
await()的回调Runnable里再触发另一个屏障的await() - 注意线程池复用场景：如果线程池里的线程反复执行含
CyclicBarrier的任务，确保每次任务都完整走完所有await()，否则残留状态会影响下一次执行
最常被忽略的一点：屏障对象本身不是线程安全的“状态容器”，它的状态（是否 broken、当前计数）由内部锁保护，但如果你在回调里修改共享变量，仍需额外同步。
