CyclicBarrier适用于固定数量线程必须全部到达后才一起继续执行的协作场景；它可重复使用，所有线程在屏障点同时唤醒，而CountDownLatch是一次性单向等待工具。
直接说结论：CyclicBarrier 适合「固定数量线程必须全部到达后才一起继续执行」的协作场景，不是用来替代 join 或 CountDownLatch 的万能工具。
什么时候该用 CyclicBarrier 而不是 CountDownLatch
CountDownLatch 是一次性倒计时，触发后不可重用；CyclicBarrier 支持重复使用，且所有等待线程会在屏障点「同时被唤醒并继续运行」——这是关键区别。
常见误用：用 CyclicBarrier 等待一个后台任务完成（比如只启动 1 个线程去干活，其余 4 个空等）。这违背设计意图，应改用 CountDownLatch 或 CompletableFuture。
- ✔ 正确场景：多个线程各自计算一部分数据，全部算完再合并结果（如分片矩阵乘法、并行归并排序）
- ✔ 正确场景：模拟多玩家游戏中的“准备就绪”阶段，5 个玩家线程都调用
await()后才开始下一回合 - ✘ 错误场景：主线程等子线程执行完某个异步操作——这不是「彼此等待」，而是「单向等待」
CyclicBarrier 构造与 await() 的典型用法
构造时指定参与线程总数，可选传入一个 Runnable 作为「屏障动作」——它由**最后一个到达的线程**执行，且在其他线程被释放前完成。
立即学习“Java免费学习笔记（深入）”；
调用 await() 可能抛出 InterruptedException 或 BrokenBarrierException，必须处理。后者表示屏障已被中断或重置，后续调用会立即失败。
int partySize = 3;
CyclicBarrier barrier = new CyclicBarrier(partySize, () -> {
System.out.println("所有线程已就位，执行汇总逻辑");
});
// 每个线程中
try {
doWork();
barrier.await(); // 阻塞直到全部到达
afterBarrierAction();
} catch (InterruptedException | BrokenBarrierException e) {
// 必须处理，不能忽略
Thread.currentThread().interrupt();
}
容易踩的坑：重入、中断与重置行为
CyclicBarrier 的「可循环」不等于「自动重置」——它在一次所有线程通过后自动进入下一轮等待，但一旦发生中断或某线程超时未到，屏障就进入 broken 状态，后续调用 await() 会直接抛 BrokenBarrierException。
- 调用
reset()会强制清空当前状态，但正在阻塞的线程会收到BrokenBarrierException，需确保调用方能安全处理 - 如果某个线程在
await()时被interrupt()，整个屏障立刻 broken，其他线程即使没超时也会抛异常 - 不要在屏障动作（
Runnable）里做耗时操作，否则会拖慢所有线程的释放时机 -
await(long, TimeUnit)超时后同样导致屏障 broken，除非你显式调用reset()
真正难处理的是 broken 状态的传播和恢复逻辑——很多业务代码只捕获异常却没重置屏障，导致后续轮次直接失败。这点比 CountDownLatch 的单次语义复杂得多。
