该用 cyclicbarrier 而不是 countdownlatch 的情况是需多线程反复在某点等齐后同步执行；因 countdownlatch 不可重置，而 cyclicbarrier 支持循环复用，并提供到达后回调、超时控制及异常传播机制。
什么时候该用 CyclicBarrier 而不是 CountDownLatch
如果你需要多个线程反复在某个点“等齐了再一起往下走”，CyclicBarrier 是唯一合理选择；CountDownLatch 一旦计数归零就不可重置，没法循环复用。典型场景是：多线程分批处理数据、模拟并发压测、并行计算中每轮迭代需同步屏障。
常见误用是拿 CountDownLatch 去凑合做循环等待——结果要么得反复 new 新实例（浪费），要么卡死在第二次 await（因为 latch 已触发）。
-
CyclicBarrier构造时可传Runnable，在所有线程到达后、释放前自动执行一次（适合汇总、日志、状态检查） - 调用
await()的线程会被阻塞，直到全部线程都调用了await()，或超时/被中断 - 任意一个线程在
await()时抛出异常（如BrokenBarrierException或InterruptedException），其他等待线程也会收到BrokenBarrierException
CyclicBarrier 的 reset() 到底能不能安全用
能调，但极不推荐主动调用 reset()。它会强行打破当前等待状态，让所有已等待线程抛出 BrokenBarrierException，后续调用 await() 会进入新一轮计数——这容易引发竞态和逻辑混乱。
真正需要“重置”的场景，往往说明设计有问题：比如本该用多个独立的 CyclicBarrier 实例（按批次隔离），或应由线程自己控制是否参与下一轮（用循环 + 条件判断，而非靠 barrier 强制重置）。
立即学习“Java免费学习笔记（深入）”；
- 如果某线程中途退出（如任务失败），其他线程 await 会一直挂住，除非设超时或用
reset()——但更好的做法是在 barrier 前加状态检查，失败则主动中断整个批次 -
getNumberWaiting()可用于调试，但不要依赖它做业务逻辑判断（非原子操作，值可能瞬间过期）
如何避免 CyclicBarrier 导致的线程永久阻塞
最常见原因是没控制好参与线程数：比如启动了 5 个线程调用 await()，但 barrier 初始化为 4，那第 5 个线程会永远等不到“第 4 个”（实际是等齐 4 个才放行，第 5 个根本没资格参与）——或者反过来，初始化为 5 却只启动 4 个线程，剩下那个 await 永远卡住。
另一个隐蔽坑是：线程在 await() 前抛异常退出，导致实际到达数不足，屏障永不触发。
- 务必确保
new CyclicBarrier(n)的n和**实际调用await()的线程数严格一致**（包括异常路径） - 总是配合超时使用：
await(10, TimeUnit.SECONDS)，避免无限等待；超时后检查返回值或异常，做降级处理（如取消剩余任务） - 在
Runnable回调里别做耗时或可能阻塞的操作（如 IO、锁竞争），否则会拖慢所有线程释放时间
Java 8+ 中 CyclicBarrier 和 Phaser 怎么选
如果只是固定数量线程循环同步，CyclicBarrier 更轻量、语义清晰；一旦涉及动态增减参与者、分阶段协调、或需要更细粒度的等待控制（比如某些线程只参与前两轮），Phaser 才值得引入。
Phaser 功能更全，但复杂度高一档：要理解 arriveAndAwaitAdvance()、register()、层级 phaser 等概念，且调试难度明显上升。多数业务场景里，硬上 Phaser 属于过早优化。
-
CyclicBarrier内部无锁，性能足够好；Phaser在大量线程频繁注册/注销时才有优势 - 如果已有代码用着
CyclicBarrier运行稳定，别仅仅因为“它看起来更现代”就换成Phaser - 注意
Phaser的onAdvance()回调和CyclicBarrier的Runnable行为不完全等价：前者在每阶段结束时触发，后者只在每次屏障通过时触发一次
真正难的不是写对 await()，而是想清楚“哪些线程必须等齐”“等齐之后谁负责清理/合并/通知”“某个线程失败时整个批次该怎么退”。这些逻辑错位，比语法错误更难排查。
