CyclicBarrier不能仅靠一次await()完事，因其设计为循环复用：需固定数量线程均调用await()才集体放行并自动重置；单次调用仅完成一轮，多次使用须确保屏障未broken且线程数匹配。
为什么 CyclicBarrier 不能靠 await() 一次就完事
因为 CyclicBarrier 的设计本质是「循环复用」：它不阻塞单次，而是等待固定数量的线程全部调用 await() 后才集体放行，之后屏障自动重置。如果你只让每个线程调用一次 await()，那它确实能集合一次；但若想多次触发（比如每轮处理一批任务），就必须确保每次调用前屏障未被破坏，且线程数匹配初始化参数。
常见错误是在线程里捕获了 BrokenBarrierException 却没重置或重建屏障，导致后续调用直接抛异常；或者误以为 await() 返回值能判断“我是第几个到达”，其实它只返回到达序号（从 0 开始），且仅在最后一个线程调用时为 0。
- 初始化时传入的
parties数必须等于实际调用await()的线程数，少一个就永久阻塞 - 任意线程在
await()时被中断，会抛InterruptedException并使屏障进入 broken 状态 - 一旦 broken，所有后续
await()都立即抛BrokenBarrierException，必须手动reset()或新建实例
怎么让最后到达的线程执行聚合逻辑
CyclicBarrier 支持传入一个 Runnable 作为 barrier action，在最后一个线程到达、其他线程尚未被唤醒前执行。这个时机非常关键——它运行在最后一个线程的调用栈中，能安全访问共享状态，也适合做汇总、日志、触发下游等操作。
注意：这个 Runnable 不在单独线程里跑，也不具备原子性保障；如果它抛异常，屏障会 broken，所有等待线程收到 RuntimeException 或其子类（如 NullPointerException）。
CyclicBarrier barrier = new CyclicBarrier(3, () -> {
System.out.println("✅ 3 个线程已齐，开始合并结果");
// 这里可以读取 volatile 或线程安全容器里的数据
});
- 不要在 barrier action 里调用
await()，否则死锁 - 避免耗时操作，否则拖慢整个屏障释放速度
- 若需异步处理，建议只发通知（如
CompletableFuture.runAsync()），别等结果
如何安全应对线程提前退出或异常
真实场景中，某个工作线程可能因业务异常、超时或中断提前结束，根本没走到 await()。这时屏障永远等不满，其余线程卡死。没有银弹，但有可落地的缓解策略：
- 给
await()加超时：barrier.await(10, TimeUnit.SECONDS)，超时后抛TimeoutException，此时屏障自动 broken，你得立刻reset()或放弃本轮 - 在线程 run 方法最外层用 try-catch 包住全部逻辑，确保即使出错也尽量走到
await()（或至少标记失败并调用barrier.reset()） - 用
Thread.currentThread().isInterrupted()主动检查中断状态，避免在阻塞前就该退出 - 不要依赖
finally块里的await()—— 如果await()本身被中断，finally里再调一次会重复抛异常
CyclicBarrier 和 CountDownLatch 到底该选谁
两者都用于线程同步等待，但语义完全不同：CountDownLatch 是「一次性倒计时门闩」，适合一个线程等多个线程完成；CyclicBarrier 是「多线程互相等待集合点」，适合 N 个线程彼此协调、分阶段推进。
典型误用：用 CountDownLatch(1) 模拟 barrier——这只能实现单向等待，无法让所有线程在同一点汇合后一起往下走；而 CyclicBarrier 的每个线程都在等别人，也同时被别人等。
- 需要重复使用？→ 选
CyclicBarrier（CountDownLatch不能 reset） - 只有主线程关心「全部完成」，子线程做完就退出？→ 用
CountDownLatch更轻量 - 要等的不是「完成」而是「到达某状态」（比如都加载完配置才启动服务）？→
CyclicBarrier更贴切 - Java 8+ 且逻辑简单？考虑
Phaser，它支持动态注册/注销线程，比CyclicBarrier更灵活
真正容易被忽略的是：屏障点不是魔法节点，它不保证内存可见性。如果线程在 await() 前写共享变量，又在之后读，必须配合 volatile、Atomic* 或显式同步，否则可能看到过期值。
