做后端这几年被高并发折磨得最厉害的往往不是数据库而是那种“一个接口要串行调好几个服务”的场景。一个典型的 SpringBoot 项目里订单详情要查订单、查库存、查优惠券、查用户每个服务稳定 50ms串起来就是 200ms。压测一到 1000 QPSTomcat 线程全被这 200ms 的等待占满接口大面积超时CPU 却闲得很。CompletableFuture 加线程池做高并发异步编排就是干这个用的把相互独立的调用拆开并行执行再用编排原语把结果汇拢把 RT 从“多个 RTT 之和”压到“最慢的那个 RTT”。这篇文章我不打算讲太多理论重点放在 SpringBoot 里这套方案怎么落地线程池怎么配才不会被拖垮CompletableFuture 的常用编排怎么用最短代码写出来以及几个我实际踩过且线上真实发生的坑。适合正在写高并发接口、对 Future 理解还不深、想把异步编排用明白的 Java 工程师。看完可以直接照着抄。1. 为什么要做异步编排这笔账其实很好算1.1 串行等待是怎么拖垮接口的先算一笔直白的账。假设一个接口依赖四个上游服务每个服务平均返回时间都是 50ms。串行调用时接口 RT 约等于 200ms如果再算上网络抖动、超时重试实际 P99 可能到 400ms 往上。你看这 4 个线程在干嘛一个请求进来线程 A 占着等用户服务线程 B 占着等订单服务每个线程大部分时间都在阻塞。Tomcat 或你自己的业务线程池一共就那么多线程全被这种无意义的等待耗光新的请求只能排队。这就是高并发下最常见的瓶颈并发上不去不是 CPU 不够而是线程都被 IO 等待堵住了。那并行之后呢四个调用同时发出去接口 RT 从“四个 RTT 之和”变成“最慢的那个 RTT”理想情况下就是 50ms 多一点点。同样 200 个线程原来最多撑 1000 QPS这里只是粗略估算现在能撑 4000 QPS直接是一个量级的提升。用生活里的例子更好理解串行就像你点外卖时只有一家餐厅、一个厨师菜一道一道做并行就像同时让四家餐厅分别做四个菜你只需要等最慢的那家。CompletableFuture 没发明任何新东西它只是把“同时让四家餐厅开工”这件事表达得足够顺手。1.2 为什么选 CompletableFuture 而不是自己写多线程很多老项目用 ExecutorService 加 Future 也能做并行为什么还要换 CompletableFuture因为老的 Future.get() 是阻塞的而且表达不了“这个任务依赖上一个任务的结果”这种流程。举个例子你要查完订单才能拿订单里的用户 ID再拿用户 ID 去查用户信息这就是典型的串行依赖。用老 Future 写你得先 submit 一个任务get 到订单再 submit 一个任务get 到用户。中间只要有任何异常、超时代码就变得乱七八糟。更别说“查完订单和查完库存之后再把两个结果合起来做一件事”这种场景手写起来全是样板代码。CompletableFuture 的核心价值是编排不是并发。它把任务之间的依赖关系声明出来A 完成后把结果交给 B、A 和 B 都完成后汇合到 C、多个任务里任意一个成功就返回。这套东西在 SpringBoot 生态里用起来非常顺因为你只需要把线程池作为参数传进去剩下的逻辑全部是声明式的。2. 线程池配置先建地基再盖楼2.1 为什么不能依赖默认的 ForkJoinPool用 CompletableFuture 不传线程池它会走 ForkJoinPool.commonPool()。这个池听起来挺正规但它有非常明显的短板默认并发度是 CPU 核数减 1。也就是说一台 8 核的机器commonPool 的并行度只有 7。如果你的业务全是 IO 等待调用外部服务、查 Redis、查数据库这 7 个线程全部被阻塞后面所有任务全在排队。commonPool 是 JVM 进程级共享的。你项目里别的地方用了 parallelStream、别的第三方库也用了 commonPool大家都在抢这 7 个线程。其中一个任务被阻塞可能把旁边完全不相干的任务也拖死。高并发场景下线程池必须是隔离的、有名字的、参数可控的。页面查询用一个池、异步推送用一个池、定时任务用另一个池。各池互不影响出问题也好排查——线程 dump 里看到biz-io-3立刻就知道这是哪条链路的线程。2.2 线程数怎么定先算账再微调线程池参数不用拍脑袋可以按业务模型的公式推一个起点。对于 IO 密集型任务最常用的估算思路是看“同时在途任务数”假设你的服务单机目标 QPS 是 200单个任务平均耗时RTT是 80ms。那么同时处理中的任务数大约是 QPS × RT 200 × 0.08 16 个任务。也就是说线程池稳态需要约 16 个线程在工作。不过流量一定有毛刺还要留余量。实践里我一般按这个起点配参数值依据corePoolSize16稳态 16 个并发任务maxPoolSize32留 100% 余量应对突刺queueCapacity200允许一部分任务排队等待keepAliveTime60s闲置线程回收的合理时间threadNamePrefixbiz-io-出问题时能准确定位线程来源拒绝策略CallerRunsPolicy宁可让调用方线程执行不愿丢任务这只是起点不是终点。真实上线前我会用压测去校核如果线程池活跃数长期 0就说明配大了如果队列一直积压几百个任务就该扩池或加机器。线程池参数不是“配一次就完了”它应该跟随业务节奏动态调整。2.3 阻塞队列到底该选哪种热词榜里有人专门搜“线程池的阻塞队列选择”说明这事坑真的很多。ThreadPoolExecutor 执行逻辑是核心线程满 - 任务进队列 - 队列满 - 创建新线程到最大线程数 - 再满就走拒绝策略。所以队列类型直接决定了线程池的扩缩行为队列类型特点适用场景隐患SynchronousQueue不缓存任务直接把任务交给线程纯 CPU 密集型任务队列通常为 0容易频繁触发 maxPoolSizeLinkedBlockingQueue默认容量是 Integer.MAX_VALUE无界对任务丢失极其敏感的场景任务无限堆积导致内存溢出且 maxPoolSize 永远不起作用ArrayBlockingQueue有界队列容量可控大多数 IO 密集型业务需要配合合理的拒绝策略否则容易丢任务PriorityBlockingQueue有优先级排序希望重要任务先执行无法和 FIFO 保证完全一致排查时心智负担重我的真实建议是IO 密集型业务用有界队列。容量不要拍脑袋通常按“稳态并发数 16 × 5~10”来定也就是 100~200 之间。队列太大任务积压一个量级用户都等到超时了你才发现队列太小线程频繁创建销毁或直接进拒绝策略接口毛刺严重。至于拒绝策略线上我一般优先选 CallerRunsPolicy。为什么因为它最“诚实”线程池忙不过来时让打过来的调用方线程自己执行任务。任务不会丢代价是调用方线程被占用这个信号通过监控很容易发现。AbortPolicy 适合任务绝对不能丢但可以快速失败的场景DiscardPolicy 适合丢一些低价值任务也无所谓的场景比如打点上报。3. CompletableFuture 核心 API把编排语言讲明白3.1 提交异步任务supplyAsync 与 runAsync最简单的用法是给线程池提交一个任务异步执行完返回结果Executor executor bizExecutor; // 有返回值的异步任务 CompletableFutureInteger countFuture CompletableFuture.supplyAsync(() - orderService.countToday(uid), executor); // 无返回值的异步任务 CompletableFutureVoid logFuture CompletableFuture.runAsync(() - logService.record(uid), executor);这里有一个非常关键的细节第二个参数不传CompletableFuture 会默认走 ForkJoinPool.commonPool()。我在代码评审时见过很多次这种问题——开发写了supplyAsync(() - xxx)没传线程池本地测试一切正常到生产环境并发一高就卡死因为默认池太弱了。supplyAsync和runAsync的路数也不一样。前者代表“异步跑了之后我还要拿结果”后者代表“你只管执行我不关心返回值”。用supplyAsync和runAsync的边界别混用不然还要再包一层 CompletableFuture。3.2 串行编排thenApply、thenCompose、thenAccept串行任务的意思是A 完成之后拿 A 的结果去跑 B。CompletableFuture 提供了三个非常容易混淆的方法thenApply上一个阶段的结果进来经过同步转换返回一个新结果thenCompose上一个阶段的结果进来返回一个新的 CompletableFuture用于扁平化thenAccept上一个阶段的结果进来消费掉没有返回结果先看thenCompose为什么比thenApply更合适做串行异步// 错误示范嵌套 CompletableFuture CompletableFutureCompletableFutureUser badFuture orderFuture.thenApply(order - userService.findAsync(order.getUid(), executor)); // 正确写法扁平化串行 CompletableFutureUser goodFuture orderFuture.thenCompose(order - userService.findAsync(order.getUid(), executor));thenCompose相当于把两层包装摊平返回的还是一个 CompletableFuture 后续继续用thenApply、exceptionally都很自然。新手更容易犯的错是在thenApply里做耗时操作——记住thenApply里的代码默认是同步执行的如果里面调了外部服务一样会阻塞当前线程。真正想把“拿到结果后再异步查别的服务”表达出来就要用thenCompose。thenAccept用在哪比如异步等待任务完成之后把结果写进缓存不需要向上返回。注意它依然可能阻塞如果 CompletableFuture 是在线程池里完成thenAccept默认也在同一个线程执行所以里面也别放太重的操作。3.3 并行汇聚thenCombine 与 thenAcceptBoth两个独立任务要同时执行最后把两个结果合并成第三个结果这种场景用thenCombine。CompletableFutureInteger cartCountFuture CompletableFuture.supplyAsync(() - cartService.count(uid), executor); CompletableFutureInteger couponCountFuture CompletableFuture.supplyAsync(() - couponService.count(uid), executor); CompletableFutureTotalCount totalFuture cartCountFuture.thenCombine(couponCountFuture, (cartCount, couponCount) - new TotalCount(cartCount, couponCount));它的执行时机是两个任务都完成之后再执行合并函数。如果你只关心两个任务都完成不需要合并结果可以用thenAcceptBoth。我在真实项目里其实较少用thenCombine因为“两个任务合并”对应场景有限更多是“一堆任务并行最后汇总”那就要靠下面这个allOf。3.4 多任务汇聚allOf 与 anyOfallOf放一串 CompletableFuture 进去等它们全部完成返回CompletableFutureVoid。它本身不给结果所以汇合时要自己遍历取值ListCompletableFutureInteger futures userIds.stream() .map(id - CompletableFuture.supplyAsync(() - userService.queryUnread(id), executor)) .collect(Collectors.toList()); CompletableFutureListInteger resultFuture CompletableFuture .allOf(futures.toArray(new CompletableFuture[0])) .thenApply(v - futures.stream() .map(CompletableFuture::join) .collect(Collectors.toList()));这段代码是聚合场景的地基。注意最后用的是join()而不是get()区别是先讲清楚join()抛的是CompletionExceptionget()抛的是受检查的ExecutionException和InterruptedException。在 lambda 里用join()不用 catch 受检异常写起来更顺手代价是异常类型要被统一处理。anyOf用的场景相对少但它很擅长“去多个数据源查库存谁先返回用谁”这类快速响应场景CompletableFutureObject anyFuture CompletableFuture.anyOf(redisStockFuture, dbStockFuture, remoteStockFuture);注意一点anyOf只关心“谁先返回”对先返回的那个值做最早响应其余任务不会被取消还在后台跑这个务必要清楚别因为用了anyOf就以为没跑完的任务不占资源。4. 实战一个高并发聚合接口从 0 到 14.1 业务场景模型IM 未读数聚合我把这个场景落在热词里有人搜过的“高并发 IM”上因为它是再典型不过的异步编排场景。假设一个 IM 应用首页要展示四类数据会话列表未读总数来自 Redis好友申请未读数来自用户服务群消息未读数来自群服务关注动态数来自 Feed 服务这四个数据源互相完全独立单个平均耗时约 30ms最慢的群服务可能要 60ms。如果串行调用最理想也得 150ms实际可能要 200ms 以上。首页刷新频率高这个接口就是线上最大的热点之一。编排思路非常清晰四个任务全扇出并行去查每个任务配exceptionally兜底最终allOf扇入汇总。整个接口目标是把 P99 控制在 80ms 以内。4.2 完整代码与关键步骤逐段解释先看 SpringBoot 里的 Controller 怎么写RestController public class ImBadgeController { private final ThreadPoolTaskExecutor bizExecutor; public ImBadgeController(ThreadPoolTaskExecutor bizExecutor) { this.bizExecutor bizExecutor; } GetMapping(/im/badge) public ImBadgeVO getBadge(RequestParam Long uid) { // 1. 并行发起四个数据源查询 CompletableFutureLong sessionUnreadFuture CompletableFuture .supplyAsync(() - unreadService.sessionUnread(uid), bizExecutor) .exceptionally(ex - fallback(sessionUnread, ex)); CompletableFutureInteger friendReqFuture CompletableFuture .supplyAsync(() - friendService.friendReqUnread(uid), bizExecutor) .exceptionally(ex - fallback(friendReqUnread, ex)); CompletableFutureInteger groupMsgFuture CompletableFuture .supplyAsync(() - groupService.groupMsgUnread(uid), bizExecutor) .exceptionally(ex - fallback(groupMsgUnread, ex)); CompletableFutureInteger feedFuture CompletableFuture .supplyAsync(() - feedService.feedCount(uid), bizExecutor) .exceptionally(ex - fallback(feedCount, ex)); // 2. 等待所有任务完成 CompletableFuture.allOf( sessionUnreadFuture, friendReqFuture, groupMsgFuture, feedFuture ).join(); // 3. 汇合结果确保每个 Future 都有值 return ImBadgeVO.builder() .sessionUnread(safeGet(sessionUnreadFuture)) .friendReq(safeGet(friendReqFuture)) .groupMsg(safeGet(groupMsgFuture)) .feed(safeGet(feedFuture)) .build(); } private long fallback(String source, Throwable ex) { log.warn([im-badge] {} 查询失败使用兜底值 0, source, ex); return 0L; } private long safeGet(CompletableFuture? extends Number future) { try { return future.get(500, TimeUnit.MILLISECONDS).longValue(); } catch (Exception e) { log.error([im-badge] 等待任务结果超时, e); return 0L; } } }这段代码有几个重要细节第一步四个任务都是通过同一个bizExecutor提交的这就让它们的线程来自同一个池后续可以通过线程池监控统一观察。第二步exceptionally是逐个挂上去的不是挂在allOf之后。这是有讲究的它能把“单个数据源失败”挡在任务内部避免一个服务挂掉拖垮整个聚合接口。如果挂在整个链的末尾某个异常会把整个流程都带进异常分支。第三步allOf().join()无参版存在隐患——所有任务都完成才返回如果有任务没配超时可能会等很久。所以我习惯在每个 Future 取值时用带超时的get(500, TimeUnit.MILLISECONDS)再加一层保险这就是我写safeGet而不是直接join()的原因。4.3 超时控制与降级策略上面代码里future.get(500, TimeUnit.MILLISECONDS)是 JDK8 里最常见的超时手段。如果你用的是 JDK9还有更优雅的方式直接在 CompletableFuture 上设置超时超过时间自动完成并返回默认值CompletableFutureInteger feedFuture CompletableFuture .supplyAsync(() - feedService.feedCount(uid), bizExecutor) .completeOnTimeout(0, 500, TimeUnit.MILLISECONDS) .exceptionally(ex - fallback(feedCount, ex));completeOnTimeout的好处是超时后这个 CompletableFuture 会以默认值完成不会抛异常。如果你希望超时后直接让任务失败那用orTimeout更合适。两个方法都是 JDK9 引入的老项目升级时要留意。降级的核心思想特别简单数据源偶尔失败是常态聚合接口对单个数据源的敏感性要降到最低把每个子任务都变成“有兜底”的状态。这也是我在生产环境上线聚合接口前一定会做的一步——把服务降级演练直接做成常规压测项目。5. 高频翻车现场与排查避坑实录5.1 线程池自己等自己接口全部假死这是我线上遇到过最诡异的问题。现象是某个接口压测到一定程度所有请求全部卡住线程 dump 一看业务线程池里的线程全在CompletableFuture.join()等子任务子任务也提交到了同一个线程池但线程池线程全被“等待子任务”占满子任务永远排不上号形成死锁。最后排查出来的核心问题一句话就能说清在一个线程池线程内不要提交新的任务到同一个线程池然后又去 join 等待它完成。你等的那个子任务可能要排队而排队的位置已经被“正在等的你”占住了。当池里只有一个线程时必死无疑池里有多个线程时也可能因为排队任务过多而大面积饿死。规避方式有两种一是把“编排等待”放到 Controller 请求线程里做所有子任务都在池里并行执行在主线程里allOf().join()二是拆两个池编排池和业务执行池分离。实战里我更推荐前者职责更清晰。5.2 ThreadLocal 上下文丢失排查半天找不到原因异步任务一旦切到别的线程主线程的 ThreadLocal 就带不过去了。这个坑在高并发平台项目里特别致命——你前面的过滤器刚把用户 ID、traceId 放进 ThreadLocal异步任务里 log 就全打不出 requestId排查问题像大海捞针。SpringBoot 的ThreadPoolTaskExecutor提供了TaskDecorator可以在提交任务时把上下文塞回去。这是我项目里的标准配置ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setTaskDecorator(runnable - { MapString, String context TraceHolder.get(); return () - { try { TraceHolder.set(context); runnable.run(); } finally { TraceHolder.clear(); } }; });这还不够Spring 的Transactional在异步任务里默认也失效因为它同样依赖 ThreadLocal 里的事务上下文。如果你要在异步任务里做数据库写操作别指望注解请用编程式事务平台或者在提交任务前把事务准备好。这是很多人开发时意识不到、上线才炸的经典问题。5.3 异常被吞代码里却以为处理了CompletableFuture 的异常捕获有个反直觉的地方链式调用里某个环节抛异常如果后面没有exceptionally异常会一直藏在 CompletableFuture 里不打印、不抛给调用方。你只在主线程future.join()才知道出错了但如果主线程也没处理线上就是静默失败。我见过最离谱的案例是异步任务里分了两个分支一个分支成功另一个分支抛了 NPE日志里完全没有好几天后用户反馈某块数据总是不对最后翻代码才发现异常被吞了。这里我给三条经验每个异步任务的第一层就配exceptionally哪怕只是记录日志也要让异常有出口。日志里把业务标识打全——uid、订单号、traceId不然线上定位无从下手。不要在whenComplete里直接返回兜底值whenComplete不改链路上的结果很多人误以为里面做了兜底实际只是“看了一眼中途的值”。5.4 从哪看线程池的健康状态没有监控线程池配置就是盲人摸象。好在 SpringBoot 对线程池的监控非常方便不用额外引入复杂框架直接看核心指标指标方法看什么活跃线程数getActiveCount()长期满负载说明线程数可能偏低当前池大小getPoolSize()观察线程是否正常扩容队列积压getQueue().size()持续增长说明消费速度跟不上已完成任务数getCompletedTaskCount()对比增量判断吞吐变化拒绝任务数自定义 Count 变量这个最重要拒绝就是丢业务我给线程池写了个很简单的监控组件每 30 秒把上述指标打一次 WARN 日志队列积压超过阈值的加一条告警。这套东西不求花哨但排障效率高到爆一看日志就知道是不是线程池扛不住了而不是去猜上下游。写在最后的一点经验这套 SpringBoot CompletableFuture 线程池的组合我在生产环境维护了快两年最大的体会是异步编排带来的性能提升不是玄学而是可以量化的收益但代价是你必须对线程池和异常传播机制有足够的敬畏心。每次接入新场景我都会先画清楚编排关系再问自己三个问题子任务的线程池隔离好了吗每个子任务的超时和兜底配了吗异常有出口、上下文能传递吗分享一个后续值得关注的方向如果项目已经升级到 JDK 21可以试试虚拟线程它能大幅降低“线程阻塞等待 IO”的成本和 CompletableFuture 的编排思想并不冲突。但不管底层细节怎么变你在这套方案里学到的并发拆分思维、线程池容量规划方法、异常兜底策略在高并发服务里会一直有用。