Java多线程协作：CyclicBarrier详解教程

本篇文章给大家分享《Java多线程协作：CyclicBarrier使用详解》，覆盖了文章的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

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

终于介绍完啦！小伙伴们，这篇关于《Java多线程协作：CyclicBarrier详解教程》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！