如果你已经在项目里用过线程池、Future、CountDownLatch这些并发工具那么对CyclicBarrier应该不陌生它是java.util.concurrent包里的另一个同步辅助类解决的问题非常直接让一组线程互相等齐等最后一个到了之后再一起往下执行。我自己是在做多线程数据分片处理的时候第一次觉得这个类确实好用后来又在一次并发压测里反复用它模拟“同一时刻发起请求”的场景发现很多细节不翻源码是真的容易踩坑。这篇文章我会从使用场景、源码机制、工具对比、实战案例到常见坑完整梳理一遍CyclicBarrier希望能帮你把它真正吃透而不是仅仅停留在“背八股文”的层面。1. CyclicBarrier到底在解决什么问题一个“人齐了才能开饭”的同步机制1.1 没有屏障的并发协作会怎样先设想一个很常见的业务需求你有 3 个线程分别从不同数据源拉取数据等 3 个线程都拉完了由主线程做合并。很多人的第一反应是Thread.join()或者Future.get()确实能实现但写起来不够优雅尤其是当“等齐”这个动作本身也是线程间协作的一部分时代码会越写越别扭。再设想一个更有意思的需求你要做并发压测希望 10 个线程在同一个瞬间同时发请求而不是先后乱序地发出去。CountDownLatch能解决“等大家都准备好了再开始”但想复用这 10 个线程发起第二轮、第三轮压测CountDownLatch的计数器是一次性的用完就废了你得重新 new 一个。这时候CyclicBarrier的价值就出来了它的“循环屏障”语义正好覆盖这两类场景一是互相等待到齐二是到齐之后自动开门放行并且可以反复使用。1.2 基础用法构造器、await与一次完整的“到齐”流程CyclicBarrier的用法极其简单核心 API 只有两个构造函数和一个await()方法// 第一个构造器指定参与线程个数 CyclicBarrier barrier new CyclicBarrier(3); // 第二个构造器多传一个 barrierAction等所有线程到齐后会由“最后到达的那个线程”执行这个动作 CyclicBarrier barrierWithAction new CyclicBarrier(3, () - { System.out.println(所有人都到了开始开会); });每个线程在自己的代码里调用一次await()表示“我到屏障点了在这里等着”。当所有参与者都调用了await()后所有线程同时被释放继续往后执行。下面是最基础的一个例子模拟 3 个人约好一起出发public class BasicCyclicBarrierDemo { public static void main(String[] args) { int parties 3; CyclicBarrier barrier new CyclicBarrier(parties, () - System.out.println(Thread.currentThread().getName() 执行最后到达后的额外动作)); for (int i 0; i parties; i) { new Thread(() - { try { System.out.println(Thread.currentThread().getName() 开始执行自己的任务); Thread.sleep(500 (long) (Math.random() * 500)); System.out.println(Thread.currentThread().getName() 到达屏障点); barrier.await(); System.out.println(Thread.currentThread().getName() 越过屏障继续往下走); } catch (Exception e) { e.printStackTrace(); } }, thread- i).start(); } } }运行后你会看到三个线程各自执行完任务后在await()处等着直到最后一个线程到达屏障打开三个线程同时往下走。这个“同时”并不是严格意义的时间点一致而是指它们在同一个屏障放行后继续调度执行。1.3 “循环”体现在哪里CyclicBarrier最容易被忽略的是“Cyclic”这个词。它和一次性计数器最大的区别在于屏障打开后计数器会被自动重置所有线程可以再次调用await()实现多轮协作。举个例子游戏组队打副本的场景。队伍 5 个人第一关需要 5 个人到齐后开始打完第一关继续跑图跑到第二关门口依然需要 5 个人到齐才能进。这个场景如果用 CountDownLatch每一关都要 new 一个对象而用CyclicBarrier同一个 barrier 实例就能贯穿全程。CyclicBarrier barrier new CyclicBarrier(5); // 每个玩家线程内部 for (int level 1; level 3; level) { barrier.await(); // 等5个人到齐 System.out.println(Thread.currentThread().getName() 进入第 level 关); }每轮await()结束后内部计数器自动恢复为 5所以可以继续下一轮等待。这是CyclicBarrier和CountDownLatch最大的分水岭。2. 源码层面的核心机制count、Generation与三把“锁”的配合2.1 dowait方法到底做了什么想要真正搞懂CyclicBarrier光会调 API 是不够的面试和实际排错迟早会把你逼到源码面前。它的内部实现不复杂核心就集中在dowait(boolean timed, long nanos)这一个方法里。先看它的几个关键成员变量public class CyclicBarrier { private final ReentrantLock lock new ReentrantLock(); private final Condition trip lock.newCondition(); private final int parties; private final Runnable barrierCommand; private Generation generation new Generation(); private int count; }这里有个很容易被忽略的点CyclicBarrier不是基于AQS的同步器它内部组合了一个ReentrantLock和一个Condition。整个dowait的过程可以概括为四步获取 lock 锁。检查当前 generation 的 broken 状态如果屏障已经损坏直接抛BrokenBarrierException。int index --count计数器减一。如果 index 不为 0说明不是最后一个线程就进入trip.await()挂起等待。如果 index 为 0说明当前线程是最后一个到达的线程这时执行barrierCommand如果构造时传了的话然后调用nextGeneration()唤醒所有等待线程并重置计数器。我用一个简化的流程图来描述整个状态流转这样比纯看源码更直观线程调用 await() | v 获取 ReentrantLock | v 检查 generation.broken true --- 抛 BrokenBarrierException | v count count - 1 | v 当前线程是最后一个 / \ 是 否 / \ 执行 barrierAction trip.await() 挂起 | v nextGeneration(): - trip.signalAll() - 重置 count parties - 创建新的 GenerationnextGeneration()就是实现“循环”的关键它会唤醒所有等待线程、把 count 重置回 parties同时创建一个全新的Generation对象代表开启新一轮协作。所以同一批线程在上一个屏障点等待被唤醒后看到的是一个崭新的 generation。2.2 屏障损坏BrokenBarrierException产生的根源CyclicBarrier里有一种状态机制是很多人刚开始接触时搞不懂的Generation中断裂标志broken true。一个屏障一旦进入 broken 状态所有后续await()调用都会立刻抛出BrokenBarrierException不管你是不是第一批参与者。什么情况下屏障会被打破源码里能触发breakBarrier()的有两种情况第一种是等待线程被中断。线程调用await()后挂起在trip.await()上如果这个线程被interrupt()打断它会从等待中醒来并抛出InterruptedException。CyclicBarrier捕获到这个异常后会调用breakBarrier()然后重新抛出InterruptedException给当前线程同时其他所有等待的线程都会收到BrokenBarrierException。第二种是等待超时。如果你用的是await(long timeout, TimeUnit unit)在时间超过阈值还没等待到齐时当前线程抛出TimeoutException同时屏障被打破其他线程同样会受到波及。为什么中断或超时要影响所有人这其实是设计上的取舍CyclicBarrier 预设的语义是“要么一起通过要么大家一起失败”。如果在某个业务场景里一个线程在中途出错其他线程还在屏障点无限等待那就可能出现永久阻塞。打破屏障的意义在于及时通知所有协作者“本次协作已经失败不用再等了”。2.3 一个常见误解barrierAction 是“最后到达的那个线程”执行的很多人以为barrierAction是在某个独立线程里执行的或者是由主线程执行的这都不对。从源码可以看到barrierCommand.run()是在最后一个调用await()的线程内部、在释放 lock 之前执行的。这一点在实际使用中非常重要。因为如果barrierAction里抛出了异常这个异常会直接传播到“最后一个到达线程”的调用链上其他线程并不会感知到这个异常它们只会被正常唤醒。同时由于异常发生在持有 lock 期间CyclicBarrier的 try/finally 机制会确保 lock 一定被释放但 generation 已经完成了更替所以这一轮的协作实际上已经成功结束。如果你希望barrierAction里的逻辑失败时让整个协作失败那需要自己在动作内部做异常包装比如把异常信息存到一个共享的容器里让其他线程醒来后检查。3. 千万不要和CountDownLatch混用一张表看懂JUC同步工具的分工3.1 CyclicBarrier 与 CountDownLatch 的核心差异CyclicBarrier和CountDownLatch是面试中最常被拿来对比的两个类。很多人能背出几句口诀“CyclicBarrier 可循环CountDownLatch 是一次性的”但真正到项目里面对具体需求还是容易选错。对照表可以帮助你在几秒钟内完成选型对比维度CyclicBarrierCountDownLatch核心语义一组线程互相等待全部到达后同时放行一个或多个线程等待计数归零参与方式每个参与线程都调用await()参与等待一边线程调用countDown()另一边线程调用await()等待是否能复用能屏障打开后自动重置不能计数器归零后失效计数方式count递减的是参与者个数最后一个到达的线程负责开门count递减的是事件次数谁调用countDown()都可以异常影响面一个线程中断/超时会打破屏障波及所有人一个线程出问题不会影响计数其他线程仍可继续countDown()典型场景多线程分阶段协同、并发起跑线、重复使用的多轮等待主线程等待多个子任务完成、服务启动时等待多个组件加载完毕3.2 网上流传很广的一句口诀为什么容易误导人经常看到有人总结“CountDownLatch 是等待别人完成CyclicBarrier 是大家互相等”这话大体没错但不够精确。更准确的说法是CountDownLatch 更强调“一个或者多个线程等待另外一些线程完成某些事情”CyclicBarrier 更强调“所有参与线程要在同一个屏障点碰头缺一不可”。举个例子线程 A 和 B 各处理一批数据线程 C 等着 A 和 B 都处理完然后做汇总。这个场景用 CountDownLatch 是更自然的选择因为 C 本身不参与任务处理它只负责等待。如果硬用 CyclicBarrier你得让 C 也调用await()但 C 自己并没有需要和其他线程对齐的任务这就把问题复杂化了。反过来如果是一个并行计算场景5 个线程分别计算一个矩阵的 5 个分块每个线程算完后在屏障点等着等 5 个分块都算完然后每个线程读取相邻分块的共享结果变量继续下一步协同计算。这个场景用 CyclicBarrier 就非常合适因为 5 个线程确实在互相等待彼此。3.3 从“复用性”看 Phaser 这个升级版如果你已经掌握了CyclicBarrier碰到更复杂的多方协作场景时可能还会遇到Phaser这个类。Phaser可以看作是CyclicBarrier的增强版它允许你动态增加或减少参与者数量而不需要重新创建对象。举个例子使用 CyclicBarrier 时参与者数量在构造时就固定了比如 5。但使用 Phaser 时线程可以通过register()和arriveAndDeregister()动态加入或退出每个阶段(phase)都可以拥有不同的参与者集合。如果你的需求是多阶段任务且每阶段参与人数有变化Phaser 比 CyclicBarrier 更合适。不过 Phaser 的使用门槛也更高需要透彻理解 phase、parties、registered 这些概念平时用不到的话不必强行上。CyclicBarrie 覆盖了 80% 的“等齐再走”场景代码也更简单直接。4. 三个可以直接抄的实战场景数据聚合、并发压测与多阶段流水线4.1 场景一多线程分片数据聚合实际业务里分片加载数据再合并是非常典型的场景。假设你要从数据库里查 3 个分区的订单数据每个分区各起一个线程查询等 3 个线程全部查完后再把结果合并写到一个汇总 Map 里。public class DataAggregationDemo { private static final int PARTITIONS 3; private static final MapString, ListString SHARED_RESULTS new ConcurrentHashMap(); public static void main(String[] args) throws Exception { CyclicBarrier barrier new CyclicBarrier(PARTITIONS, () - { System.out.println(所有分区数据准备完成开始合并); // 这里执行的是最后到达线程的逻辑 mergeAndSave(); }); ExecutorService executor Executors.newFixedThreadPool(PARTITIONS); for (int i 0; i PARTITIONS; i) { final int partition i; executor.submit(() - { try { ListString data queryPartitionData(partition); SHARED_RESULTS.put(partition- partition, data); barrier.await(); } catch (Exception e) { Thread.currentThread().interrupt(); } }); } executor.shutdown(); } private static ListString queryPartitionData(int partition) { // 模拟耗时查询 try { Thread.sleep(300 partition * 200L); } catch (InterruptedException ignored) { } return List.of(data- partition -1, data- partition -2); } private static void mergeAndSave() { System.out.println(合并结果大小: SHARED_RESULTS.size()); } }需要注意的一个细节是barrierAction里读取的SHARED_RESULTS写入方是三个线程各自调用put完成的。ConcurrentHashMap 虽然保证了可见性但这里的可见性更大程度上依赖于CyclicBarrier内部锁的 happens-before 关系线程 T1 在调用await()之前的写操作对于屏障唤醒后的其他线程是可见的。4.2 场景二并发性能测试中模拟“同一时刻发起请求”做性能压测的时候最难的是如何让 N 个线程真正同时发起请求。有人直接 start 线程期望它们能齐头并进但线程启动本身有开销先启动的线程可能已经发出请求了后启动的线程才刚被创建。用 CyclicBarrier 可以把所有线程对齐到同一个起跑线。public class ConcurrentPressureTestDemo { public static void main(String[] args) throws InterruptedException { int workerCount 10; CyclicBarrier startBarrier new CyclicBarrier(workerCount); CountDownLatch doneLatch new CountDownLatch(workerCount); for (int i 0; i workerCount; i) { new Thread(() - { try { startBarrier.await(); // 所有线程准备就绪后统一开跑 long startTime System.currentTimeMillis(); // 模拟调用远程接口 HttpClient.doRequest(); System.out.printf(线程 %s 耗时 %d ms%n, Thread.currentThread().getName(), System.currentTimeMillis() - startTime); } catch (Exception e) { Thread.currentThread().interrupt(); } finally { doneLatch.countDown(); } }, worker- i).start(); } doneLatch.await(); // 主线程等待所有压测任务结束 } }这里我刻意把 CyclicBarrier 和 CountDownLatch 放在了一起用各司其职CyclicBarrier 管“同时启动”CountDownLatch 管“等待全部结束”。这种组合在实际压测脚本中非常常见比单纯用一个工具硬扛更合理。4.3 场景三多阶段协同流水线CyclicBarrier 的可循环特性在做多阶段流水线时非常好用。比如一个数据处理任务需要经过“校验 - 清洗 - 转换”三个阶段每个线程负责一批数据每完成一个阶段要等所有线程都到达当前阶段的屏障点后才能进入下一阶段。public class PipelineDemo { private static final int WORKERS 3; private static final CyclicBarrier BARRIER new CyclicBarrier(WORKERS); public static void main(String[] args) { for (int i 0; i WORKERS; i) { final int workerId i; new Thread(() - { try { // 阶段1校验 System.out.printf(工作线程 %d 开始校验数据%n, workerId); Thread.sleep(200 workerId * 100L); BARRIER.await(); // 阶段2清洗 System.out.printf(工作线程 %d 开始清洗数据%n, workerId); Thread.sleep(150 workerId * 50L); BARRIER.await(); // 阶段3转换 System.out.printf(工作线程 %d 开始转换数据%n, workerId); Thread.sleep(100 workerId * 30L); BARRIER.await(); System.out.printf(工作线程 %d 处理完成%n, workerId); } catch (Exception e) { Thread.currentThread().interrupt(); } }, pipeline- i).start(); } } }整个流程里同一个 barrier 实例被 await 了 3 次每一轮都完整地执行了一次“等齐-放行-重置”的过程。如果某个线程在某一阶段抛了异常它后续的await()会抛出BrokenBarrierException其他线程也会在当前的屏障点发现屏障已经损坏从而快速失败而不是无限等下去。5. 实战中最容易踩的坑线程池饥饿、broken状态与超时处理的正确姿势5.1 线程池饥饿parties比核心线程数大卡死的典型case这是我在实际项目中踩过的最经典的一个坑。假设你定了一个 3 个参与者的 CyclicBarrier但线程池的核心线程数只有 2ExecutorService executor Executors.newFixedThreadPool(2); CyclicBarrier barrier new CyclicBarrier(3); for (int i 0; i 3; i) { executor.submit(() - { try { barrier.await(); // 前两个任务会在这里永久等下去 } catch (Exception e) { Thread.currentThread().interrupt(); } }); }线程池只有 2 个线程它们都执行了任务并卡在barrier.await()上第三个任务排队等着空闲线程但前两个线程永远不释放线程于是整个池子就被僵住了。这不是 CyclicBarrier 的 bug而是使用方没搞清楚“参与者数量和线程池容量必须匹配”这个前提。排查这种问题有个很直观的特征程序既不报错也不退出所有线程卡在同一个堆栈位置CyclicBarrier.dowait。用 jstack 一看就能发现多个线程都在等待一个 Condition而线程池里的 worker 数已经耗尽。所以我的经验法则是使用 CyclicBarrier 时线程池的核心线程数必须大于等于 participants 数量否则就要改用 CountDownLatch 或者调整设计。5.2 await超时之后整个屏障就废了CyclicBarrier提供了带超时参数的await(long timeout, TimeUnit unit)看起来像是给了你一条退路但很多新手不知道一旦某个线程在 await 时超时这个屏障就会进入 broken 状态所有后续调用都会直接抛 BrokenBarrierException。下面的代码演示了这种情况CyclicBarrier barrier new CyclicBarrier(2); Thread t1 new Thread(() - { try { barrier.await(1, TimeUnit.SECONDS); } catch (TimeoutException e) { System.out.println(线程1超时了); } catch (Exception e) { e.printStackTrace(); } }); Thread t2 new Thread(() - { try { barrier.await(); System.out.println(线程2通过了屏障); } catch (Exception e) { System.out.println(线程2收到异常: e); } });当线程1超时后屏障被打破线程2会收到BrokenBarrierException而不是被正常放行。这在业务上往往是合理的因为当一个参与者在规定时间内没能赶到整个协作计划就不该继续下去。关键在于你需要对 broken 状态有预期。捕获到BrokenBarrierException时不要只打一行日志就继续走要根据业务决定是直接终止、重试还是调用barrier.reset()重新开启下一轮。5.3 线程中断不是小事一个线程被打断全员抛BrokenBarrierException中断的处理逻辑和超时非常相似。当某一个正在await()的线程被外部interrupt()时它自己会抛出InterruptedException而其他线程会在屏障被打破后抛出BrokenBarrierException。这种传播特性在协同时很有用但也容易让人困惑。比如你只是想取消当前这个线程的任务结果发现其他协作者也被影响了。反之如果你让线程池调用shutdownNow()它会中断所有工作线程这也会导致所有正在屏障点等待的线程收到异常。处理建议是在线程中断发生后尽量在 finally 块里调用barrier.reset()把屏障状态恢复避免影响后续任务复用。5.4 reset() 的使用时机与风险CyclicBarrier.reset()会把计数器重置回 parties并同时把当前 generation 标记为 broken唤醒所有正在等待的线程这些线程会收到BrokenBarrierException。这里有几点经验如果当前有线程正在阻塞在await()上你调用了 reset()这些线程会立刻醒过来并收到异常。这在很多场景下是一种“主动取消协作”的方式。如果在没有任何线程等待的时候调用 reset那就相当于把屏障恢复到初始状态可以安全复用。不要在用完一个屏障后随手调用 reset除非你明确知道当前状态。更常见的做法是直接 new 一个新实例尤其是当旧屏障已经 broken 的时候与其 reset 不如重新创建代码意图更清晰。6. 面试八股文的常见问法从用法到原理的自查清单6.1 面试官这样问你怎么答结合最近大家在准备 Java 面试时最关心的“八股”类问题我把 CyclicBarrier 的高频考点整理成了一问一答的形式方便自查。问题1CyclicBarrier 底层是怎么实现的答CyclicBarrier 内部维护了一个 ReentrantLock 和一个 Conditiontrip以及一个计数变量 count。每个线程调用 await() 后count 减 1如果不为 0就通过 condition.await() 挂起自己如果减到 0说明当前线程是最后一个到达的会先执行构造时传入的 barrierAction然后调用 nextGeneration() 唤醒所有等待线程并重置 count。此外内部还通过 Generation 对象管理屏障的状态用来区分不同轮次的协作。问题2一个线程在 await 时被中断会发生什么答这个线程会抛出 InterruptedException同时 CyclicBarrier 会把当前代的状态标记为 broken唤醒所有其他等待的线程这些线程会抛出 BrokenBarrierException。也就是说一个线程的中断会波及整组协作者。问题3await() 方法返回的 int 值有什么用答await()返回的是当前线程到达屏障时的“倒计数值”具体来说是--count之后的结果。最后一个到达的线程返回 0第一个到达的线程返回 parties-1。利用这个返回值你可以判断当前线程是不是最后一个到达的从而执行一些特殊逻辑比如绝杀、统计、兜底等。问题4parties 数量和实际线程数不一致会怎样答如果实际调用 await() 的线程数少于 parties那么已有线程会一直阻塞直到剩余线程调用 await()。如果实际调用线程数多于 parties那么多余的线程不会被屏障管理它们调用 await() 时会立刻进入下一轮等待可能导致逻辑错乱。所以编码时必须保证两部分数量严格一致。问题5barrierAction 是在哪个线程执行的答在最后一个调用 await() 的线程里同步执行执行完 barrierAction 后该线程继续返回。barrierAction 抛出的异常会传播给这个线程但不会中断已经触发的开门动作。6.2 易错点快问快答这里再整理一些细节判断题都是我平时帮别人 review 代码时容易发现的问题CyclicBarrier 是基于 AQS 实现的吗不是。CyclicBarrier 使用 ReentrantLock Condition 实现Semaphore、CountDownLatch 等才有一部分基于 AQS。CountDownLatch 的 await 可以让多个线程同时等待吗可以CountDownLatch 的 await() 可以被任意多个线程调用它们都会等待计数归零。CyclicBarrier 中某个线程抛出异常后其他线程会正常放行吗不会屏障会进入 broken 状态其他线程收到 BrokenBarrierException。CyclicBarrier 可以在所有线程到齐前被复用吗不能必须等当前 generation 结束所有线程到齐或屏障被打破后才进入下一轮。reset() 会让正在等待的线程正常通过吗不会等待线程会收到 BrokenBarrierException。CyclicBarrier 适合和线程池配合吗适合但必须保证线程池有足够线程容纳所有参与者否则会因为线程饥饿而死锁。在实际面试中与其死记硬背这些结论不如自己在本地把源码调试一遍打断点看 count 是怎么递减的、signalAll 是在哪触发的这比你背十篇面经都管用。毕竟并发这块的面试官问到最后一定是看你在遇到意外情况时能不能快速定位问题而不是看你背得多流利。我个人在使用了很长一段时间的 CyclicBarrier 之后最大的体会是它的使用门槛其实不高但一定要把“屏障破碎”这件事纳入设计的考虑范围任何中断、超时、异常都可能让一组线程从“互相协作”变成“互相等待”这时候如果没有兜底策略线上故障就是这么来的。希望这篇文章能帮你少走一点弯路。