先问一个很现实的问题一次接口请求里你需要同时去查 5 个不同服务的数据等它们全部返回之后才能拼装结果。你是老老实实写一个 for 循环挨个查还是用 CountDownLatch 把 5 个查询同时丢进线程池然后让主线程等一个倒计时归零的信号相信做过几年 Java 开发的人都遇到过类似的需求也大概率在项目里用过 CountDownLatch。这个位于 java.util.concurrent 包下的同步工具类中文圈子里习惯叫它倒计时门闩。它的核心作用一句话就能讲明白允许一个或多个线程进入等待状态直到其他线程完成一组操作后再放行。CountDownLatch 是 Java 并发编程里最容易被理解、也最容易被用错的工具之一几乎每次 Java 面试题涉及并发时都会提到它。这篇文章我打算结合自己项目里的实战踩坑经验把 CountDownLatch 的原理、用法、源码机制和常见错误一次聊透。适合刚接触并发编程的同学建立扎实认知也适合准备 Java 开发工程师面试的朋友作为知识点串讲。我会尽量用大白话讲清楚底层机制让你不仅能写对代码还能说出它为什么是这样设计的。1. 先搞懂 CountDownLatch 是什么一个会倒数计时的门闩1.1 一个真实场景引出主角说个我最近负责的数据报表功能。需求很简单把用户最近 30 天的订单数、退款数、客服工单数、登录记录和库存预警这 5 类数据分别从不同的服务查出来再拼成一个响应对象返回给前端。一开始我图省事直接在接口里写了个 for 循环挨个查。结果一到高峰期这个接口的 P99 耗时直接飙到 1.5 秒以上因为每个内部服务调用平均要 300 毫秒5 个调用串行执行时间全部累加起来了。后来改成线程池并发查询情况立刻不一样5 个调用同时发起理论上最大等待时间从5 次之和降到了最慢的那一次也就是 300 毫秒左右。问题来了主线程把 5 个任务丢进线程池后怎么知道它们都已经执行完了如果直接不等待前端的响应结果就会缺数据如果粗暴地 sleep 一个固定时间要么等太久要么等不够。这时候就需要一个倒计时机制每个任务完成时扣一下计数计数归零时主线程立刻被唤醒。CountDownLatch 就是为这个场景设计的。它底层维护一个整数计数器创建时指定初始值比如上面这个例子就设成 5。每有一个任务完成调用一次 countDown()计数减一主线程调用 await() 阻塞等待直到计数减到 0 才继续往下走。注意它等的不是某个线程结束而是某个事件发生了多少次。这一点在理解上很关键后面我会反复强调。1.2 门闩模型的三个要素把 CountDownLatch 类比成一扇带锁的门会好理解很多门的锁由一根插销控制插销上有 count 个刻度。调用 await() 的线程站在门里等待只要插销还有一个刻度没落下来门就打不开。其他线程每完成一次任务就调用 countDown() 让插销落下一格等到 count 个刻度全部落下门闩自动弹开所有等待的线程一起通过。这个模型里有三个关键点值得记住等待者可以有多个不止主线程能 await任何线程都能调用 await()。只要门不开所有调了 await() 的线程都会阻塞。countDown 和 await 是解耦的负责倒计时的线程不需要认识等待的线程只需要拿到同一个 CountDownLatch 实例调用对应方法即可。计数器不可逆一旦归零这个实例就永久处于门已打开状态后续再调用 countDown() 不会有效果再调用 await() 也会直接放行。它没有提供重置计数的方法。这些特性决定了它的适用边界适合一次性等待不适合重复使用。至于为什么这样设计以及哪些场景需要二次等待看到后面的源码分析和 CyclicBarrier 对比就明白了。1.3 什么场景不该硬用它我见过不少同学在需要反复协调多批任务的场景里硬用 CountDownLatch结果每个循环都 new 一个实例代码又笨又容易出错。比如有两批任务第一批 5 个第二批 8 个你当然可以创建两个 CountDownLatch 分别等待但整体代码复杂度会明显上升。如果任务批次数量不固定或者需要同一批线程重复协作那就该换思路了具体可以参考后面讲 CyclicBarrier 和 CompletableFuture 的对比。一句话总结CountDownLatch 最擅长的是一次性聚合等待。它不负责结果收集也不负责任务调度它只做一个最纯粹的事——计数与放行。2. 核心 API 与最关键的两个姿势await 与 countDown2.1 构造函数计数器从多少开始CountDownLatch 的构造函数只有一个public CountDownLatch(int count)这个 count 就是初始计数必须是大于等于 0 的整数。如果传负数直接抛 IllegalArgumentException。count 的真实意义是需要等待多少个事件完成所以事件数量得提前确定因为构造函数只执行一次后面没有任何 setter 能改初始值。这里有两个容易被忽略的小细节count 设为 0 时所有调用 await() 的线程会立刻返回不阻塞。这种用法业务里很少见所以别把 0 当成默认值来用。count 的值是事件数量不一定等于线程数量。同一个线程完成多个事件也可以多次调用 countDown()。比如一个线程负责处理 3 个批次那它完全可以 countDown 三次。2.2 await 与带超时的 awaitCountDownLatch 有两个等待方法public void await() throws InterruptedException public boolean await(long timeout, TimeUnit unit) throws InterruptedException第一个是无超时版本调用后线程一直阻塞直到计数归零或被中断。注意它和 Thread.sleep 一样会响应中断一旦线程的中断标志位被设置await 会抛出 InterruptedException把中断信号传播出去。第二个是带超时版本也是我在生产代码里更推荐用的最多等待指定的时间如果计数在这段时间内归零返回 true如果超时了计数还不为 0返回 false线程继续执行。这个返回值必须认真处理不能假装没看见。比如上面那个报表接口如果 5 个查询里有一个特别慢超过了预算时间await 返回 false 后接口不能直接返回残缺数据得走降级逻辑把超时的那个来源标记为暂时不可用。选超时时间也有讲究不能拍脑袋写一个看起来够用的固定值。最好结合上游服务的 P99 耗时和接口自身的 SLA 来定。比如你希望整个聚合接口在 1 秒内返回内部调用平均耗时 300ms、最慢 800ms那 await 的超时时间设成 900ms 就是比较合理的选择留 100ms 给主线程做后续拼装。2.3 countDown 的调用边界为什么必须在 finally 里countDown 方法签名很简单也不抛受检异常public void countDown()但真正的坑不在方法本身而在调用的位置。最典型的问题是任务执行过程抛了异常函数提前返回countDown() 根本执行不到主线程就一直阻塞在 await() 上整个流程卡死。这类问题在测试环境里不明显——通常任务都能成功——一旦线上偶发异常就变成接口超时、服务假死排查起来特别费劲。正确姿势是把 countDown 放进 finally 块executor.submit(() - { try { // 真正的业务逻辑允许抛异常 doSomething(); } finally { latch.countDown(); } });这样无论业务逻辑正常结束还是抛出异常计数都一定会被扣减主线程永远不会因为某个任务失败而无限期等待。我面试别人时也常问这个问题如果某个任务异常了你的 CountDownLatch 会怎样答不出 finally 的人多半都在线上栽过跟头。另外还要注意 countDown 的次数边界。任务是 5 个但代码 bug 导致同一个任务被执行了两次 countDown计数就会提前归零主线程提前放行数据不完整。所以业务逻辑要尽量保证一个事件恰好 countDown 一次不能多也不能少。这句话听起来简单在递归任务、批处理任务里要做到位并不容易。3. 三个实战场景覆盖 80% 的并发需求3.1 场景一主任务等待多个子任务完成这就是我开头说的报表聚合场景。需求很明确把 n 个独立任务丢给线程池主线程等全部完成后再继续。代码可以这样写int taskCount 5; CountDownLatch latch new CountDownLatch(taskCount); ExecutorService executor Executors.newFixedThreadPool(taskCount); for (int i 1; i taskCount; i) { int taskId i; executor.submit(() - { try { // 模拟调用远程服务耗时约 200-500ms Thread.sleep(ThreadLocalRandom.current().nextLong(200, 500)); System.out.println(任务 taskId 完成); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { latch.countDown(); } }); } latch.await(); executor.shutdown(); System.out.println(所有任务全部完成开始组装结果);有几个细节值得说明。第一线程池的线程数在这里设成 taskCount纯粹是为了演示生产环境里资源有限线程数通常会小于任务数任务会在队列里排队latch 等待的是5 个任务都真正执行完而不是5 个线程都创建完所以哪怕线程数只有 3这段逻辑也没问题。第二executor.shutdown() 放在 await 之后是为了让线程池里的任务先跑完、计数归零、主线程放行然后才关闭线程池避免线程池提前销毁导致排队任务被拒绝。第三如果你想让 JVM 正常退出shutdown 之后往往还需要 awaitTermination那是另一个话题这里不展开。3.2 场景二所有线程就绪后统一开跑这个场景在高并发压测和性能测试里非常常见你希望 10 个线程在同一个时刻开始执行而不是一个接一个地启动。用两个 CountDownLatch 可以优雅地实现int threadCount 10; CountDownLatch readyLatch new CountDownLatch(threadCount); CountDownLatch startLatch new CountDownLatch(1); for (int i 0; i threadCount; i) { new Thread(() - { // 1. 告诉主线程我已就绪 readyLatch.countDown(); // 2. 等待主线程发令枪 try { startLatch.await(); System.out.println(线程开始执行时间戳 System.currentTimeMillis()); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }).start(); } // 主线程等待所有线程就绪 readyLatch.await(); // 就绪后统一放行 startLatch.countDown();这个模式的核心在于 startLatch 初始计数为 1它扮演的不是逐格倒计时而是一个开关。10 个线程全部调用 await() 等待开关打开主线程确认所有人就绪后调用一次 countDown()开关打开所有线程同时被唤醒。readyLatch 则保证主线程不会在大家还没准备好时就提前按下开关。这种双门闩写法效果上接近 CyclicBarrier但用 CountDownLatch 可以更直观地控制等到什么时候才放行。实际压测时我要强调一点线程真正执行的起始时间并不会完全一致毕竟线程被唤醒后要经过操作系统的调度才会拿到 CPU。能做到的是从等待状态同时被释放而不是纳秒级对齐够用就好别强求完美同时。3.3 场景三多个初始化任务并行执行还有一个我经常用的场景服务启动阶段需要同时初始化数据库连接池、Redis 连接、消息队列生产者、远程配置中心客户端等一堆组件。这些初始化操作彼此没有依赖但如果串行执行启动时间会变得很长。思路和场景一几乎一样每个初始化任务完成后 countDown 一次主线程 await 到计数归零后再对外宣布服务启动完成。这段代码写出来后你会发现CountDownLatch 的价值不是让初始化本身变快而是让你优雅地把并行执行和等待收口分开代码结构清晰得多。值得留意的是启动期间的初始化任务一旦失败你并不希望整个服务闷头卡住。所以这里强烈建议用带超时的 await并且对返回的 boolean 做分支判断false 时记录哪个组件初始化失败给出有意义的告警信息再决定是重试还是退出。3.4 场景四把等待锁封装成通用组件时的注意事项如果你想把 CountDownLatch 的等待逻辑抽成公共组件我建议至少暴露两个方法一个是带超时的等待方法返回值交给调用方决定如何处理另一个是安全的 countDown 包装内部捕获异常并记录日志。这样可以让团队里的同学少踩很多坑也方便出现问题时从日志里定位到底是哪个环节没有执行到。组件里还要注意实例的隔离性。多个业务共用同一个静态 CountDownLatch 是非常危险的做法一个业务的 countDown 可能把另一个业务的计数提前清零造成数据混乱。每个独立的业务场景都应该 new 自己的实例并且把它的生命周期控制在业务方法内部。4. 从面试官视角看源码AQS 共享模式与 state 计数源码部分是面试里的硬核考点也是理解为什么 CountDownLatch 能实现多线程通知的关键。很多 Java 八股文里都会提到 CountDownLatch但只停留在使用方法层面。我现在从源码角度把内部机制拆开。4.1 CountDownLatch 的内部结构CountDownLatch 的源码不长核心是一个继承自 AbstractQueuedSynchronizerAQS的内部类 Syncprivate static final class Sync extends AbstractQueuedSynchronizer { Sync(int count) { setState(count); } int getCount() { return getState(); } protected int tryAcquireShared(int acquires) { return (getState() 0) ? 1 : -1; } protected boolean tryReleaseShared(int releases) { // 自旋 CAS 把 state 减 1 for (;;) { int c getState(); if (c 0) { return false; } int nextc c - 1; if (compareAndSetState(c, nextc)) { return nextc 0; } } } }看到这里就明白了CountDownLatch 把构造参数 count 直接存成了 AQS 的 state。AQS 是整个 JUC 并发包的基石ReentrantLock、Semaphore、ReentrantReadWriteLock 等工具都基于它构建。CountDownLatch 的状态只有两种方向大于 0 和等于 0所以它天然适合用 AQS 的共享锁模式来实现。4.2 await 和 countDown 分别做了什么await() 底层调用的是 AQS 的 acquireSharedInterruptibly(1)。它的逻辑是先尝试 acquireShared也就是执行 tryAcquireShared如果 state 是 0直接返回 1表示可以通行如果 state 不是 0返回 -1当前线程就被包装成节点放进 AQS 的等待队列进入阻塞挂起状态等待后续被唤醒。countDown() 底层调用的是 AQS 的 releaseShared(1)。它会执行 tryReleaseShared用自旋配合 CAS 把 state 减 1。注意每一次 countDown 只减一格多个线程同时调用时CAS 保证了同一时间只有一个线程能成功修改 state所以计数操作是线程安全的。当某一次减完之后 state 变成 0tryReleaseShared 返回 trueAQS 就会执行 doReleaseShared把等待队列里的线程逐个唤醒。这正是广播唤醒的实现原理当计数归零的时刻所有之前调用 await() 而阻塞的线程会被一起唤醒而不是只唤醒其中一个。理解了这一点你就不会对多个线程等待同一个门闩感到困惑了。4.3 为什么 CountDownLatch 是一次性的这个设计原因也可以从源码里直接找到答案。AQS 的 state 一旦减到 0没有任何入口把它重新设置回初始值。Sync 里只有构造时的 setState 和 tryReleaseShared 里的递减逻辑没有一个 reset 方法。计数归零后 tryReleaseShared 会直接返回 false不做任何修改tryAcquireShared 也永远返回 1await 一律直接放行。所以如果你需要分批次反复协调要么每次创建新的 CountDownLatch 实例要么改用 CyclicBarrier。CyclicBarrier 之所以可以循环使用是因为它内部维护了 count 和 reset 机制每次屏障点冲破后都会重置计数。这是两者在设计目的上的根本差异。小结一下这段源码分析CountDownLatch 用 AQS 的共享锁把计数归零和唤醒等待线程两个动作绑定在一起同时借助 CAS 保证并发安全。整段源码加起来几十行设计却非常精巧。这也是我建议每个做 Java 开发的同学至少读一遍 AQS 源码的原因——读懂了它你看 JUC 下的其他工具就像看同一套设计模式的不同变体。5. 与 CyclicBarrier、join、CompletableFuture 的对比5.1 一张表看透四种等待机制的差异很多初学者容易把 CountDownLatch 和 Thread.join() 搞混后来又冒出 CyclicBarrier 和 CompletableFuture选择困难症直接发作。我整理了一张对比表方便你按需选型。维度CountDownLatchCyclicBarrierThread.join()CompletableFuture.allOf()等待对象事件计数归零线程人齐线程结束异步任务是否可复用否是否每次新建等待时能否拿返回值否否否是主线程能否超时等待支持支持不支持支持是否适合线程池任务适合适合不适合适合典型场景一次性聚合等待多轮协作、循环赛跑串行启动顺序控制异步流水线、结果合并这个表里最值得关注的是第一行。Thread.join() 的语义是等这个线程死了它只能等 Thread 对象本身结束没法等待一个被线程池执行的任务CountDownLatch 等的是事件事件由 countDown() 来宣告不关心是哪个线程、什么时间完成的。理解了这个区别你就不会在 ExecutorService 里用 join 了因为线程池里的线程根本不让你 join你拿到的是 Future 而不是 Thread。5.2 什么时候只能选 CountDownLatch有几个场景CyclicBarrier 和 CompletableFuture 都不太合适优先考虑 CountDownLatch统一出发的并发压测。CyclicBarrier 的人齐后同时冲破也能做到类似效果但需要处理 reset 之后的状态而用 CountDownLatch 的两个实例反而更直白。初始化任务的聚合等待。你只是要等这些任务都完成不需要拿每个任务的返回值也不需要它们互相协作CountDownLatch 代码量最少。希望等待时引入超时控制且等待线程不止一个。CompletableFuture.allOf 也能等待但如果你想同时让多个独立线程都停在同一扇门等放行门闩模型更贴合。5.3 如果还想拿到返回结果怎么办CountDownLatch 本身不负责结果收集它是一个纯粹的同步信号工具。如果你除了等待完成还需要拿每个任务的返回值我的建议是直接用 CompletableFuture.allOf把每个子任务封装成 CompletableFuture再用 allOf(...).join() 统一等待最后逐个 get 结果。这样写出来的代码比线程池 CountDownLatch 共享容器的组合简洁得多类型上也更安全。不过也要说句公道话CountDownLatch 在需要手动控制放行时机的场景里仍然不可替代。CompletableFuture 的编排能力很强但它没有一个外部线程随时拨一下开关的机制。你没法让 10 个 CompletableFuture 任务同时停在一个起跑线等一个外部信号而 CountDownLatch 可以。工具之间本来就是互相补充不是谁淘汰谁。6. 实操避坑那些让我 debug 到怀疑人生的细节6.1 常见问题速查表我把自己和团队踩过的坑集中列出来每条都是真实事故的浓缩。现象根本原因解决方案主线程永久阻塞子任务抛异常countDown 没执行到把 countDown 放进 finallyawait 提前返回但数据不完整某个任务 countDown 了多次严格保证一事件一扣减必要时加日志超时返回 false 但业务不感知主线程直接忽略返回值对 false 做降级、重试或告警线程池任务跑不完任务里又套了等待互相等导致死锁检查任务间是否存在依赖避免任务内阻塞式等待JVM 无法退出线程池未关闭或非守护线程存活显式 shutdown 并等待终止同一实例在下一批任务里失效不了解不可复用的特性每批任务 new 一个或改用 CyclicBarrier6.2 排查思路先看线程栈再数 countDown遇到 CountDownLatch 相关的卡死问题我的第一反应永远是先抓线程栈。用 jstack 或者 Arthas 查看主线程停留在哪个方法上如果看到 java.util.concurrent.CountDownLatch.await 这样的栈帧再去看另外几个工作线程的栈。如果工作线程不在执行业务代码而是阻塞在别的资源上十有八九是死锁如果工作线程根本没被创建就得检查线程池有没有正常接受任务。一旦确认是计数器没归零还有一个很实用的排查手段在 await 超时返回 false 之后打印一下当前的 getCount 还剩几。这个数字能直接告诉你有多少个事件没完成再对着任务清单一个个核对问题就能快速收敛。我见过有人在 20 个任务的场景里排查了半天最后发现代码里任务数写死了 15有 5 个任务压根没提交到线程池——这种问题看一眼 getCount 就能定位。6.3 几个生产级建议最后给三个我认为很有价值的生产建议。第一所有 await 都尽量带上超时除非你能绝对保证事件一定会在可预期时间内完成。不带超时的 await 一旦碰上异常路径等于把整个应用的运行权交给一个可能永远不会发生的事件风险极高。第二CountDownLatch 实例的生命周期要和业务作用域绑定。如果实例被意外共享到多个互不相关的业务流程里一个业务的 countDown 可能扰乱另一个业务的计数造成诡异的数据不一致。每个独立的等待集合都应该有自己的实例不要图省事复用全局的。第三在高并发的批量场景里综合考虑 CompletableFuture 或 ForkJoinPool 的并行编排能力。CountDownLatch 并不是万能的它擅长的是等待不擅长收集结果、异常传递、组合依赖。工具选型时先想清楚需求到底是等待还是编排别拿一把锤子砸所有的钉子。写在最后一点个人体会搞明白 CountDownLatch 这个类我的收获其实远不止多背一个 API。真正改变我习惯的是那种把等待的开关抓到主线程手里的思路并行任务发起只是一瞬间难的是知道什么时候该收口。而 CountDownLatch 用一个小小的计数器把收口这个动作变成了可控制、可超时、可中断的精确操作。最后再分享一个小技巧如果你厌倦了在代码里写 try-finally 来确保 countDown 执行可以考虑把 CountDownLatch 的 countDown 原语封装进自己的任务包装类里比如提供一个 SafeCountDownTask在内部统一处理 finally 和异常日志。这种封装能让业务代码更干净也能最大程度避免团队成员重复踩坑。代码写得久了你会发现并发工具本身不复杂复杂的是让人人都在正确的位置调用它。 
长河君 · 2026/10/7 5:10:41 · 阅读 1.2k CountDownLatch实战：原理、用法与避坑指南
先问一个很现实的问题一次接口请求里你需要同时去查 5 个不同服务的数据等它们全部返回之后才能拼装结果。你是老老实实写一个 for 循环挨个查还是用 CountDownLatch 把 5 个查询同时丢进线程池然后让主线程等一个倒计时归零的信号相信做过几年 Java 开发的人都遇到过类似的需求也大概率在项目里用过 CountDownLatch。这个位于 java.util.concurrent 包下的同步工具类中文圈子里习惯叫它倒计时门闩。它的核心作用一句话就能讲明白允许一个或多个线程进入等待状态直到其他线程完成一组操作后再放行。CountDownLatch 是 Java 并发编程里最容易被理解、也最容易被用错的工具之一几乎每次 Java 面试题涉及并发时都会提到它。这篇文章我打算结合自己项目里的实战踩坑经验把 CountDownLatch 的原理、用法、源码机制和常见错误一次聊透。适合刚接触并发编程的同学建立扎实认知也适合准备 Java 开发工程师面试的朋友作为知识点串讲。我会尽量用大白话讲清楚底层机制让你不仅能写对代码还能说出它为什么是这样设计的。1. 先搞懂 CountDownLatch 是什么一个会倒数计时的门闩1.1 一个真实场景引出主角说个我最近负责的数据报表功能。需求很简单把用户最近 30 天的订单数、退款数、客服工单数、登录记录和库存预警这 5 类数据分别从不同的服务查出来再拼成一个响应对象返回给前端。一开始我图省事直接在接口里写了个 for 循环挨个查。结果一到高峰期这个接口的 P99 耗时直接飙到 1.5 秒以上因为每个内部服务调用平均要 300 毫秒5 个调用串行执行时间全部累加起来了。后来改成线程池并发查询情况立刻不一样5 个调用同时发起理论上最大等待时间从5 次之和降到了最慢的那一次也就是 300 毫秒左右。问题来了主线程把 5 个任务丢进线程池后怎么知道它们都已经执行完了如果直接不等待前端的响应结果就会缺数据如果粗暴地 sleep 一个固定时间要么等太久要么等不够。这时候就需要一个倒计时机制每个任务完成时扣一下计数计数归零时主线程立刻被唤醒。CountDownLatch 就是为这个场景设计的。它底层维护一个整数计数器创建时指定初始值比如上面这个例子就设成 5。每有一个任务完成调用一次 countDown()计数减一主线程调用 await() 阻塞等待直到计数减到 0 才继续往下走。注意它等的不是某个线程结束而是某个事件发生了多少次。这一点在理解上很关键后面我会反复强调。1.2 门闩模型的三个要素把 CountDownLatch 类比成一扇带锁的门会好理解很多门的锁由一根插销控制插销上有 count 个刻度。调用 await() 的线程站在门里等待只要插销还有一个刻度没落下来门就打不开。其他线程每完成一次任务就调用 countDown() 让插销落下一格等到 count 个刻度全部落下门闩自动弹开所有等待的线程一起通过。这个模型里有三个关键点值得记住等待者可以有多个不止主线程能 await任何线程都能调用 await()。只要门不开所有调了 await() 的线程都会阻塞。countDown 和 await 是解耦的负责倒计时的线程不需要认识等待的线程只需要拿到同一个 CountDownLatch 实例调用对应方法即可。计数器不可逆一旦归零这个实例就永久处于门已打开状态后续再调用 countDown() 不会有效果再调用 await() 也会直接放行。它没有提供重置计数的方法。这些特性决定了它的适用边界适合一次性等待不适合重复使用。至于为什么这样设计以及哪些场景需要二次等待看到后面的源码分析和 CyclicBarrier 对比就明白了。1.3 什么场景不该硬用它我见过不少同学在需要反复协调多批任务的场景里硬用 CountDownLatch结果每个循环都 new 一个实例代码又笨又容易出错。比如有两批任务第一批 5 个第二批 8 个你当然可以创建两个 CountDownLatch 分别等待但整体代码复杂度会明显上升。如果任务批次数量不固定或者需要同一批线程重复协作那就该换思路了具体可以参考后面讲 CyclicBarrier 和 CompletableFuture 的对比。一句话总结CountDownLatch 最擅长的是一次性聚合等待。它不负责结果收集也不负责任务调度它只做一个最纯粹的事——计数与放行。2. 核心 API 与最关键的两个姿势await 与 countDown2.1 构造函数计数器从多少开始CountDownLatch 的构造函数只有一个public CountDownLatch(int count)这个 count 就是初始计数必须是大于等于 0 的整数。如果传负数直接抛 IllegalArgumentException。count 的真实意义是需要等待多少个事件完成所以事件数量得提前确定因为构造函数只执行一次后面没有任何 setter 能改初始值。这里有两个容易被忽略的小细节count 设为 0 时所有调用 await() 的线程会立刻返回不阻塞。这种用法业务里很少见所以别把 0 当成默认值来用。count 的值是事件数量不一定等于线程数量。同一个线程完成多个事件也可以多次调用 countDown()。比如一个线程负责处理 3 个批次那它完全可以 countDown 三次。2.2 await 与带超时的 awaitCountDownLatch 有两个等待方法public void await() throws InterruptedException public boolean await(long timeout, TimeUnit unit) throws InterruptedException第一个是无超时版本调用后线程一直阻塞直到计数归零或被中断。注意它和 Thread.sleep 一样会响应中断一旦线程的中断标志位被设置await 会抛出 InterruptedException把中断信号传播出去。第二个是带超时版本也是我在生产代码里更推荐用的最多等待指定的时间如果计数在这段时间内归零返回 true如果超时了计数还不为 0返回 false线程继续执行。这个返回值必须认真处理不能假装没看见。比如上面那个报表接口如果 5 个查询里有一个特别慢超过了预算时间await 返回 false 后接口不能直接返回残缺数据得走降级逻辑把超时的那个来源标记为暂时不可用。选超时时间也有讲究不能拍脑袋写一个看起来够用的固定值。最好结合上游服务的 P99 耗时和接口自身的 SLA 来定。比如你希望整个聚合接口在 1 秒内返回内部调用平均耗时 300ms、最慢 800ms那 await 的超时时间设成 900ms 就是比较合理的选择留 100ms 给主线程做后续拼装。2.3 countDown 的调用边界为什么必须在 finally 里countDown 方法签名很简单也不抛受检异常public void countDown()但真正的坑不在方法本身而在调用的位置。最典型的问题是任务执行过程抛了异常函数提前返回countDown() 根本执行不到主线程就一直阻塞在 await() 上整个流程卡死。这类问题在测试环境里不明显——通常任务都能成功——一旦线上偶发异常就变成接口超时、服务假死排查起来特别费劲。正确姿势是把 countDown 放进 finally 块executor.submit(() - { try { // 真正的业务逻辑允许抛异常 doSomething(); } finally { latch.countDown(); } });这样无论业务逻辑正常结束还是抛出异常计数都一定会被扣减主线程永远不会因为某个任务失败而无限期等待。我面试别人时也常问这个问题如果某个任务异常了你的 CountDownLatch 会怎样答不出 finally 的人多半都在线上栽过跟头。另外还要注意 countDown 的次数边界。任务是 5 个但代码 bug 导致同一个任务被执行了两次 countDown计数就会提前归零主线程提前放行数据不完整。所以业务逻辑要尽量保证一个事件恰好 countDown 一次不能多也不能少。这句话听起来简单在递归任务、批处理任务里要做到位并不容易。3. 三个实战场景覆盖 80% 的并发需求3.1 场景一主任务等待多个子任务完成这就是我开头说的报表聚合场景。需求很明确把 n 个独立任务丢给线程池主线程等全部完成后再继续。代码可以这样写int taskCount 5; CountDownLatch latch new CountDownLatch(taskCount); ExecutorService executor Executors.newFixedThreadPool(taskCount); for (int i 1; i taskCount; i) { int taskId i; executor.submit(() - { try { // 模拟调用远程服务耗时约 200-500ms Thread.sleep(ThreadLocalRandom.current().nextLong(200, 500)); System.out.println(任务 taskId 完成); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { latch.countDown(); } }); } latch.await(); executor.shutdown(); System.out.println(所有任务全部完成开始组装结果);有几个细节值得说明。第一线程池的线程数在这里设成 taskCount纯粹是为了演示生产环境里资源有限线程数通常会小于任务数任务会在队列里排队latch 等待的是5 个任务都真正执行完而不是5 个线程都创建完所以哪怕线程数只有 3这段逻辑也没问题。第二executor.shutdown() 放在 await 之后是为了让线程池里的任务先跑完、计数归零、主线程放行然后才关闭线程池避免线程池提前销毁导致排队任务被拒绝。第三如果你想让 JVM 正常退出shutdown 之后往往还需要 awaitTermination那是另一个话题这里不展开。3.2 场景二所有线程就绪后统一开跑这个场景在高并发压测和性能测试里非常常见你希望 10 个线程在同一个时刻开始执行而不是一个接一个地启动。用两个 CountDownLatch 可以优雅地实现int threadCount 10; CountDownLatch readyLatch new CountDownLatch(threadCount); CountDownLatch startLatch new CountDownLatch(1); for (int i 0; i threadCount; i) { new Thread(() - { // 1. 告诉主线程我已就绪 readyLatch.countDown(); // 2. 等待主线程发令枪 try { startLatch.await(); System.out.println(线程开始执行时间戳 System.currentTimeMillis()); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }).start(); } // 主线程等待所有线程就绪 readyLatch.await(); // 就绪后统一放行 startLatch.countDown();这个模式的核心在于 startLatch 初始计数为 1它扮演的不是逐格倒计时而是一个开关。10 个线程全部调用 await() 等待开关打开主线程确认所有人就绪后调用一次 countDown()开关打开所有线程同时被唤醒。readyLatch 则保证主线程不会在大家还没准备好时就提前按下开关。这种双门闩写法效果上接近 CyclicBarrier但用 CountDownLatch 可以更直观地控制等到什么时候才放行。实际压测时我要强调一点线程真正执行的起始时间并不会完全一致毕竟线程被唤醒后要经过操作系统的调度才会拿到 CPU。能做到的是从等待状态同时被释放而不是纳秒级对齐够用就好别强求完美同时。3.3 场景三多个初始化任务并行执行还有一个我经常用的场景服务启动阶段需要同时初始化数据库连接池、Redis 连接、消息队列生产者、远程配置中心客户端等一堆组件。这些初始化操作彼此没有依赖但如果串行执行启动时间会变得很长。思路和场景一几乎一样每个初始化任务完成后 countDown 一次主线程 await 到计数归零后再对外宣布服务启动完成。这段代码写出来后你会发现CountDownLatch 的价值不是让初始化本身变快而是让你优雅地把并行执行和等待收口分开代码结构清晰得多。值得留意的是启动期间的初始化任务一旦失败你并不希望整个服务闷头卡住。所以这里强烈建议用带超时的 await并且对返回的 boolean 做分支判断false 时记录哪个组件初始化失败给出有意义的告警信息再决定是重试还是退出。3.4 场景四把等待锁封装成通用组件时的注意事项如果你想把 CountDownLatch 的等待逻辑抽成公共组件我建议至少暴露两个方法一个是带超时的等待方法返回值交给调用方决定如何处理另一个是安全的 countDown 包装内部捕获异常并记录日志。这样可以让团队里的同学少踩很多坑也方便出现问题时从日志里定位到底是哪个环节没有执行到。组件里还要注意实例的隔离性。多个业务共用同一个静态 CountDownLatch 是非常危险的做法一个业务的 countDown 可能把另一个业务的计数提前清零造成数据混乱。每个独立的业务场景都应该 new 自己的实例并且把它的生命周期控制在业务方法内部。4. 从面试官视角看源码AQS 共享模式与 state 计数源码部分是面试里的硬核考点也是理解为什么 CountDownLatch 能实现多线程通知的关键。很多 Java 八股文里都会提到 CountDownLatch但只停留在使用方法层面。我现在从源码角度把内部机制拆开。4.1 CountDownLatch 的内部结构CountDownLatch 的源码不长核心是一个继承自 AbstractQueuedSynchronizerAQS的内部类 Syncprivate static final class Sync extends AbstractQueuedSynchronizer { Sync(int count) { setState(count); } int getCount() { return getState(); } protected int tryAcquireShared(int acquires) { return (getState() 0) ? 1 : -1; } protected boolean tryReleaseShared(int releases) { // 自旋 CAS 把 state 减 1 for (;;) { int c getState(); if (c 0) { return false; } int nextc c - 1; if (compareAndSetState(c, nextc)) { return nextc 0; } } } }看到这里就明白了CountDownLatch 把构造参数 count 直接存成了 AQS 的 state。AQS 是整个 JUC 并发包的基石ReentrantLock、Semaphore、ReentrantReadWriteLock 等工具都基于它构建。CountDownLatch 的状态只有两种方向大于 0 和等于 0所以它天然适合用 AQS 的共享锁模式来实现。4.2 await 和 countDown 分别做了什么await() 底层调用的是 AQS 的 acquireSharedInterruptibly(1)。它的逻辑是先尝试 acquireShared也就是执行 tryAcquireShared如果 state 是 0直接返回 1表示可以通行如果 state 不是 0返回 -1当前线程就被包装成节点放进 AQS 的等待队列进入阻塞挂起状态等待后续被唤醒。countDown() 底层调用的是 AQS 的 releaseShared(1)。它会执行 tryReleaseShared用自旋配合 CAS 把 state 减 1。注意每一次 countDown 只减一格多个线程同时调用时CAS 保证了同一时间只有一个线程能成功修改 state所以计数操作是线程安全的。当某一次减完之后 state 变成 0tryReleaseShared 返回 trueAQS 就会执行 doReleaseShared把等待队列里的线程逐个唤醒。这正是广播唤醒的实现原理当计数归零的时刻所有之前调用 await() 而阻塞的线程会被一起唤醒而不是只唤醒其中一个。理解了这一点你就不会对多个线程等待同一个门闩感到困惑了。4.3 为什么 CountDownLatch 是一次性的这个设计原因也可以从源码里直接找到答案。AQS 的 state 一旦减到 0没有任何入口把它重新设置回初始值。Sync 里只有构造时的 setState 和 tryReleaseShared 里的递减逻辑没有一个 reset 方法。计数归零后 tryReleaseShared 会直接返回 false不做任何修改tryAcquireShared 也永远返回 1await 一律直接放行。所以如果你需要分批次反复协调要么每次创建新的 CountDownLatch 实例要么改用 CyclicBarrier。CyclicBarrier 之所以可以循环使用是因为它内部维护了 count 和 reset 机制每次屏障点冲破后都会重置计数。这是两者在设计目的上的根本差异。小结一下这段源码分析CountDownLatch 用 AQS 的共享锁把计数归零和唤醒等待线程两个动作绑定在一起同时借助 CAS 保证并发安全。整段源码加起来几十行设计却非常精巧。这也是我建议每个做 Java 开发的同学至少读一遍 AQS 源码的原因——读懂了它你看 JUC 下的其他工具就像看同一套设计模式的不同变体。5. 与 CyclicBarrier、join、CompletableFuture 的对比5.1 一张表看透四种等待机制的差异很多初学者容易把 CountDownLatch 和 Thread.join() 搞混后来又冒出 CyclicBarrier 和 CompletableFuture选择困难症直接发作。我整理了一张对比表方便你按需选型。维度CountDownLatchCyclicBarrierThread.join()CompletableFuture.allOf()等待对象事件计数归零线程人齐线程结束异步任务是否可复用否是否每次新建等待时能否拿返回值否否否是主线程能否超时等待支持支持不支持支持是否适合线程池任务适合适合不适合适合典型场景一次性聚合等待多轮协作、循环赛跑串行启动顺序控制异步流水线、结果合并这个表里最值得关注的是第一行。Thread.join() 的语义是等这个线程死了它只能等 Thread 对象本身结束没法等待一个被线程池执行的任务CountDownLatch 等的是事件事件由 countDown() 来宣告不关心是哪个线程、什么时间完成的。理解了这个区别你就不会在 ExecutorService 里用 join 了因为线程池里的线程根本不让你 join你拿到的是 Future 而不是 Thread。5.2 什么时候只能选 CountDownLatch有几个场景CyclicBarrier 和 CompletableFuture 都不太合适优先考虑 CountDownLatch统一出发的并发压测。CyclicBarrier 的人齐后同时冲破也能做到类似效果但需要处理 reset 之后的状态而用 CountDownLatch 的两个实例反而更直白。初始化任务的聚合等待。你只是要等这些任务都完成不需要拿每个任务的返回值也不需要它们互相协作CountDownLatch 代码量最少。希望等待时引入超时控制且等待线程不止一个。CompletableFuture.allOf 也能等待但如果你想同时让多个独立线程都停在同一扇门等放行门闩模型更贴合。5.3 如果还想拿到返回结果怎么办CountDownLatch 本身不负责结果收集它是一个纯粹的同步信号工具。如果你除了等待完成还需要拿每个任务的返回值我的建议是直接用 CompletableFuture.allOf把每个子任务封装成 CompletableFuture再用 allOf(...).join() 统一等待最后逐个 get 结果。这样写出来的代码比线程池 CountDownLatch 共享容器的组合简洁得多类型上也更安全。不过也要说句公道话CountDownLatch 在需要手动控制放行时机的场景里仍然不可替代。CompletableFuture 的编排能力很强但它没有一个外部线程随时拨一下开关的机制。你没法让 10 个 CompletableFuture 任务同时停在一个起跑线等一个外部信号而 CountDownLatch 可以。工具之间本来就是互相补充不是谁淘汰谁。6. 实操避坑那些让我 debug 到怀疑人生的细节6.1 常见问题速查表我把自己和团队踩过的坑集中列出来每条都是真实事故的浓缩。现象根本原因解决方案主线程永久阻塞子任务抛异常countDown 没执行到把 countDown 放进 finallyawait 提前返回但数据不完整某个任务 countDown 了多次严格保证一事件一扣减必要时加日志超时返回 false 但业务不感知主线程直接忽略返回值对 false 做降级、重试或告警线程池任务跑不完任务里又套了等待互相等导致死锁检查任务间是否存在依赖避免任务内阻塞式等待JVM 无法退出线程池未关闭或非守护线程存活显式 shutdown 并等待终止同一实例在下一批任务里失效不了解不可复用的特性每批任务 new 一个或改用 CyclicBarrier6.2 排查思路先看线程栈再数 countDown遇到 CountDownLatch 相关的卡死问题我的第一反应永远是先抓线程栈。用 jstack 或者 Arthas 查看主线程停留在哪个方法上如果看到 java.util.concurrent.CountDownLatch.await 这样的栈帧再去看另外几个工作线程的栈。如果工作线程不在执行业务代码而是阻塞在别的资源上十有八九是死锁如果工作线程根本没被创建就得检查线程池有没有正常接受任务。一旦确认是计数器没归零还有一个很实用的排查手段在 await 超时返回 false 之后打印一下当前的 getCount 还剩几。这个数字能直接告诉你有多少个事件没完成再对着任务清单一个个核对问题就能快速收敛。我见过有人在 20 个任务的场景里排查了半天最后发现代码里任务数写死了 15有 5 个任务压根没提交到线程池——这种问题看一眼 getCount 就能定位。6.3 几个生产级建议最后给三个我认为很有价值的生产建议。第一所有 await 都尽量带上超时除非你能绝对保证事件一定会在可预期时间内完成。不带超时的 await 一旦碰上异常路径等于把整个应用的运行权交给一个可能永远不会发生的事件风险极高。第二CountDownLatch 实例的生命周期要和业务作用域绑定。如果实例被意外共享到多个互不相关的业务流程里一个业务的 countDown 可能扰乱另一个业务的计数造成诡异的数据不一致。每个独立的等待集合都应该有自己的实例不要图省事复用全局的。第三在高并发的批量场景里综合考虑 CompletableFuture 或 ForkJoinPool 的并行编排能力。CountDownLatch 并不是万能的它擅长的是等待不擅长收集结果、异常传递、组合依赖。工具选型时先想清楚需求到底是等待还是编排别拿一把锤子砸所有的钉子。写在最后一点个人体会搞明白 CountDownLatch 这个类我的收获其实远不止多背一个 API。真正改变我习惯的是那种把等待的开关抓到主线程手里的思路并行任务发起只是一瞬间难的是知道什么时候该收口。而 CountDownLatch 用一个小小的计数器把收口这个动作变成了可控制、可超时、可中断的精确操作。最后再分享一个小技巧如果你厌倦了在代码里写 try-finally 来确保 countDown 执行可以考虑把 CountDownLatch 的 countDown 原语封装进自己的任务包装类里比如提供一个 SafeCountDownTask在内部统一处理 finally 和异常日志。这种封装能让业务代码更干净也能最大程度避免团队成员重复踩坑。代码写得久了你会发现并发工具本身不复杂复杂的是让人人都在正确的位置调用它。