要用好CyclicBarrier，关键在于理解其“齐步走、可循环、带协调”的协作逻辑：需按组独立创建实例、严格匹配线程数、统一调用await()、捕获两类异常、善用barrierAction做轻量协调，并通过超时机制与reset()管理破损状态。
要用好 CyclicBarrier，关键不是记住 API，而是理解它“齐步走、可循环、带协调”的协作逻辑。它不是用来等任务结束的，而是让固定数量的线程在明确阶段点上彼此等待、全员到齐后一起迈步，并且这一步能反复走多次。
明确任务组规模，避免跨组干扰
每个任务组必须对应一个独立的 CyclicBarrier 实例。比如 8 个线程分 2 组（每组 4 人），就得创建两个 CyclicBarrier(4)；若共用一个 CyclicBarrier(8)，就可能出现 A 组 3 人 + B 组 5 人提前放行，破坏分组语义。
- 组内线程数即构造时的 parties 值，必须与实际参与线程严格一致
- 组间完全隔离：A 组调
barrierA.await()，B 组调barrierB.await()，互不影响 - 建议按业务维度命名或封装，例如用
Map<String, CyclicBarrier>管理不同场景的屏障
统一调用 await()，确保每轮只执行一次
await() 是同步点，也是阻塞点。所有组内线程必须在完成本阶段工作后、进入下一阶段前，无条件调用一次。少调或跳过会导致计数器卡住，其余线程永久等待。
- 把它放在逻辑“收尾处”，例如：数据加载完成 →
barrier.await()→ 开始校验 - 禁止写成
if (success) barrier.await()；失败线程也应调用，或主动触发barrier.reset()并通知其他方 - 务必包裹 try-catch，捕获 InterruptedException 和 BrokenBarrierException
用好 barrierAction 做轻量协调
构造时传入的 Runnable 会在所有线程就位后、释放前由最后一个到达的线程串行执行。这是做阶段汇总、状态切换或日志快照的理想时机。
- 适合操作：合并各线程结果（写入
ConcurrentHashMap后读取）、切换全局标志位、记录阶段耗时 - 必须轻量：控制在毫秒级，避免成为瓶颈；不可抛未捕获异常，否则屏障破损
- 不另起线程，也不阻塞唤醒流程——它执行完，所有线程才同时恢复
善用重用性，但要管好破损状态
CyclicBarrier 天然支持多轮使用，前提是每轮都干净通过。一旦有线程中断、超时或异常退出，屏障就会进入 broken 状态，后续 await() 全部立即失败。
- 正常流程下，一轮结束后自动重置，可直接用于下一轮
- 发生
BrokenBarrierException时，需检查isBroken()，再决定是否调用reset()恢复 -
reset()会唤醒所有等待线程并抛出异常，仅在线程全部脱离 await 状态时安全使用 - 生产环境建议搭配超时版
await(long, TimeUnit)，防止单点卡死拖垮整组
