你有没有遇到过这种需求页面一打开要同时发三个接口去拉数据三个都返回了才允许渲染或者跑批处理的时候要先并发准备好几批素材最后才能合并计算。这种多个异步任务必须全部到达同一个汇合点才能继续往下走的逻辑Java里最直接的工具就是CountDownLatch。但我在项目里真正用起来之后发现每次手写都是那么几行样板代码漏掉一个分支线程就永远挂着排查起来又费时又费劲。用了几次我干脆把常用的动作收拢成了一个静态工具类——TaskLatchUtils。这篇文章就是把我的封装思路、核心API、落地场景和踩坑记录完整摊开适合正在纠结多个异步任务怎么优雅等待的开发者参考。1. 为什么我会写一个叫TaskLatchUtils的工具类1.1 从三版代码演变看痛点最早我接到一个需求某个页面需要同时请求用户信息、订单列表、优惠券三个接口三个接口全部返回后把数据聚合到一个ViewModel里展示。一开始我是这么写的Thread userThread new Thread(() - user api.getUser()); Thread orderThread new Thread(() - order api.getOrder()); Thread couponThread new Thread(() - coupon api.getCoupon()); userThread.start(); orderThread.start(); couponThread.start(); userThread.join(); orderThread.join(); couponThread.join();这个写法看起来简单但问题很明显join()对线程的启动顺序有隐式要求而且线程一旦出现异常join根本不会帮你做任何处理。更麻烦的是这个页面用的是线程池而Thread.join只对Thread对象友好配合ExecutorService时你得先拿到Future再逐个future.get()。Future.get本身能阻塞等待但如果任务内部是回调驱动的比如网络请求的CallbackFuture也接不住。后来我换成CountDownLatch代码变成了这样CountDownLatch latch new CountDownLatch(3); api.getUser(new CallbackUser() { Override public void onSuccess(User result) { user result; latch.countDown(); } Override public void onError(Exception e) { latch.countDown(); } }); api.getOrder(new CallbackOrder() { // 同样的样板 }); api.getCoupon(new CallbackCoupon() { // 同样的样板 }); latch.await(3, TimeUnit.SECONDS); // 聚合展示能用但每次都要new CountDownLatch、每个回调里写countDown、每个调用的末尾写await三个回调加起来将近二十行重复代码。而且回调的onSuccess和onError里各写一次countDown万一以后回调多出一个onCancel分支漏写就是线上事故。用了几次之后我把这些重复动作收进了一个静态工具类TaskLatchUtils业务侧代码就被压缩成了核心逻辑为主的样子。这就是这个工具类的由来——它不解决异步任务怎么执行只解决异步任务怎么安全、可靠地汇合。1.2 工具类该管什么、不该管什么封装之前我先定了三条边界不管线程池怎么建那是调用方的事工具类不给全局线程池不管任务怎么调度ExecutorService还是Callback都随你只管计数减一安全等待超时兜底这三件事这样的好处是工具类本身没有任何状态静态方法可以全局调用也不会因为项目里不同的线程模型而水土不服。这个定位在后面写代码时帮了大忙因为我只需要维护十几个方法而不是一套完整的任务调度框架。2. TaskLatchUtils的核心API与工作原理2.1 基于CountDownLatch的四个基础方法TaskLatchUtils的核心就是对CountDownLatch做门面封装。先说四个最基础的方法它们几乎覆盖了80%的使用场景。public final class TaskLatchUtils { private TaskLatchUtils() { } // 统一入口创建计数器 public static CountDownLatch create(int count) { if (count 0) { throw new IllegalArgumentException(count must be positive); } return new CountDownLatch(count); } // 安全减一latch为空时不抛异常减小偶发NPE排查成本 public static void countDown(CountDownLatch latch) { if (latch ! null) { latch.countDown(); } } // 无限等待谨慎使用 public static void await(CountDownLatch latch) throws InterruptedException { if (latch ! null) { latch.await(); } } // 超时等待返回true表示在超时前已经归零 public static boolean await(CountDownLatch latch, long timeout, TimeUnit unit) { if (latch null) { return true; } try { return latch.await(timeout, unit); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } } }这里有两个容易被忽略的细节。第一create里必须对count做校验。CountDownLatch的构造函数允许传入0传入0时await()会直接放行这在某些动态拼接任务数量的场景里会被误用。比如你根据接口返回的列表数量动态决定latch计数结果列表为空计数变成0所有等待瞬间通过——这往往不是你想要的。所以工具类这里直接限制为正数从源头排除这种边界。第二await捕获InterruptedException后必须重新设置中断标志Thread.currentThread().interrupt()。这是Java并发编程的老规矩捕获中断异常时不要吞掉中断状态否则上层代码判断线程是否中断时就会失效。很多初学者在这里直接return false导致调用方对线程状态产生误判。2.2 run()高阶封装把忘记countDown变成不可能基础方法解决了样板代码的问题但还没有解决漏写countDown这个更危险的问题。于是我做了一个更高的封装run()它的设计思路是把CountDownLatch的生命周期交给lambda同时把无论业务代码是否抛异常都要减一这个动作固定下来。inline fun T TaskLatchUtils.run( count: Int, crossinline action: (CountDownLatch) - T ): T { val latch CountDownLatch(count) return try { action(latch) } finally { // 这里不自动归零只负责在action异常时兜底避免调用方卡死 while (latch.count 0) { latch.countDown() } } }等等这个while循环把计数清零的做法其实是双刃剑。如果action在提交完所有任务之后正常返回了但某些任务还没执行完此时直接把计数清零就会让等待方提前通过数据缺失。所以我实际项目中用的不是自动清零而是另外提供一个组合方法把执行某个带返回值的逻辑finally中countDown绑在一起fun T safeCountDown(latch: CountDownLatch, body: () - T): T { try { return body() } finally { latch.countDown() } }这样业务方的每个回调都写成latch.safeCountDown(latch) { api.getUser { user it } }callback里哪怕抛了异常countDown也一定会执行。这个组合拳是我用下来觉得性价比最高的一招它把最容易出错的分支漏减问题降到了几乎不会发生。这里顺便说下原理CountDownLatch底层是AQS的共享锁countDown()对应releaseShared(1)当计数器减到0时会唤醒所有等待线程await()对应acquireSharedInterruptibly(1)只有计数器为0才能获得。因为底层是AQS所以countDown可以并发调用线程安全不需要额外操心。3. 三个最常见的落地场景与完整示例3.1 场景一并发拉取多个接口后聚合数据这是最经典的使用场景。假设一个Dashboard页面需要用户信息、订单总数、优惠券数量三个数据三个接口互相独立可以并发请求CountDownLatch latch TaskLatchUtils.create(3); AtomicReferenceUserInfo userRef new AtomicReference(); AtomicReferenceOrderStat orderRef new AtomicReference(); AtomicReferenceCouponStat couponRef new AtomicReference(); userService.getUserAsync(new CallbackUserInfo() { Override public void onSuccess(UserInfo result) { try { userRef.set(result); } finally { TaskLatchUtils.countDown(latch); } } Override public void onError(Exception e) { TaskLatchUtils.countDown(latch); } }); orderService.getOrderStatAsync(new CallbackOrderStat() { // 同样的结构 }); couponService.getCouponStatAsync(new CallbackCouponStat() { // 同样的结构 }); boolean done TaskLatchUtils.await(latch, 3, TimeUnit.SECONDS); if (!done) { // 超时记录日志用已有部分数据降级展示 } renderDashboard(userRef.get(), orderRef.get(), couponRef.get());这里我特意在onSuccess里又套了一层try-finally。原因很简单userRef.set(result)之后如果抛出任何异常finally里的countDown依然执行。很多人在回调里直接写userRef.set(result); latch.countDown();一旦set抛出异常countDown就丢了等待方永远等不到。超时时间怎么定我一般用预估P99响应时间乘以3再加1到2秒缓冲。比如接口P99是800ms那就等3秒左右。太短容易误伤正常慢请求太长则拖累UI响应。3.2 场景二Android中把多个回调转成挂起函数在Android Kotlin项目里协程已经是主流但第三方SDK往往还是老的Callback接口并不会为了你改成suspend。如果只有单个回调用suspendCancellableCoroutine很好处理但如果是多个回调齐了才算完成TaskLatchUtils依然能派上用场。suspend fun loadMergedConfig(): MergedConfig withContext(Dispatchers.IO) { val latch TaskLatchUtils.create(2) var remoteConfig: RemoteConfig? null var localConfig: LocalConfig? null sdk.fetchRemoteConfig { remoteConfig it TaskLatchUtils.countDown(latch) } sdk.fetchLocalConfig { localConfig it TaskLatchUtils.countDown(latch) } TaskLatchUtils.await(latch, 5, TimeUnit.SECONDS) MergedConfig(remoteConfig, localConfig) }这样写外部调用方不需要关心回调的存在直接val config loadMergedConfig()就能拿到聚合结果。需要注意的一点是withContext(Dispatchers.IO)让这个挂起函数跑在了IO线程所以阻塞等待不会卡主线程。如果忘了这一步挂起函数会被误认为不阻塞结果在Dispatchers.Main上直接await立刻引发ANR。协程场景还有一个更地道的替代方案用async加awaitAll。但前提是异步任务本身能落地为suspend函数。当SDK回调没法转成挂起、又不想为了转挂起引入太多中间层时TaskLatchUtils这种局部阻塞反而是最省事的折中方案。3.3 场景三并发执行多个前置检查并汇总失败原因这类场景往往出现在批量导入、发布前自检、或者启动引导流程里。多个检查项并发跑每个检查的结论是通过或失败最后统一汇总失败原因给用户。CountDownLatch latch TaskLatchUtils.create(3); ListString errors Collections.synchronizedList(new ArrayList()); executor.execute(() - { try { checkNetwork(); } catch (Exception e) { errors.add(网络检查失败: e.getMessage()); } finally { TaskLatchUtils.countDown(latch); } }); executor.execute(() - { try { checkStorageSpace(); } catch (Exception e) { errors.add(磁盘检查失败: e.getMessage()); } finally { TaskLatchUtils.countDown(latch); } }); executor.execute(() - { try { checkDependencyService(); } catch (Exception e) { errors.add(依赖服务检查失败: e.getMessage()); } finally { TaskLatchUtils.countDown(latch); } }); TaskLatchUtils.await(latch, 10, TimeUnit.SECONDS); if (!errors.isEmpty()) { showCheckReport(errors); } else { startNextStep(); }这里有几个细节我踩过坑errors必须用Collections.synchronizedList或者CopyOnWriteArrayList。多个线程同时add普通ArrayList会丢数据甚至数组越界。每个检查项内部必须自己catch所有异常否则一个检查项异常会直接打断线程池里该线程的后续逻辑而finally里的countDown虽然会执行但异常信息就丢了。检查项数量与latch计数必须一致。比如你提交了4个任务但只create(3)那么有一个任务跑完后计数刚好归零另一个任务之后才执行完等不到就继续了反过来create(4)但只提交3个任务则必然超时。4. 用TaskLatchUtils最容易踩的五个坑及排查链路这一节我按现象、原因、定位方法、修复方案的顺序写都是真实排查中总结出来的不是理论推演。4.1 坑一线程池太小任务还没执行就死等现象程序卡在await直到超时日志里只看到latch wait timeout但没有任何业务异常。有一次我并发拉取5个外部接口线程池核心线程数却只有2。线程池的2个核心线程被其中两个任务占住剩下的3个任务排队而这3个任务对应的countDown也迟迟不执行。那2个先执行的任务跑完也才把计数从5减到3永远到不了0。定位方法卡住时对进程做线程dump会看到核心线程正在执行业务代码而等待块之外还有任务在线程池队列里排队。或者直接在超时分支打印latch.getCount()如果计数大于已提交数基本可以判断有任务没开始跑。修复方案要么把线程池核心线程数调整为至少等于任务数要么改用newFixedThreadPool(n)这种正好匹配任务数的线程池。更稳妥的做法是提前算好线程数CPU密集型任务核心线程数设为CPU核数IO密集型设为核数的2倍及以上。4.2 坑二回调里有多个返回分支漏掉了countDown现象计数器偶尔不为0表现为这次好了下次卡住特别像随机偶发故障。典型代码长这样Override public void onResult(boolean success, User user) { if (success) { cache.save(user); return; // 这里countDown了下面还有没执行的分支 } if (user null) { return; // 这里忘了countDown } TaskLatchUtils.countDown(latch); }这种多分支的return是漏减的高发区。定位时先把超时时间调短在超时分支打印latch.getCount()你会发现计数比预期大然后逐行检查回调里每条分支路径。修复方案其实很简单不要在分支里到处写countDown而是用一个统一的工具方法让所有分支都经过finally。这就是前面提到的safeCountDown的价值。如果回调是第三方SDK固定的接口没法改那就自己在回调方法最外层包一层try-finally把原逻辑整体塞进去。4.3 坑三await放错位置让汇合变成了自杀现象程序直接卡死线程dump显示很多线程都在park状态。有一种很隐蔽的写法把await放到了提交任务之前CountDownLatch latch TaskLatchUtils.create(2); TaskLatchUtils.await(latch, 5, TimeUnit.SECONDS); // 先等了 executor.execute(() - { TaskLatchUtils.countDown(latch); }); executor.execute(() - { TaskLatchUtils.countDown(latch); });由于await在任务提交之前就阻塞了后面两行代码根本不会执行计数永远是2永远到不了0。这个错误刚看会觉得低级但在复用的公共方法里很容易出现某个方法先调用await再通过参数传入任务执行器去提交任务代码流转起来就乱了。定位方法看调用栈如果await发生的位置在所有任务提交逻辑之前基本可以判定是这个坑。修复方案就是先全部提交再统一等待把提交和等待分到两个阶段用代码注释把这两个阶段明确隔开。4.4 坑四异常被吞任务正常完成但结果缺失现象await正常通过了不超时但拿到的结果里有一部分是null。我在一个批量任务里见过这种代码try { result api.getXXX(); } catch (Exception e) { // 这里空catch } latch.countDown();异常被空catch吞掉后result保持默认值nullcountDown正常执行。从latch的角度看任务确实完成了但从业务角度看结果数据压根没拿到。定位方法不要只看有没有超时要检查每个任务是否有完整异常记录。我在工具类里建议的做法是每个任务捕获异常后至少把e写入一个并发集合聚合成失败列表。前端展示时也能明确告诉用户哪一项失败、失败原因是什么而不是所有项都静默通过。修复方案一行日志都不愿意写的话也要保证异常挂到结果对象上或者抛给上层统一定义失败态。总之countDown不能成为任务结束了的唯一信号它只代表任务执行流走到了末尾。4.5 坑五latch复用与计数错乱现象第二次使用同一个latch时等待瞬间通过或者完全卡死。CountDownLatch是不可复用的计数器一旦减到0就不会自动重置。有人图省事把latch存在成员变量里第一次用完没过多久又调用同一个实例结果第二次await时计数已经是0直接放行。更糟糕的是如果第一次没等到归零第二次再继续用这个latch计数还是那个没减完的值怎么等都不会通过。定位方法检查latch是不是每次新建。凡是看到private CountDownLatch latch;这种字段定义就要警惕。修复方案是让工具类的create()成为唯一创建入口业务侧强制每次任务组一个实例。这里给个小小的建议TaskLatchUtils支持传入外部latch是为了灵活性但正常业务里应该优先用run()或按方法内部创建latch的方式保证生命周期跟着方法走而不是跟着对象走。5. 什么时候不该用TaskLatchUtils替代方案对比与取舍5.1 四类方案横评TaskLatchUtils不是银弹。我把它和市面上主流的异步协作方案放在一起对比过各有各的适用场景。方案核心思路优点缺点CountDownLatch / TaskLatchUtils计数器阻塞等待简单直接、无额外依赖、易排查阻塞线程、不可复用、结果聚合要靠手写CompletableFuture任务依赖链回调编排非阻塞、组合能力强、自带异常链API学习成本高、复杂链路上排查难Kotlin协程 async/await结构化并发轻量、写法直观、取消机制完善需要协程环境、部分老代码迁移成本高RxJava zip数据流聚合操作符丰富、线程调度灵活项目包袱重、抽象层级偏高从解决多个任务汇合这个最小需求看CountDownLatch系的优势是心智负担小一眼就知道哪个数字没减完、为什么在等。CompletableFuture的allOf虽然也能做类似的事但如果你还要处理多个结果的聚合、异常恢复、超时分支CompletableFuture的链式调用确实更优雅可也更容易出现整个链路都挂在某个回调上的复杂排查场景。5.2 我的选型建议如果你维护的是老项目线程模型还是ExecutorService加一堆Callback那TaskLatchUtils是性价比最高的选择改动小、可读性好。如果你已经全面切到Kotlin协程并且第三方SDK都提供了suspend接口那就直接用async加awaitAll不要再引入CountDownLatch。比如coroutineScope { val deferredA async { api.getA() } val deferredB async { api.getB() } val (a, b) awaitAll(deferredA, deferredB) }这种写法比TaskLatchUtilswithContext(Dispatchers.IO)更地道因为协程的挂起不是阻塞线程单位资源下能撑起更多并发。还有一个混合思路值得推荐老代码层用TaskLatchUtils等SDK回调等完拿到结果后再用协程把结果包进suspend返回给上层。这样既不用重写老SDK调用又能让上层享受到协程的写法红利。我项目里有很多模块就是这么过渡的。6. 沉淀下来的几个使用习惯用TaskLatchUtils时间长了我养成了几个固定习惯不一定适合所有人但每次靠它们躲过了不少线上问题。第一个习惯是所有等待都必须有超时。哪怕是本地文件读取这种看起来不可能卡住的操作我也会给一个上限。无超时的await在测试环境通常没问题上线后一旦遇到极端情况线程就永久挂住连dump都救不回来只能重启。第二个习惯是超时分支里必打日志且带上getCount()。日志里如果光有一句timeout排查看不出到底是哪个任务没完成。带上latch.getCount()一眼就知道还剩几个没回来结合任务列表能快速锁定问题任务。第三个习惯是回调里先赋值再统一finally减一。顺序很重要。有人习惯先countDown再做结果赋值一旦等待方被唤醒后立即读取结果很容易读到还没写入的旧值造成竞态。先赋值、后释放保证等待方被唤醒时数据已经就位。第四个习惯是绝不在主线程或UI线程直接await。要么把等待逻辑放到withContext(Dispatchers.IO)要么放到子线程。这个我在前面的例子里反复强调因为很多年轻人写代码时只看逻辑通不通忽略了阻塞所在线程是谁。第五个习惯是把TaskLatchUtils当门面用。将来如果你决定把底层换成CompletableFuture或者协程只需要改工具类内部实现业务代码的调用点基本不用动。这也是我把create()、await()这些动作收拢成静态方法的原因——为了留一条往后替换实现的后路。最后再分享一个小技巧在多模块工程里给TaskLatchUtils加一个debug开关打开后每次countDown时打印当前计数和调用栈。这个开关平时关掉几乎零开销出问题时在测试环境开一下比看什么日志都直观。我的同事第一次看到那个开关的打印时还说了一句这玩意儿早该写进公司公共库了。就这么点事值得每个异步任务繁重的项目都来一套。
CountDownLatch封装实战：TaskLatchUtils让多异步任务等待更优雅
你有没有遇到过这种需求页面一打开要同时发三个接口去拉数据三个都返回了才允许渲染或者跑批处理的时候要先并发准备好几批素材最后才能合并计算。这种多个异步任务必须全部到达同一个汇合点才能继续往下走的逻辑Java里最直接的工具就是CountDownLatch。但我在项目里真正用起来之后发现每次手写都是那么几行样板代码漏掉一个分支线程就永远挂着排查起来又费时又费劲。用了几次我干脆把常用的动作收拢成了一个静态工具类——TaskLatchUtils。这篇文章就是把我的封装思路、核心API、落地场景和踩坑记录完整摊开适合正在纠结多个异步任务怎么优雅等待的开发者参考。1. 为什么我会写一个叫TaskLatchUtils的工具类1.1 从三版代码演变看痛点最早我接到一个需求某个页面需要同时请求用户信息、订单列表、优惠券三个接口三个接口全部返回后把数据聚合到一个ViewModel里展示。一开始我是这么写的Thread userThread new Thread(() - user api.getUser()); Thread orderThread new Thread(() - order api.getOrder()); Thread couponThread new Thread(() - coupon api.getCoupon()); userThread.start(); orderThread.start(); couponThread.start(); userThread.join(); orderThread.join(); couponThread.join();这个写法看起来简单但问题很明显join()对线程的启动顺序有隐式要求而且线程一旦出现异常join根本不会帮你做任何处理。更麻烦的是这个页面用的是线程池而Thread.join只对Thread对象友好配合ExecutorService时你得先拿到Future再逐个future.get()。Future.get本身能阻塞等待但如果任务内部是回调驱动的比如网络请求的CallbackFuture也接不住。后来我换成CountDownLatch代码变成了这样CountDownLatch latch new CountDownLatch(3); api.getUser(new CallbackUser() { Override public void onSuccess(User result) { user result; latch.countDown(); } Override public void onError(Exception e) { latch.countDown(); } }); api.getOrder(new CallbackOrder() { // 同样的样板 }); api.getCoupon(new CallbackCoupon() { // 同样的样板 }); latch.await(3, TimeUnit.SECONDS); // 聚合展示能用但每次都要new CountDownLatch、每个回调里写countDown、每个调用的末尾写await三个回调加起来将近二十行重复代码。而且回调的onSuccess和onError里各写一次countDown万一以后回调多出一个onCancel分支漏写就是线上事故。用了几次之后我把这些重复动作收进了一个静态工具类TaskLatchUtils业务侧代码就被压缩成了核心逻辑为主的样子。这就是这个工具类的由来——它不解决异步任务怎么执行只解决异步任务怎么安全、可靠地汇合。1.2 工具类该管什么、不该管什么封装之前我先定了三条边界不管线程池怎么建那是调用方的事工具类不给全局线程池不管任务怎么调度ExecutorService还是Callback都随你只管计数减一安全等待超时兜底这三件事这样的好处是工具类本身没有任何状态静态方法可以全局调用也不会因为项目里不同的线程模型而水土不服。这个定位在后面写代码时帮了大忙因为我只需要维护十几个方法而不是一套完整的任务调度框架。2. TaskLatchUtils的核心API与工作原理2.1 基于CountDownLatch的四个基础方法TaskLatchUtils的核心就是对CountDownLatch做门面封装。先说四个最基础的方法它们几乎覆盖了80%的使用场景。public final class TaskLatchUtils { private TaskLatchUtils() { } // 统一入口创建计数器 public static CountDownLatch create(int count) { if (count 0) { throw new IllegalArgumentException(count must be positive); } return new CountDownLatch(count); } // 安全减一latch为空时不抛异常减小偶发NPE排查成本 public static void countDown(CountDownLatch latch) { if (latch ! null) { latch.countDown(); } } // 无限等待谨慎使用 public static void await(CountDownLatch latch) throws InterruptedException { if (latch ! null) { latch.await(); } } // 超时等待返回true表示在超时前已经归零 public static boolean await(CountDownLatch latch, long timeout, TimeUnit unit) { if (latch null) { return true; } try { return latch.await(timeout, unit); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } } }这里有两个容易被忽略的细节。第一create里必须对count做校验。CountDownLatch的构造函数允许传入0传入0时await()会直接放行这在某些动态拼接任务数量的场景里会被误用。比如你根据接口返回的列表数量动态决定latch计数结果列表为空计数变成0所有等待瞬间通过——这往往不是你想要的。所以工具类这里直接限制为正数从源头排除这种边界。第二await捕获InterruptedException后必须重新设置中断标志Thread.currentThread().interrupt()。这是Java并发编程的老规矩捕获中断异常时不要吞掉中断状态否则上层代码判断线程是否中断时就会失效。很多初学者在这里直接return false导致调用方对线程状态产生误判。2.2 run()高阶封装把忘记countDown变成不可能基础方法解决了样板代码的问题但还没有解决漏写countDown这个更危险的问题。于是我做了一个更高的封装run()它的设计思路是把CountDownLatch的生命周期交给lambda同时把无论业务代码是否抛异常都要减一这个动作固定下来。inline fun T TaskLatchUtils.run( count: Int, crossinline action: (CountDownLatch) - T ): T { val latch CountDownLatch(count) return try { action(latch) } finally { // 这里不自动归零只负责在action异常时兜底避免调用方卡死 while (latch.count 0) { latch.countDown() } } }等等这个while循环把计数清零的做法其实是双刃剑。如果action在提交完所有任务之后正常返回了但某些任务还没执行完此时直接把计数清零就会让等待方提前通过数据缺失。所以我实际项目中用的不是自动清零而是另外提供一个组合方法把执行某个带返回值的逻辑finally中countDown绑在一起fun T safeCountDown(latch: CountDownLatch, body: () - T): T { try { return body() } finally { latch.countDown() } }这样业务方的每个回调都写成latch.safeCountDown(latch) { api.getUser { user it } }callback里哪怕抛了异常countDown也一定会执行。这个组合拳是我用下来觉得性价比最高的一招它把最容易出错的分支漏减问题降到了几乎不会发生。这里顺便说下原理CountDownLatch底层是AQS的共享锁countDown()对应releaseShared(1)当计数器减到0时会唤醒所有等待线程await()对应acquireSharedInterruptibly(1)只有计数器为0才能获得。因为底层是AQS所以countDown可以并发调用线程安全不需要额外操心。3. 三个最常见的落地场景与完整示例3.1 场景一并发拉取多个接口后聚合数据这是最经典的使用场景。假设一个Dashboard页面需要用户信息、订单总数、优惠券数量三个数据三个接口互相独立可以并发请求CountDownLatch latch TaskLatchUtils.create(3); AtomicReferenceUserInfo userRef new AtomicReference(); AtomicReferenceOrderStat orderRef new AtomicReference(); AtomicReferenceCouponStat couponRef new AtomicReference(); userService.getUserAsync(new CallbackUserInfo() { Override public void onSuccess(UserInfo result) { try { userRef.set(result); } finally { TaskLatchUtils.countDown(latch); } } Override public void onError(Exception e) { TaskLatchUtils.countDown(latch); } }); orderService.getOrderStatAsync(new CallbackOrderStat() { // 同样的结构 }); couponService.getCouponStatAsync(new CallbackCouponStat() { // 同样的结构 }); boolean done TaskLatchUtils.await(latch, 3, TimeUnit.SECONDS); if (!done) { // 超时记录日志用已有部分数据降级展示 } renderDashboard(userRef.get(), orderRef.get(), couponRef.get());这里我特意在onSuccess里又套了一层try-finally。原因很简单userRef.set(result)之后如果抛出任何异常finally里的countDown依然执行。很多人在回调里直接写userRef.set(result); latch.countDown();一旦set抛出异常countDown就丢了等待方永远等不到。超时时间怎么定我一般用预估P99响应时间乘以3再加1到2秒缓冲。比如接口P99是800ms那就等3秒左右。太短容易误伤正常慢请求太长则拖累UI响应。3.2 场景二Android中把多个回调转成挂起函数在Android Kotlin项目里协程已经是主流但第三方SDK往往还是老的Callback接口并不会为了你改成suspend。如果只有单个回调用suspendCancellableCoroutine很好处理但如果是多个回调齐了才算完成TaskLatchUtils依然能派上用场。suspend fun loadMergedConfig(): MergedConfig withContext(Dispatchers.IO) { val latch TaskLatchUtils.create(2) var remoteConfig: RemoteConfig? null var localConfig: LocalConfig? null sdk.fetchRemoteConfig { remoteConfig it TaskLatchUtils.countDown(latch) } sdk.fetchLocalConfig { localConfig it TaskLatchUtils.countDown(latch) } TaskLatchUtils.await(latch, 5, TimeUnit.SECONDS) MergedConfig(remoteConfig, localConfig) }这样写外部调用方不需要关心回调的存在直接val config loadMergedConfig()就能拿到聚合结果。需要注意的一点是withContext(Dispatchers.IO)让这个挂起函数跑在了IO线程所以阻塞等待不会卡主线程。如果忘了这一步挂起函数会被误认为不阻塞结果在Dispatchers.Main上直接await立刻引发ANR。协程场景还有一个更地道的替代方案用async加awaitAll。但前提是异步任务本身能落地为suspend函数。当SDK回调没法转成挂起、又不想为了转挂起引入太多中间层时TaskLatchUtils这种局部阻塞反而是最省事的折中方案。3.3 场景三并发执行多个前置检查并汇总失败原因这类场景往往出现在批量导入、发布前自检、或者启动引导流程里。多个检查项并发跑每个检查的结论是通过或失败最后统一汇总失败原因给用户。CountDownLatch latch TaskLatchUtils.create(3); ListString errors Collections.synchronizedList(new ArrayList()); executor.execute(() - { try { checkNetwork(); } catch (Exception e) { errors.add(网络检查失败: e.getMessage()); } finally { TaskLatchUtils.countDown(latch); } }); executor.execute(() - { try { checkStorageSpace(); } catch (Exception e) { errors.add(磁盘检查失败: e.getMessage()); } finally { TaskLatchUtils.countDown(latch); } }); executor.execute(() - { try { checkDependencyService(); } catch (Exception e) { errors.add(依赖服务检查失败: e.getMessage()); } finally { TaskLatchUtils.countDown(latch); } }); TaskLatchUtils.await(latch, 10, TimeUnit.SECONDS); if (!errors.isEmpty()) { showCheckReport(errors); } else { startNextStep(); }这里有几个细节我踩过坑errors必须用Collections.synchronizedList或者CopyOnWriteArrayList。多个线程同时add普通ArrayList会丢数据甚至数组越界。每个检查项内部必须自己catch所有异常否则一个检查项异常会直接打断线程池里该线程的后续逻辑而finally里的countDown虽然会执行但异常信息就丢了。检查项数量与latch计数必须一致。比如你提交了4个任务但只create(3)那么有一个任务跑完后计数刚好归零另一个任务之后才执行完等不到就继续了反过来create(4)但只提交3个任务则必然超时。4. 用TaskLatchUtils最容易踩的五个坑及排查链路这一节我按现象、原因、定位方法、修复方案的顺序写都是真实排查中总结出来的不是理论推演。4.1 坑一线程池太小任务还没执行就死等现象程序卡在await直到超时日志里只看到latch wait timeout但没有任何业务异常。有一次我并发拉取5个外部接口线程池核心线程数却只有2。线程池的2个核心线程被其中两个任务占住剩下的3个任务排队而这3个任务对应的countDown也迟迟不执行。那2个先执行的任务跑完也才把计数从5减到3永远到不了0。定位方法卡住时对进程做线程dump会看到核心线程正在执行业务代码而等待块之外还有任务在线程池队列里排队。或者直接在超时分支打印latch.getCount()如果计数大于已提交数基本可以判断有任务没开始跑。修复方案要么把线程池核心线程数调整为至少等于任务数要么改用newFixedThreadPool(n)这种正好匹配任务数的线程池。更稳妥的做法是提前算好线程数CPU密集型任务核心线程数设为CPU核数IO密集型设为核数的2倍及以上。4.2 坑二回调里有多个返回分支漏掉了countDown现象计数器偶尔不为0表现为这次好了下次卡住特别像随机偶发故障。典型代码长这样Override public void onResult(boolean success, User user) { if (success) { cache.save(user); return; // 这里countDown了下面还有没执行的分支 } if (user null) { return; // 这里忘了countDown } TaskLatchUtils.countDown(latch); }这种多分支的return是漏减的高发区。定位时先把超时时间调短在超时分支打印latch.getCount()你会发现计数比预期大然后逐行检查回调里每条分支路径。修复方案其实很简单不要在分支里到处写countDown而是用一个统一的工具方法让所有分支都经过finally。这就是前面提到的safeCountDown的价值。如果回调是第三方SDK固定的接口没法改那就自己在回调方法最外层包一层try-finally把原逻辑整体塞进去。4.3 坑三await放错位置让汇合变成了自杀现象程序直接卡死线程dump显示很多线程都在park状态。有一种很隐蔽的写法把await放到了提交任务之前CountDownLatch latch TaskLatchUtils.create(2); TaskLatchUtils.await(latch, 5, TimeUnit.SECONDS); // 先等了 executor.execute(() - { TaskLatchUtils.countDown(latch); }); executor.execute(() - { TaskLatchUtils.countDown(latch); });由于await在任务提交之前就阻塞了后面两行代码根本不会执行计数永远是2永远到不了0。这个错误刚看会觉得低级但在复用的公共方法里很容易出现某个方法先调用await再通过参数传入任务执行器去提交任务代码流转起来就乱了。定位方法看调用栈如果await发生的位置在所有任务提交逻辑之前基本可以判定是这个坑。修复方案就是先全部提交再统一等待把提交和等待分到两个阶段用代码注释把这两个阶段明确隔开。4.4 坑四异常被吞任务正常完成但结果缺失现象await正常通过了不超时但拿到的结果里有一部分是null。我在一个批量任务里见过这种代码try { result api.getXXX(); } catch (Exception e) { // 这里空catch } latch.countDown();异常被空catch吞掉后result保持默认值nullcountDown正常执行。从latch的角度看任务确实完成了但从业务角度看结果数据压根没拿到。定位方法不要只看有没有超时要检查每个任务是否有完整异常记录。我在工具类里建议的做法是每个任务捕获异常后至少把e写入一个并发集合聚合成失败列表。前端展示时也能明确告诉用户哪一项失败、失败原因是什么而不是所有项都静默通过。修复方案一行日志都不愿意写的话也要保证异常挂到结果对象上或者抛给上层统一定义失败态。总之countDown不能成为任务结束了的唯一信号它只代表任务执行流走到了末尾。4.5 坑五latch复用与计数错乱现象第二次使用同一个latch时等待瞬间通过或者完全卡死。CountDownLatch是不可复用的计数器一旦减到0就不会自动重置。有人图省事把latch存在成员变量里第一次用完没过多久又调用同一个实例结果第二次await时计数已经是0直接放行。更糟糕的是如果第一次没等到归零第二次再继续用这个latch计数还是那个没减完的值怎么等都不会通过。定位方法检查latch是不是每次新建。凡是看到private CountDownLatch latch;这种字段定义就要警惕。修复方案是让工具类的create()成为唯一创建入口业务侧强制每次任务组一个实例。这里给个小小的建议TaskLatchUtils支持传入外部latch是为了灵活性但正常业务里应该优先用run()或按方法内部创建latch的方式保证生命周期跟着方法走而不是跟着对象走。5. 什么时候不该用TaskLatchUtils替代方案对比与取舍5.1 四类方案横评TaskLatchUtils不是银弹。我把它和市面上主流的异步协作方案放在一起对比过各有各的适用场景。方案核心思路优点缺点CountDownLatch / TaskLatchUtils计数器阻塞等待简单直接、无额外依赖、易排查阻塞线程、不可复用、结果聚合要靠手写CompletableFuture任务依赖链回调编排非阻塞、组合能力强、自带异常链API学习成本高、复杂链路上排查难Kotlin协程 async/await结构化并发轻量、写法直观、取消机制完善需要协程环境、部分老代码迁移成本高RxJava zip数据流聚合操作符丰富、线程调度灵活项目包袱重、抽象层级偏高从解决多个任务汇合这个最小需求看CountDownLatch系的优势是心智负担小一眼就知道哪个数字没减完、为什么在等。CompletableFuture的allOf虽然也能做类似的事但如果你还要处理多个结果的聚合、异常恢复、超时分支CompletableFuture的链式调用确实更优雅可也更容易出现整个链路都挂在某个回调上的复杂排查场景。5.2 我的选型建议如果你维护的是老项目线程模型还是ExecutorService加一堆Callback那TaskLatchUtils是性价比最高的选择改动小、可读性好。如果你已经全面切到Kotlin协程并且第三方SDK都提供了suspend接口那就直接用async加awaitAll不要再引入CountDownLatch。比如coroutineScope { val deferredA async { api.getA() } val deferredB async { api.getB() } val (a, b) awaitAll(deferredA, deferredB) }这种写法比TaskLatchUtilswithContext(Dispatchers.IO)更地道因为协程的挂起不是阻塞线程单位资源下能撑起更多并发。还有一个混合思路值得推荐老代码层用TaskLatchUtils等SDK回调等完拿到结果后再用协程把结果包进suspend返回给上层。这样既不用重写老SDK调用又能让上层享受到协程的写法红利。我项目里有很多模块就是这么过渡的。6. 沉淀下来的几个使用习惯用TaskLatchUtils时间长了我养成了几个固定习惯不一定适合所有人但每次靠它们躲过了不少线上问题。第一个习惯是所有等待都必须有超时。哪怕是本地文件读取这种看起来不可能卡住的操作我也会给一个上限。无超时的await在测试环境通常没问题上线后一旦遇到极端情况线程就永久挂住连dump都救不回来只能重启。第二个习惯是超时分支里必打日志且带上getCount()。日志里如果光有一句timeout排查看不出到底是哪个任务没完成。带上latch.getCount()一眼就知道还剩几个没回来结合任务列表能快速锁定问题任务。第三个习惯是回调里先赋值再统一finally减一。顺序很重要。有人习惯先countDown再做结果赋值一旦等待方被唤醒后立即读取结果很容易读到还没写入的旧值造成竞态。先赋值、后释放保证等待方被唤醒时数据已经就位。第四个习惯是绝不在主线程或UI线程直接await。要么把等待逻辑放到withContext(Dispatchers.IO)要么放到子线程。这个我在前面的例子里反复强调因为很多年轻人写代码时只看逻辑通不通忽略了阻塞所在线程是谁。第五个习惯是把TaskLatchUtils当门面用。将来如果你决定把底层换成CompletableFuture或者协程只需要改工具类内部实现业务代码的调用点基本不用动。这也是我把create()、await()这些动作收拢成静态方法的原因——为了留一条往后替换实现的后路。最后再分享一个小技巧在多模块工程里给TaskLatchUtils加一个debug开关打开后每次countDown时打印当前计数和调用栈。这个开关平时关掉几乎零开销出问题时在测试环境开一下比看什么日志都直观。我的同事第一次看到那个开关的打印时还说了一句这玩意儿早该写进公司公共库了。就这么点事值得每个异步任务繁重的项目都来一套。
