cyclicbarrier的await()方法让线程在屏障点同步等待，直至所有线程到达才共同放行；其基于计数+条件等待机制，支持重复使用、异常中断响应及阶段间任务执行。
Java中CyclicBarrier的await()方法本质是让线程在指定屏障点同步等待，直到所有参与线程都调用await()，才一同放行进入下一阶段。它不依赖锁的持有顺序，而是基于计数+条件等待机制实现阶段性协同。
理解await()的阻塞与唤醒逻辑
await()会将当前线程挂起，直到满足两个条件之一：一是到达的线程数达到预设的parties值；二是被中断或超时（若使用带超时的重载）。内部通过一个共享的ReentrantLock保护计数器和等待队列，每次调用await()都会递减计数器，当归零时触发所有等待线程唤醒。
- 首次调用
await()的线程不一定最先执行后续逻辑——唤醒后各线程竞争CPU，执行顺序不确定 - 如果某线程在等待时被中断，会抛出
InterruptedException，且屏障会被打破（isBroken()返回true） - 计数器归零后自动重置，支持重复使用，这是“Cyclic”的核心体现
正确使用await()完成阶段同步
典型场景是多线程分阶段协作，比如多个线程并行计算一部分结果，然后统一汇总。关键在于确保每个线程都在同一逻辑位置调用await()，且调用次数与parties严格匹配。
- 构造
CyclicBarrier时可传入Runnable参数，该任务仅由最后一个到达的线程执行，适合做阶段间清理或广播操作 - 避免在
await()前后存在未同步的共享状态修改，否则可能引发竞态——屏障只保证到达时序，不保证内存可见性（需配合volatile或synchronized） - 若某线程因异常提前退出未调用
await()，其余线程将永久阻塞，应在外层捕获异常并调用reset()或确保流程兜底
处理await()的异常与中断响应
await()声明抛出InterruptedException和BrokenBarrierException，必须显式处理。前者表示线程被中断，后者说明屏障已被破坏（如其他线程中断、超时或重置）。
- 捕获
InterruptedException后通常应恢复中断状态：Thread.currentThread().interrupt(); - 遇到
BrokenBarrierException意味着本次协作失败，需判断是否重试、降级或终止任务 - 不要忽略异常直接吞掉——这会导致部分线程卡死，且难以定位问题
对比CountDownLatch避免误用
CyclicBarrier和CountDownLatch都用于线程同步，但语义不同：CountDownLatch是一次性倒计时门闩，适用于“一个线程等待多个线程完成”；而CyclicBarrier是循环屏障，适用于“多个线程互相等待彼此到达某点”。
- 若只需等待固定事件完成一次，选
CountDownLatch更轻量 - 若需多轮迭代协作（如模拟多轮游戏回合、分批次数据处理），
CyclicBarrier更自然 -
await()在CyclicBarrier中是“参与者行为”，而在CountDownLatch中await()是“等待者行为”，角色不可混用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
