并发编程里线程安全只是第一步线程之间的协调才是真正让项目从“能跑”变成“跑得稳”的分水岭。日常开发中CountDownLatch、CyclicBarrier、Semaphore 这三个同步工具类几乎是所有中型以上 Java 服务都会遇到的协调利器。Day30 这一练我把它们从原理到实战彻底拆开讲一遍。很多人刚开始接触这三个类时容易陷入“背 API”的误区知道countDown()是减一await()是等待但一放到真实业务里就懵。原因很简单——这三个工具分别解决的是完全不同的三类协作问题如果不懂它们背后的状态模型和适用边界代码写出来要么死锁要么结果不符合预期。这篇文章我会直接站在业务落地的角度带你搞清楚它们各自解决什么、怎么用、以及最容易踩的那些坑。1. 为什么需要专门的协调工具先理解并发协作的本质1.1 从一次实际业务故障说起我先讲一个我实际排查过的案例。某公司有一个数据报表服务每天早上八点会启动一个定时任务它需要从三个不同的数据源拉取数据等三份数据全部到齐后再做合并、去重、写库。最初实现时开发者用的是Thread.sleep()轮询一个共享标志位。结果就是某一天数据源响应慢了主线程等的时间不够就开始处理不完整的数据报表直接错乱。这种问题的根源在于多线程场景下我们需要的不是简单的“互斥”而是“线程之间的协作时序”——谁必须等谁等到什么程度才能继续。synchronized能保证同一时刻只有一个线程执行关键代码但它管不了“三个子任务都完成后再汇总”这种依赖关系。wait/notify虽然能实现等待与通知但用起来非常原始容易踩到信号丢失、过早唤醒之类的坑。1.2 synchronized 与 wait/notify 的局限先看一个典型的wait/notify协作代码感受一下它的痛点synchronized (lockObj) { while (!condition) { lockObj.wait(); } // 执行后续逻辑 }这里你至少要处理三件事一是必须用while循环包裹wait()防止虚假唤醒二是必须手动维护一个共享条件变量condition三是notify()和notifyAll()的选择要非常谨慎否则容易造成线程饿死。这些细节不是不能做但代码的可读性、可维护性直线下降。更重要的是这类底层协作原语解决不了几个高频业务需求一个线程要等另外 N 个线程全部执行完毕再继续。一组线程要互相等齐然后同时开始下一轮任务并且可以反复多轮。某一资源只允许固定数量的线程同时访问超出则排队等待。这三类需求如果都用wait/notify去手搓代码复杂度会爆炸而且测试极难覆盖所有边界情况。JDK 提供CountDownLatch、CyclicBarrier、Semaphore本质上就是把这三类协作场景抽象成了开箱即用的组件。1.3 三个工具类分别解决哪一类问题我用一个生活化的类比来建立整体认知CountDownLatch像一个倒计时闸机。比如景区大巴要等 30 名游客全部上车才发车每上一个游客计数减一减到 0 时闸机打开大巴出发。它是一次性的发车之后闸机就报废了。CyclicBarrier像一个回合制集合点。比如团队副本里每轮战斗前所有人都必须到场人齐了才开始打打完后各自分散下一轮再次集合。它可以循环使用多轮重复。Semaphore像一个停车场道闸。停车场只有 100 个车位车进来占一个车出去让一个没车位时后来的车只能排队等待。它管的是“同时最多允许多少个线程通过”。这三个类名字容易混但从业务视角去看功能非常清晰倒计时触发、回合同步、资源限流。后文我会逐个深入然后给你一套完整的实战代码。2. CountDownLatch一次性倒计时门闩的底层细节2.1 核心机制与状态流转CountDownLatch 的底层是一个基于AbstractQueuedSynchronizerAQS实现的共享锁。构造时传入的count就是初始状态值await()方法会阻塞当前线程直到状态值变为 0。每次调用countDown()内部会通过 CAS 将状态值减一当减到 0 时唤醒所有在await()上等待的线程。这里有个非常重要的概念CountDownLatch 的计数是只减不增的。一旦减到 0门闩就永久打开不能再重置。很多人误以为它和计数器一样可以重新初始化实际上如果你需要重置就得重新new一个对象。另外await()不等于“立刻通行”。它会让当前线程进入等待状态挂起线程直到满足条件。这意味着使用 CountDownLatch 时要注意线程资源的占用尤其在池化环境里如果等待时间过长可能会占满线程池。2.2 常用方法与参数陷阱核心方法只有三个CountDownLatch(int count)构造函数count 必须为正数如果为 0那么所有await()都会立刻返回不会阻塞。await()阻塞等待直到 count 变成 0。await(long timeout, TimeUnit unit)限时等待超时后返回 false线程继续往下走。countDown()计数器减一。getCount()查询当前计数一般用于日志和监控。使用中最大的陷阱有三个第一count 值与子任务数量必须一一对应。如果一个任务里调用两次countDown()或者漏调一次就会导致主线程永远等下去。建议把countDown()放在finally块里保证无论是正常完成还是异常退出都能执行。第二超时等待要处理返回值。很多新手写了await(3, TimeUnit.SECONDS)后以为超时就会自动做兜底其实代码会继续执行如果此时子任务还没完成后续逻辑就会读到不完整的共享数据。一定要判断返回值if (latch.await(5, TimeUnit.SECONDS)) { // 同步完成执行汇总 } else { // 超时走降级或重试逻辑 }第三不要在主线程里做繁重任务。如果你把主线程的核心逻辑放在await()之前而子线程又在等主线程释放某把锁就会出现循环等待甚至死锁。2.3 使用场景主线程等待多个子任务我举一个最常用的业务场景某个查询接口需要同时调用三个外部服务然后合并结果返回。为了提高响应速度我们把三个调用分别放到线程池中并发执行主线程等待所有子任务完成后做聚合。package com.demo.concurrent; import java.util.concurrent.CountDownLatch; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class CountDownLatchDemo { public static void main(String[] args) throws InterruptedException { ExecutorService pool Executors.newFixedThreadPool(3); CountDownLatch latch new CountDownLatch(3); final String[] results new String[3]; pool.submit(() - { try { results[0] queryServiceA(); } finally { latch.countDown(); } }); pool.submit(() - { try { results[1] queryServiceB(); } finally { latch.countDown(); } }); pool.submit(() - { try { results[2] queryServiceC(); } finally { latch.countDown(); } }); if (latch.await(10, TimeUnit.SECONDS)) { System.out.println(三个外部服务均已完成结果: String.join(,, results)); } else { System.out.println(等待超时部分服务未返回执行降级逻辑); } pool.shutdown(); } private static String queryServiceA() throws InterruptedException { Thread.sleep(1000); return A-data; } // 省略 B、C }这个模式的核心是用finally确保每次任务结束都扣减一次计数。这样哪怕某个服务调用抛异常主线程也不会被永久挂起。配合超时await整个流程既有并发能力又具备兜底机制。3. CyclicBarrier可循环屏障的工作原理与阶段协同3.1 从回合制任务说起CyclicBarrier 的字面意思是“循环屏障”。它会让一组线程互相等待直到所有线程都到达同一个“屏障点”然后才全部同时放行。最经典的场景是多个线程各自处理一部分数据处理完一轮后大家必须对齐一次再一起进入下一轮。与 CountDownLatch 的“主线程等子线程”不同CyclicBarrier 是参与线程之间互相等。假设有 4 个线程分别计算不同区域的数据每算完一个区域就调用barrier.await()等待其他 3 个线程。当 4 个线程都到达屏障时屏障破裂所有线程同时被释放进入下一轮计算。CyclicBarrier 允许传入一个barrierAction它是当所有线程到达屏障时由最后一个到达的线程执行的一个额外任务。这个动作很适合做“阶段汇总”。3.2 构造参数与重置机制构造函数有两种CyclicBarrier(int parties) CyclicBarrier(int parties, Runnable barrierAction)parties表示需要协同的线程数量。barrierAction在所有线程都到达屏障时执行可以用来做阶段间的地汇总或状态切换。CyclicBarrier 具备自动重置能力每次所有线程越过屏障后屏障会重置为初始状态可以继续下一轮使用。这一点与 CountDownLatch 不可复用形成鲜明对比。还有一个容易忽略的点如果参与线程因为异常中断会导致屏障破坏broken barrier。其他正在等待的线程会抛出BrokenBarrierException。很多初学者不知道如何处理这个异常导致程序莫名其妙崩溃。我的建议是在每个线程的await()调用处捕获BrokenBarrierException和InterruptedException统一做超时或重置处理。3.3 与 CountDownLatch 的关键差异我把两个工具的关键差异整理成一张表方便你记忆对比维度CountDownLatchCyclicBarrier协作模式主线程等子线程完成一组线程互相等齐计数器方向只减不增固定数量到达即递减放行后重置复用性不可复用用后即弃可循环复用触发动作无内置动作可指定 barrierAction异常表现子线程异常需手动处理线程中断会导致屏障破坏典型场景聚合多结果、任务启动门闩多轮迭代计算、分阶段任务选择边界其实很清晰如果你只需要“等待事件发生一次”用 CountDownLatch如果业务是多轮对抗、分阶段推进需要反复凑齐人马那就用 CyclicBarrier。硬要把 CyclicBarrier 当 CountDownLatch 用不是不行但会增加心智负担没必要。4. Semaphore信号量的流量控制哲学4.1 许可证模型与公平性设置Semaphore 的核心是“许可证”模型。构造函数传入一个许可数量比如new Semaphore(10)表示同一时刻最多允许 10 个线程通过。每次acquire()会从信号量中申请一个许可如果当前许可已用完线程就会阻塞直到其他线程释放许可。许可模型本质上是一个共享状态的非负整数获取操作会通过 CAS 减少计数释放操作会增加计数。如果信号量初始值为 1它就退化成了一个互斥锁不过它跟synchronized的区别在于Semaphore 允许你手动控制获取与释放的时机还可以实现“限时获取”等灵活策略。服务端开发里Semaphore 最典型的用法就是保护外部 API 调用。比如你的系统调下游接口下游最多支持 50 并发多了就会超时。我们就可以在调用前的门面层加一个Semaphore(50)把并发压到安全阈值内。还有一个容易被忽略的构造参数new Semaphore(int permits, boolean fair)。fairtrue表示按请求顺序分配许可即先申请的线程先获得适合对公平性有要求的场景fairfalse是默认值采用非公平模式性能更高但可能造成少量线程等待较久。4.2 获取与释放的对称性要求Semaphore 最严重的坑就是许可证泄漏。如果你在获取许可后因为异常提前返回没有在finally里释放许可那么许可数会越变越少最终信号量被耗尽所有后续线程全部阻塞。我见过一个线上事故某服务在调用第三方接口时使用 Semaphore 限流但代码里acquire()之后业务代码抛了运行时异常而release()写在异常分支里没被执行导致信号量许可从 100 慢慢降到 0整个服务雪崩。从那之后我在团队里立了一条规矩注意Semaphore 的release()必须放在finally块中确保任何情况下都能归还许可。获取和释放的操作必须配对出现。另外acquire()有两种形式acquire()响应中断如果线程被中断会抛出InterruptedException。acquireUninterruptibly()不响应中断线程会一直等待直到获取许可。还有tryAcquire(timeout, unit)可以在指定时间内尝试获取拿不到就返回 false。这种带超时的方式非常适用于需要降级的场景。4.3 经典限流示例扩展下面是一个更真实的限流场景模拟 20 个请求同时涌来但只允许 5 个线程同时访问一个共享资源。package com.demo.concurrent; import java.util.concurrent.Semaphore; import java.util.concurrent.TimeUnit; public class SemaphoreDemo { public static void main(String[] args) { Semaphore semaphore new Semaphore(5); for (int i 1; i 20; i) { final int requestId i; new Thread(() - { try { if (semaphore.tryAcquire(3, TimeUnit.SECONDS)) { try { System.out.println(请求 requestId 已通过开始调用下游接口...); Thread.sleep(1000); } finally { semaphore.release(); System.out.println(请求 requestId 调用完毕释放许可); } } else { System.out.println(请求 requestId 等待超时进入降级队列); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }).start(); } } }这个示例展示了两个关键点一是用tryAcquire代替acquire避免无限等待二是释放操作包裹在finally中。实际生产环境你还可以在此基础上加入队列缓存、动态拒绝策略等但底层的信号量协调逻辑基本就是这样。5. 实操过程三个工具在业务系统中的落地实现5.1 场景设计模拟电商大促中的并发协调理论再好不落实到业务上都是空中楼阁。我用一个综合模拟场景把三个工具串起来模拟电商大促期间的订单批量处理系统。需求拆分成三个步骤一个大订单被拆分成多个子任务比如库存、价格、优惠券、配送四个子任务并发执行全部完成后才能生成最终订单结果。订单处理分阶段第一阶段校验并填充基础数据第二阶段计算金额和优惠第三阶段扣减库存并生成物流单。每阶段所有子任务都必须全部到达才能进入下一阶段。生成物流单后调用外部物流接口但该接口每秒最多只能处理 100 个请求需要限流保护。这三个需求正好对应 CountDownLatch、CyclicBarrier、Semaphore。我们把代码分三块写出来方便你直接参照。5.2 CountDownLatch 实现订单批量处理先看第一步假设一个订单需要并发做四项检查主线程等待检查全部通过后才允许生成订单。package com.demo.concurrent; import java.util.concurrent.CountDownLatch; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class OrderSplitTask { public static void main(String[] args) throws InterruptedException { ExecutorService pool Executors.newFixedThreadPool(4); CountDownLatch latch new CountDownLatch(4); boolean[] checkResults new boolean[4]; pool.submit(() - { try { checkResults[0] checkStock(); } finally { latch.countDown(); } }); pool.submit(() - { try { checkResults[1] checkPrice(); } finally { latch.countDown(); } }); pool.submit(() - { try { checkResults[2] checkCoupon(); } finally { latch.countDown(); } }); pool.submit(() - { try { checkResults[3] checkDelivery(); } finally { latch.countDown(); } }); if (latch.await(10, TimeUnit.SECONDS)) { boolean allPass true; for (boolean result : checkResults) { allPass allPass result; } System.out.println(所有子任务检查完成总体检查结果: (allPass ? 通过 : 不通过)); } else { System.out.println(检测超时订单暂缓处理); } pool.shutdown(); } private static boolean checkStock() throws InterruptedException { Thread.sleep(800); return true; } // 其余 check 方法省略逻辑相同 }实际业务中每个检查可能都会访问不同的库或者缓存并发度提升带来的收益非常明显。注意checkResults数组的写入发生在子线程主线程通过await()建立 happens-before 关系所以读取时能看到子线程写入的结果不需要额外加 volatile。5.3 CyclicBarrier 实现分阶段数据聚合第二步模拟三个子订单处理器必须每一阶段都对齐后进入下一阶段。这里我用 CyclicBarrier 的循环特性。package com.demo.concurrent; import java.util.concurrent.BrokenBarrierException; import java.util.concurrent.CyclicBarrier; public class OrderPhaseCoordinator { private static final int THREAD_COUNT 3; public static void main(String[] args) { CyclicBarrier barrier new CyclicBarrier(THREAD_COUNT, () - { System.out.println(当前阶段所有子任务已就绪进行阶段汇总时间: System.currentTimeMillis()); }); for (int i 1; i THREAD_COUNT; i) { final int workerId i; new Thread(() - { try { // 第一阶段 System.out.println(Worker workerId 开始第一阶段: 校验基础数据); Thread.sleep((workerId % 3) * 1000); barrier.await(); // 第二阶段 System.out.println(Worker workerId 进入第二阶段: 计算金额与优惠); Thread.sleep((workerId % 2) * 1000); barrier.await(); // 第三阶段 System.out.println(Worker workerId 进入第三阶段: 扣减库存并生成物流单); barrier.await(); System.out.println(Worker workerId 全部完成); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } catch (BrokenBarrierException e) { System.out.println(Worker workerId 检测到屏障被破坏执行恢复逻辑); } }).start(); } } }运行后你会看到三个线程在时间点不完全一致的情况下依然强制在每个阶段的起点对齐。这里的barrierAction很有意思——它由最后一个到达屏障的线程执行所以你在动作里千万不要做耗时很长的操作否则会拖累整个进度。阶段汇总建议只收集结果、更新状态不要执行重量级 IO。5.4 Semaphore 实现下游接口限流第三步在物流单生成后调用外部物流接口。为了保护接口不被打挂我在调用入口加一个 Semaphore限制最大并发数。package com.demo.concurrent; import java.util.concurrent.Semaphore; import java.util.concurrent.TimeUnit; public class LogisticsApiGuard { private static final int MAX_CONCURRENT 100; private static final Semaphore semaphore new Semaphore(MAX_CONCURRENT, true); public static void main(String[] args) { for (int i 1; i 200; i) { final int orderId i; new Thread(() - callLogisticsApi(orderId)).start(); } } private static void callLogisticsApi(int orderId) { try { if (semaphore.tryAcquire(2, TimeUnit.SECONDS)) { try { System.out.println(订单 orderId 正在调用物流接口当前并发: (MAX_CONCURRENT - semaphore.availablePermits())); Thread.sleep(500); } finally { semaphore.release(); } } else { System.out.println(订单 orderId 等待超时进入重试队列); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }注意我这里使用了公平模式这样在高并发下每个订单不会因为被反复插队而饿死。availablePermits()可以用来做监控但要注意它只是一个实时快照不能当作精确的并发计数来使用。更准确的做法是自己维护一个AtomicInteger记录当前正在处理的请求数。5.5 运行结果分析与性能观察如果你把上述三段代码跑起来配合System.currentTimeMillis()打印日志会发现几个有意思的现象CountDownLatch 版本中await()返回后主线程立即执行汇总但四个子线程可能还没完全退出只是把countDown后的清理动作留在后台。所以不要在await()返回后立刻假设“子线程已销毁”。CyclicBarrier 版本中每个阶段耗时不取决于单个线程的最快速度而是最慢速度。这正好体现了“木桶效应”。Semaphore 版本中200 个请求同时启动但真正进入接口调用的同时并发数始终不会超过 100多出来的请求要么排队要么超时降级。这三个工具各自管一摊但组合起来以后整个订单处理链路的并发协调就能做到“该等的等该限的限”。6. 常见问题与排查技巧实录6.1 CountDownLatch 被永久阻塞的排查典型现象主线程卡在latch.await()永远不返回。排查思路按顺序来检查countDown()调用次数是否和初始 count 相等。检查countDown()是否可能在子线程异常分支中未被调用。这时可以给await()加超时用超时日志反推。检查是否有子线程因为获取锁失败或者执行了死循环根本没走到countDown()。我个人的排查技巧是在构造 CountDownLatch 时把初始计数与子任务列表绑定然后用一个AtomicInteger记录实际完成的次数。如果日志中“实际完成次数”小于初始计数那就非常直观地定位到哪个任务没完成。6.2 CyclicBarrier 循环复用时的异常处理CyclicBarrier 在使用中如果某个线程在await()期间被中断或者有线程因为业务异常提前退出屏障会进入 broken 状态。此时其他等待线程会抛出BrokenBarrierException。如果不捕获线程会直接崩溃如果捕获了不处理整个多轮任务就会乱套。我的建议是遇到BrokenBarrierException时先检查屏障是否重置必要时调用barrier.reset()。但如果已经有线程在等待重置操作会让他们也收到异常。所以更稳妥的做法是不要让业务线程在屏障前抛异常而是把业务执行放在try/catch中把异常封装进结果正常到达屏障等待处。6.3 Semaphore 许可证泄漏问题这是我见过最多的事故来源。典型症状随着时间推移调用下游接口的超时率越来越高最后所有请求都卡死在acquire()。排查手段很简单在释放处加日志或者用监控工具查看availablePermits()的曲线。如果初始是 100运行一小时后变成 50那基本可以断定有线程没有释放。根治方案就是前面强调的release()必须放在finally块中并且获取和释放要严格配对。如果你想更保险可以用tryAcquire 活跃线程计数的方式结合定时检查来发现泄漏。6.4 综合避坑清单我把三个工具的避坑点汇总成一张速查表建议你直接截图保存工具易错点正确姿势CountDownLatchcount 与任务数不一致在 finally 中 countDownCountDownLatchawait 无限阻塞使用带超时的 awaitCyclicBarrier忽略 BrokenBarrierException捕获异常并执行兜底CyclicBarrier在 barrierAction 中做重操作只做轻量汇总和状态更新Semaphorerelease 遗漏finally 中释放许可Semaphore非公平导致线程饿死对公平性有要求时设置 fairtrue全部直接使用默认构造不评估参数根据并发量和业务需求显式设置7. 选型建议什么场景该用哪个工具7.1 三张工具能力对比表工具核心语义方向性复用性后置动作推荐度CountDownLatch事件倒计时触发主等子不可复用无入门必备CyclicBarrier多线程互相等待多线程对等可循环有 barrierAction阶段协同利器Semaphore许可数限制多线程共享可循环无限流安全阀从场景匹配度上讲主线程需要等待一个或多个异步任务完成优先 CountDownLatch。一组线程需要重复进行多轮同步每轮开始前必须人齐就用 CyclicBarrier。下游资源并发受限需要控制同时访问的线程数选 Semaphore。7.2 我个人的选型经验与建议这三个工具在实际项目中往往不是单独出现的。我做过一个数据同步系统里面同时用了 CountDownLatch 控制任务启动、CyclicBarrier 分阶段聚合、Semaphore 保护文件写入通道彼此配合效果很好。我的建议是不要为了用而用。如果你的任务并发量很低线程之间几乎没有交互直接用顺序执行反而更简单。当你发现代码中频繁出现Thread.sleep轮询、或者使用wait/notify却需要强依赖一个复杂状态时再考虑这三个工具。另外在线上环境使用这些工具时最好把关键参数如计数、许可数、超时时间做成可配置项。因为流量是波动的你很难在最初阶段就确定一个绝对合理的并发数。我曾把一个 Semaphore 的许可数从 50 调整为 200只改了一个配置参数系统吞吐直接翻倍而代码一行没动。最后再分享一个小技巧所有await()和acquire()的调用处一定要打日志或者做监控。并发问题的复现难度指数级高于普通 bug唯一能救你的就是事发时的第一手数据。我见过太多系统在出问题时连最基本的“卡在哪个 await 上”都不知道只能靠瞎猜那才是真正的灾难。