该用 CyclicBarrier 而不是 CountDownLatch 的场景是需要多线程分阶段协作且屏障可重用时，如多玩家回合同步、mini-batch 数据校验；因其可重置，而 CountDownLatch 仅适用于一次性初始化等待。
什么时候该用 CyclicBarrier 而不是 CountDownLatch
核心区别在于复用性：CyclicBarrier 可重置、可重复使用；CountDownLatch 一旦计数归零就不可逆。如果你的任务是「多线程分阶段协作」，比如每轮都需等所有线程到达某个检查点再一起继续（如并行计算的迭代步、模拟中的时间片同步），CyclicBarrier 更合适。
常见误用场景：用 CountDownLatch 做阶段性等待——结果只能用一次，第二轮就得新建实例，逻辑臃肿且易出竞态。
- 适合
CyclicBarrier：多玩家回合制游戏每轮同步、分布式测试中多个客户端统一启停、机器学习 mini-batch 训练前的数据校验同步 - 不适合：一次性初始化等待（如服务启动时加载配置），选
CountDownLatch更轻量
CyclicBarrier 构造与基本用法要点
最常用构造函数是 new CyclicBarrier(int parties)，parties 表示需要等待的线程总数。注意：这个数必须和实际调用 await() 的线程数严格一致，少一个则永远阻塞，多一个会抛 BrokenBarrierException。
关键行为：每个线程调用 await() 后被挂起，直到第 parties 个线程调用，所有线程才同时唤醒继续执行。
立即学习“Java免费学习笔记（深入）”；
-
await()是可中断的，若线程在等待时被interrupt()，抛InterruptedException，屏障自动进入破损状态 - 可选构造函数
new CyclicBarrier(int parties, Runnable barrierAction)，由最后一个到达的线程执行该回调，常用于汇总结果或日志记录 - 回调
barrierAction若抛异常，会导致所有等待线程收到BrokenBarrierException
如何安全处理 BrokenBarrierException 和屏障破损
BrokenBarrierException 不仅在屏障被中断时抛出，也出现在任一线程在 await() 中超时、异常退出、或 barrierAction 抛异常之后。此时屏障已损坏，后续所有 await() 都会立即抛该异常，除非手动重置。
典型错误：只捕获 InterruptedException，忽略 BrokenBarrierException，导致后续线程陷入不可预期失败。
- 必须显式捕获
BrokenBarrierException并决定是否重试或退出 - 调用
reset()可恢复屏障，但会唤醒所有等待线程并令其收到BrokenBarrierException—— 所以重置前应确保无线程仍在await() - 生产环境建议配合
try-catch-finally：在finally块里检查isBroken()，必要时记录告警
性能与线程安全注意事项
CyclicBarrier 内部基于 ReentrantLock 和 Condition 实现，本身线程安全，但不解决业务逻辑的竞态。例如多个线程在 barrierAction 中写共享变量，仍需额外同步。
小规模线程（≤ 数十）下性能良好；但若 parties 过大（如上千），每次 await 都需原子更新计数+条件唤醒，开销上升，且容易因个别线程延迟拖慢整体进度。
- 避免在
barrierAction中做耗时操作（如 I/O、远程调用），否则会阻塞所有线程的下一步执行 - 不要在
await()前持有其他锁，否则可能引发死锁（如线程 A 持锁等屏障，线程 B 在屏障回调中试图获取同一锁） - 调试时留意线程 dump 中的
java.util.concurrent.CyclicBarrier$Generation状态，破损屏障通常显示为broken=true
真正难的不是调用 await()，而是设计好「谁该等、等什么、等完做什么」——屏障只是同步点，背后的数据依赖和生命周期管理，得靠你提前想清楚。
