在Java中如何使用CyclicBarrier实现多线程屏障_Java线程协作解析

CyclicBarrier适用于固定数量线程必须全部到达后才一起继续执行的协作场景；它可重复使用，所有线程在屏障点同时唤醒，而CountDownLatch是一次性单向等待工具。

直接说结论：CyclicBarrier 适合「固定数量线程必须全部到达后才一起继续执行」的协作场景，不是用来替代 join 或 CountDownLatch 的万能工具。

什么时候该用 CyclicBarrier 而不是 CountDownLatch

CountDownLatch 是一次性倒计时，触发后不可重用；CyclicBarrier 支持重复使用，

常见误用：用 CyclicBarrier 等待一个后台任务完成（比如只启动 1 个线程去干活，其余 4 个空等）。这违背设计意图，应改用 CountDownLatch 或 CompletableFuture。

• ✔ 正确场景：多个线程各自计算一部分数据，全部算完再合并结果（如分片矩阵乘法、并行归并排序）
• ✔ 正确场景：模拟多玩家游戏中的“准备就绪”阶段，5 个玩家线程都调用 await() 后才开始下一回合
• ✘ 错误场景：主线程等子线程执行完某个异步操作——这不是「彼此等待」，而是「单向等待」

CyclicBarrier 构造与 await() 的典型用法

构造时指定参与线程总数，可选传入一个 Runnable 作为「屏障动作」——它由**最后一个到达的线程**执行，且在其他线程被释放前完成。

调用 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 的单次语义复杂得多。