1. 不只是“异步”那么简单：为什么需要编排
后端接口性能优化这件事，做久了你会发现一个非常现实的问题：单靠“异步”两个字解决不了真正的性能瓶颈。
举个例子，一个聚合查询接口要调用户服务、订单服务、营销服务、库存服务四个下游，写成串行调用，延迟直接相加，100ms × 4 = 400ms，用户明显感觉到卡顿。如果只是粗暴地把它们丢到线程池里“异步执行”，然后再手动get()结果等待，代码会退化成“异步的串行”，依然慢。更麻烦的是，如果第三个服务返回延迟，第四个服务的失败兜底、超时取消这些逻辑，用原生Future写起来根本不是人干的活。
CompletableFuture的出现真正把这个问题解决了，它不只是异步执行，而是异步编排。配合一个像样的线程池，它能让你用声明式的方式把多个异步任务组合起来，有依赖关系的串联、没有依赖关系的并联、多结果汇聚成一个结果、其中任何一个失败都能快速进入降级分支——这套组合拳，才是应对高并发场景的正解。
这篇文章围绕SpringBoot + CompletableFuture + 线程池这套组合，把高并发下的异步编排从原理到落地讲透。包含线程池参数怎么算、阻塞队列怎么选、CompletableFuture的核心API怎么用、完整场景怎么写、生产环境踩过的坑怎么避免，全部是我实际项目中验证过的方案，可以直接抄作业。
适合谁看：在业务里开始遇到接口变慢、扇出请求多的Java后端开发；想把“会异步”升级成“懂编排”的进阶者；以及面试前想系统梳理高并发异步这块知识点的人。
2. 整体设计思路：三个组件各自承担什么角色
2.1 为什么是“线程池 + CompletableFuture”组合
很多人用CompletableFuture的时候会图省事，直接用默认的ForkJoinPool。第一版接口确实跑通了，但上线一压测就露馅：默认池是公共池，CPU密集和IO密集的任务全挤在一起，局部流量一高，整个应用的异步任务全部互相拖累，甚至把ForkJoinPool的common pool线程耗尽，导致其他用CompletableFuture的地方集体卡顿。这就是我在生产环境踩过的第一个坑。
这套组合的分工，拆开看非常清晰：
| 组件 | 角色定位 | 核心职责 |
|---|---|---|
| SpringBoot | 容器与装配底座 | 负责Bean管理、配置注入、生命周期管控 |
| 线程池 | 异步任务的执行载体 | 隔离不同业务的执行资源，防止互相干扰 |
| CompletableFuture | 任务编排与结果聚合 | 处理依赖、并行、聚合、异常、超时等复杂逻辑 |
也就是说，线程池解决“谁去干活”和“干活的资源边界”问题，CompletableFuture解决“任务之间的安排顺序和组合方式”问题。SpringBoot在这里的价值是让线程池和业务代码的耦合变得非常松——通过配置类和@Bean注解，把线程池的创建收纳到IoC容器里，替换参数不用改任何业务代码。
2.2 方案选型的底层逻辑
在接触CompletableFuture之前，异步方案我用过好几种，踩过坑才明白每种方案的适用边界。
FutureTask + 手动线程池是最初级的。线程池负责执行，FutureTask拿到返回值。缺点非常明显：任务之间只要有依赖关系，你得在一个线程里阻塞等待另一个线程的结果，那就退化成伪异步；多个任务并行执行完成后要汇总，你必须一个一个future.get()等完一个再看下一个，浪费了好不容易做出来的并行能力。而且异常处理极其反人类，等个get()还要被ExecutionException包裹一层。这种方案适合“发出去就不管结果”的场景，但完全扛不住编排需求。
MQ做异步是重型方案。引入消息中间件，把任务改造成消息。削峰填谷能力确实强，但带来的成本也高：需要运维一套中间件，消息顺序性、重复消费、事务一致性这些都要处理。而且如果只是接口内部几个子任务需要合并结果，走MQ反而绕路——你没法简单地“发个消息再等结果回来”。MQ更合适的是两个独立系统间的异步解耦，不适合处理“单次请求内的异步编排”。
CompletableFuture + 自定义线程池是这两个极端之间的最优解。它只依赖JDK内置库，零额外依赖；部署形态不用变，原来怎么发布还怎么发布；重新审视业务发现，那种“一个请求要按需并行调多个服务、最后把结果汇总返回”的场景，CompletableFuture简直就是量身定做。成本低、见效快、又不需要改造架构，这就是选择它的根本原因。
2.3 异步编排能解决的典型场景
这套方案在真实业务里解决的最典型问题就是扇出场景——一个入口请求，后面需要拉取N个独立数据源，全部拉齐后再组装返回。
拿IM消息列表举例。用户进入会话界面，某条消息需要展示发送者昵称、头像、已读未读状态、引用消息内容、点赞信息。这些信息分散在用户服务、消息服务、社交服务里。如果串行，一条消息可能要多出几百毫秒延迟；如果用CompletableFuture，把这些查询任务全部并行发出去，再用allOf等所有任务完成，一下就把这个“每条消息多出来的延迟”摊平到单个请求里最慢的那一次调用上。
另外一个高频场景是预加载与聚合的配合。比如生成一条动态时，要同时检查内容安全（异步审核，不阻塞主流程）、生成缩略图、推送通知给关注者，还要实时返回“发布中”状态给用户。这种“主流程继续走，支线任务并行落地”的模式，用CompletableFuture的runAsync一脚油门就很舒服。
还有电商订单详情：查订单基本信息、查库存快照、查物流轨迹、查用户优惠使用情况，各自独立，最后拼成一个详情页返回。刚才第一次做这个场景的时候，把四个主流程从串行优化成并行+编排，接口P99耗时从480ms直接降到150ms以内。
3. 线程池配置：高并发下最容易翻车的环节
3.1 SpringBoot中定义线程池的正确姿势
SpringBoot的好用之处在于你可以把所有线程池配置集中在配置类里。下面的配置是我比较推荐的做法，把关键参数全部扔到application.yml里，方便后续调整而不改代码：
@Configuration @EnableAsync public class AsyncConfig { @Bean("bizThreadPool") public ThreadPoolTaskExecutor bizThreadPool() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(20); executor.setQueueCapacity(200); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix("biz-async-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(30); executor.initialize(); return executor; } }其中有两个点要特别说明。setWaitForTasksToCompleteOnShutdown(true)是我吃了亏之后才加上的，应用平滑关闭时必须等已提交任务执行完，不然应用重启瞬间，正在处理中的异步任务直接被强行中断，那个时间段里用户请求会异常惊悚。settAwaitTerminationSeconds(30)设个上限，防止任务一直卡住导致应用无法关闭。
还有一个小习惯：我用ThreadPoolTaskExecutor而不是直接new ThreadPoolExecutor，是因为Spring对前者做了更完善的Bean生命周期管理，而且它内置了线程池状态监控相关的钩子，配合Micrometer做指标采集很省事。如果你的场景更底层、需要更精细的控制，也可以直接用ThreadPoolExecutor，但要注意Spring容器关闭时默认不会帮你平滑收尾线程池。
3.2 核心参数的计算逻辑
线程池参数网上说法一堆，但落到自己业务上不能瞎拍脑袋。我一般遵循这个思路：
- 核心线程数（corePoolSize）：估算一下这类任务的平均耗时和每秒的请求量。比如任务平均耗时200ms，单线程能处理5个请求每秒，如果高峰期QPS是50，那核心线程数10就够覆盖正常流量。计算方式可以简单粗暴地按
峰值QPS × 单任务平均耗时来估算，比如50 × 0.2 = 10，再打1.2的冗余系数，定12~16。当然，线上监控要持续校准，不能定完就不管。 - 最大线程数（maxPoolSize）：想象一下突发流量冲过来，队列排满，必须开更多线程硬抗。最大线程数一般不是核心线程的简单倍数，而是要看机器资源。CPU核数按8核机器算，IO密集型的任务经常发生线程阻塞等待（比如远程调用、写MQ、读数据库），这时线程数可以开到核心线程数的2倍甚至更高；如果是CPU密集型计算任务，最大线程数设置为CPU核数+1或+2更合适。IO密集可以多开线程让它们在等待期间不闲着。
- 队列容量（queueCapacity）：这是最容易出问题的参数。排队的逻辑是：提交任务时，核心线程全部忙，就放进队列；队列满了，才创建非核心线程；非核心线程也全忙，队列依然满，才触发拒绝策略。一个常见的错误是核心线程数设小了，但队列容量却设得非常大（比如上万），导致流量进来时任务全在排队，响应时间直线上升。合理范围是让队列能在几十毫秒内“流动”，Task需要多久能流到线程上执行。通常我会配合核心线程数来算：核心线程数10，任务处理时间200ms，那1秒钟内核心线程能消费50个任务，假设60ms内任务必须被处理掉，那队列容量设为核心线程1秒消费总量的一半左右，取50~100比较稳，而不是400万那种无脑配置。
3.3 阻塞队列选型对比
队列这块最容易被新手忽略，但实际上线程池行为的整个分水岭就在这里。
| 队列类型 | 特性 | 适用场景 |
|---|---|---|
| ArrayBlockingQueue | 有界队列，必须在初始化时指定容量 | 防止任务无限堆积，适合大多数业务场景 |
| LinkedBlockingQueue | 默认无界，也可以指定有界 | 如果不限制容量，队列会无限增长，最终导致OOM |
| SynchronousQueue | 不存储任务，直接转交线程 | 适合任务执行非常快、不依赖排队缓冲的场景 |
生产环境我强烈建议别用默认的无界队列。你自己想一下：如果上游流量暴涨，几千个任务瞬间涌入，LinkedBlockingQueue默认是无界的，它们全部堆积在内存里，每个任务对象还带着上下文字段，内存直接顶爆，然后JVM开始疯狂GC，应用逐渐失去响应——这个故障我来回排查了很久才发现根因。所有线程池的队列，都要显式有界。
ArrayBlockingQueue的内部实现是循环数组，在并发下需要加锁保护入队和出队操作，LinkedBlockingQueue用的是两个锁分别管入队和出队。同样是1000容量，高并发读写下LinkedBlockingQueue的吞吐量通常略好一点。所以我会选有界的LinkedBlockingQueue实例——记住关键是有界。如果你的任务生命周期极短、到来速度极快但处理也极快，SynchronousQueue也是合理的，但那种情况下主线程可能会因为等交接而抖动，需要仔细压测。
3.4 拒绝策略不是“死路一条”
拒绝策略有四种，我用表格来对比一下：
| 策略 | 行为 | 适用场景 |
|---|---|---|
| AbortPolicy | 直接抛异常 | 必须保证每个任务不丢，宁可报错也不丢弃 |
| CallerRunsPolicy | 任务由提交线程（调用方）自己执行 | 宁可拖慢调用方，也不能丢任务 |
| DiscardOldestPolicy | 丢弃队列中最早的一个未处理任务 | 对部分任务时效性不敏感，可接受丢弃老任务的场景 |
| DiscardPolicy | 直接丢弃新任务 | 几乎不推荐，任务丢了没人知道 |
业务系统我最常用的是CallerRunsPolicy。原因很直接：在SpringBoot的Web场景，提交任务的是Tomcat线程，如果线程池已满，任务回退到Tomcat线程执行，等于“阻塞了当前请求但任务还在处理”。这种策略会让接口变慢，但起码不会丢数据。抢购、秒杀这种宁可丢弃部分请求的场景，DiscardOldestPolicy可能更合适，但你得接受老任务被踢掉的事实。
有一种情况需要注意：如果主线程是Web请求线程，一旦触发CallerRunsPolicy，任务在请求线程里跑，这个请求的响应时间就会被拉长。如果你对响应时间有硬性要求，而业务又允许丢数据，那AbortPolicy + 兜底日志 + 降级到前端重试，反而是更“老练”的做法——这个问题没有标准答案，每个系统怎么选取决于“丢任务”和“拖慢请求”哪一个代价更高。
4. CompletableFuture核心API与编排实战
4.1 为什么可以放心替换FutureTask
FutureTask核心功能是阻塞等待任务结果。CompletableFuture接口名字里的“Completable”就把定位写清楚了：任务可以被手动完成，可以在完成时自动回调对应动作。
最核心的差异在于依赖编排。FutureTask写法：
Future<UserInfo> userFuture = executor.submit(() -> userClient.getUser(userId)); Future<OrderInfo> orderFuture = executor.submit(() -> orderClient.getOrder(orderId)); UserInfo user = userFuture.get(); OrderInfo order = orderFuture.get();虽然两个任务确实是并行提交了，但第二行get()会先把线程卡住等订单结果，第一行get()可能还没返回，代码逻辑上还是串行等待的感觉。增加一个有依赖的任务，比如“拿到用户信息后再查他的最近订单”，FutureTask就只能再提交一个新任务，中途的线程切换、等待逻辑全部要自己写。CompletableFuture的thenCompose/thenCombine这类方法直接把这些关系描述清楚，可读性和维护性完全是两个级别。
CompletableFuture的另外一个优势是异常链处理。exceptionaly、handle、whenComplete等可以精确作用在某一个节点上，不会把一长串异常全部笼统地堆到最外层。这在“中间某个子任务失败了，后续依赖它的任务全都走降级”的场景里特别重要。
4.2 常用API的分类记忆法
API名字看起来多，但本质上是三类操作。
第一类：创建和启动任务
- supplyAsync：带返回值的异步任务
- runAsync：不带返回值的异步任务
- completedFuture：创建已完成结果的Future，测试时很常用
第二类：任务间的编排
- thenApply：拿到上一个阶段的结果，转换后返回新结果
- thenAccept：拿到上一个阶段的结果，消费但不返回新结果
- thenRun：上一个阶段完成后，执行另一个无返回值的动作
- thenCompose：上一个阶段结果依赖下一个阶段——适合处理“两级请求串行依赖”
- thenCombine：等两个阶段都完成了，合并结果
第三类：整体聚合与异常兜底
- allOf：等待所有任务完成
- anyOf：任意一个任务完成即返回
- exceptionally：仅当异常时执行，返回兜底结果
- handle：无论结果还是异常都会执行，返回新结果
记忆口诀：Apply是传递结果、Accept是消费结果、Run是跑个新任务、Combine是汇合两个、Compose是串接两个。
生活化类比：thenApply就像流水线加工——上一个人加工完的零件递给下一个工位继续加工；thenCombine是两个工位分别加工完成后，把两个零件拼装在一起；allOf是车间主任说要等所有工位完工才广播下班；exceptionally是某个工位出问题直接走废品处理通道。
4.3 典型编排模式：并行聚合与串行依赖
先看“并行聚合”模式，这也是引用最多的用法。三个互不依赖的子任务并行执行，全部完成后把结果聚合起来。调用链就三段：启动任务、allOf等待、join取结果。
CompletableFuture<UserInfo> userFuture = CompletableFuture.supplyAsync(() -> userService.getUser(userId), bizExecutor); CompletableFuture<List<OrderVO>> orderFuture = CompletableFuture.supplyAsync(() -> orderService.listOrders(userId), bizExecutor); CompletableFuture<List<CouponVO>> couponFuture = CompletableFuture.supplyAsync(() -> couponService.listValidCoupons(userId), bizExecutor); CompletableFuture.allOf(userFuture, orderFuture, couponFuture).join(); UserInfo user = userFuture.getNow(defaultUser); List<OrderVO> orders = orderFuture.getNow(Collections.emptyList()); List<CouponVO> coupons = couponFuture.getNow(Collections.emptyList());这里用getNow而不是get，是个经验之谈。getNow(默认值)在任务还没完成时会立刻返回默认值，不会阻塞。配合allOf().join()，正常情况下所有future都已经完成，getNow能直接拿到结果，但万一某个任务异常了，allOf的join()会抛出CompletionException，这个异常直接阻断整个方法。如果你的容忍度是“任务挂了但不能让接口挂”，就需要结合exceptionally处理。
再看“串行依赖”模式。比如“查用户基本信息→拿到用户ID再去查他的购物车”，这个串联关系就是thenCompose的舞台。
CompletableFuture.supplyAsync(() -> userService.getUserAuth(userId), bizExecutor) .thenCompose(authInfo -> CompletableFuture.supplyAsync( () -> cartService.getCartsByUserId(authInfo.getUserId()), bizExecutor )) .thenApply(carts -> { if (CollectionUtils.isEmpty(carts)) { return Collections.emptyList(); } return cartAssembler.toCartDetailVO(carts); }) .exceptionally(ex -> { log.error("查询购物车异常", ex); return Collections.emptyList(); });这个链路的优势是整个异常都能汇聚到尾部的exceptionally，任意一个环节抛错都会落入兜底逻辑。每个thenCompose内部新开的异步任务都显式指定了业务线程池，不会落回ForkJoinPool。
4.4 超时控制的正确姿势
CompletableFuture原生API没有超时控制，这是它不讨人喜欢的一点。orTimeout方法在Java 9才加入，如果你还在用Java 8（很多存量SpringBoot项目确实是），就需要动手包一层。
CompletableFuture<Result> future = CompletableFuture.supplyAsync(() -> remoteService.call(), bizExecutor ); try { return future.get(2, TimeUnit.SECONDS); } catch (TimeoutException ex) { log.warn("任务执行超时，返回降级结果"); return Result.fallback(); } catch (Exception ex) { log.error("任务执行异常", ex); return Result.fallback(); }关键点在于future.get(long, TimeUnit)超时后，get方法抛TimeoutException，但底层任务其实还在跑。如果任务本身是数据库查询或者RPC调用，它不会因为你get超时而被取消，线程池里那个线程还在干活。这就是为什么线程池参数要考虑任务实际被塞进队列但还没执行完的总量——一旦超时，任务不会消失，它依然占用着线程池资源。
所以更规范的做法是任务内部自带超时机制。比如调Redis、RPC时设置好客户端的超时时间，保证线程池里的线程不会无限期待。如果你用Dubbo、Feign，把超时配置调小一些，让依赖方超时来中断异常情况。
5. 完整实操：高并发下的订单聚合接口
5.1 场景设定与设计要点
我拿一个比较典型但不会太复杂的“高并发IM消息加载”场景来说。假设对接一个即时通讯模块，某个用户打开会话，业务接口需要一次性返回：
- 这个会话的基本信息（对方ID、会话类型、未读消息数）
- 最近一页的消息列表（消息ID、内容、发送时间）
- 每条消息的发送者信息（昵称、头像、在线状态）
- 消息中包含的富媒体附件信息（图片URL、文件大小等）
四个信息之间相互独立，唯一关联是它们都依赖“当前会话上下文”。最直观的串行方案需要调4次下游服务，但用异步编排可以做到“并行发起4项工作，全部完成后按主键组装起来”。
设计时先拆清楚依赖关系：会话基本信息是相对较轻的操作，用户信息要看缓存和DB，富媒体附件要看对象存储服务，这些链路延迟各不相同。如果等最慢的才返回，用户体验最优但系统实时性差，如果做一个“先返回基础数据，附件延迟异步加载推送”的折中方案，对消息流场景常常更合适。下面把实现讲清楚。
5.2 编排代码实现
首先，基于前面配置好的bizThreadPool，在业务Service里注入并编排任务：
@Service @Slf4j public class ConversationDetailService { @Resource(name = "bizThreadPool") private ThreadPoolTaskExecutor bizExecutor; public ConversationDetailVO getDetail(Long conversationId, Long currentUserId) { AgentCallContext context = AgentCallContext.current(); CompletableFuture<ConversationInfo> conversationFuture = CompletableFuture.supplyAsync( () -> conversationRepository.getInfo(conversationId), bizExecutor ); CompletableFuture<List<MessageVO>> messageFuture = CompletableFuture.supplyAsync( () -> messageRepository.listRecent(conversationId, 20), bizExecutor ); CompletableFuture<List<UserBriefVO>> userBriefFuture = conversationFuture.thenCompose(info -> CompletableFuture.supplyAsync( () -> userService.batchQueryUserBrief(info.getMemberIds()), bizExecutor ) ); CompletableFuture<Map<Long, AttachmentVO>> attachmentFuture = messageFuture.thenCompose(msgs -> { List<Long> attachIds = msgs.stream() .filter(m -> m.getAttachId() != null) .map(MessageVO::getAttachId) .distinct() .collect(Collectors.toList()); return CompletableFuture.supplyAsync( () -> attachmentService.batchGetAttachments(attachIds), bizExecutor ); }); try { ConversationInfo info = conversationFuture.join(); List<MessageVO> messages = messageFuture.join(); Map<Long, UserBriefVO> userMap = userBriefFuture.join(); Map<Long, AttachmentVO> attachMap = attachmentFuture.join(); return assembleResult(info, messages, userMap, attachMap); } catch (CompletionException ex) { log.error("加载会话详情异步编排失败，conversationId={}", conversationId, ex); throw new BizException("CONVERSATION_LOAD_FAILED", "会话详情加载失败"); } } }来看任务关系：conversationFuture和messageFuture是根任务，并行发出。userBriefFuture依赖conversationFuture的返回结果，attachmentFuture依赖messageFuture的返回结果，所以两者分别在根任务上接thenCompose。四个任务最终在try块里各自join取结果。这个设计比纯串行要快很多：假设四个下游分别耗时50ms、30ms、80ms、60ms，串行220ms，异步编排整体耗时约等于最长链路的80ms（conversation → userBrief），加上小量join开销，大约90ms。
这里有一个容易被忽略的点：AgentCallContext是自定义的上下文，比如traceId、userId。异步任务中要传递上下文信息，不能依赖ThreadLocal——因为线程池里的线程不是每次新建，任务A执行后ThreadLocal的值可能被任务B读到。这个问题在下面的常见问题章节单独展开。
5.3 异常与降级细节
上面代码中join()一旦抛出CompletionException，整个接口直接报错。业务上这样一刀切其实不够：有些数据（比如附件）挂了，不应该让会话信息和消息列表也拿不到。更好的做法是给每个子任务加exceptionally，让每个环节都有独立兜底。
CompletableFuture<Map<Long, AttachmentVO>> safeAttachmentFuture = attachmentFuture.exceptionally(ex -> { log.warn("附件信息加载失败，降级返回空", ex); return Collections.emptyMap(); });然后主流程用safeAttachmentFuture来join。这样附件服务崩溃不会拖垮整个会话详情。这种把“可以局部失败的逻辑”和“必须全部成功的主流程”分开设计的思维，才是异步编排真正考验经验的地方。
消息列表里有一个奇怪的边界情况：如果消息有20条，但只有3个人发了消息，userBriefFuture只需要查3个用户的资料，但这种批量查在用户服务那边可能不支持动态参数。如果用户服务只支持固定批量上限，就需要对用户ID做分组并发查，又是一层编排——我实际做完之后才意识到这个问题，代码里需要至少两个CompletableFuture互相配合。
5.4 上线前必须做的压测验证
写完代码不是万事大吉，线程池参数合不合理，必须用真实压测数据验证。我之前犯过的错是把核心线程数设为CPU核数，结果IO密集型的业务在压测时，线程数不够用导致任务大量排队，P99从50ms飙到400ms。
建议至少跑三组压测：
- 低水位：正常流量的一半，观察任务有没有排队
- 高水位：预估峰值的1.5倍，观察线程池是否扩容、队列占比是否合理
- 冲击：瞬时流量打满，观察拒绝策略是否生效、接口错误率是否在可控范围
同时开启线程池监控，用ThreadPoolExecutor自带的getPoolSize、getActiveCount、getQueue().size()等指标，再叠加Micrometer输出到Grafana。我个人的习惯是给线程池埋四个核心指标：活跃线程数、队列深度、拒绝任务数、任务处理耗时。拒绝任务数一旦出现非零，说明参数就需要调了。
6. 常见问题与排查技巧实录
6.1 任务异常被“无声吞掉”
用supplyAsync提交任务后，如果子任务抛出异常，主线程没有及时join，那么异常会暂时“挂”在future里，不会打印出来。等到有人join或者get时才会抛出CompletionException。如果你的代码只提交任务，没有join、没有exceptionally，异常就会直接消失得无影无踪，线上出问题都查不到。
排查思路：第一，所有异步任务必须有全局未捕获异常处理器，至少在任务的入口处log.error一把；第二，线程工厂设置一个自定义UncaughtExceptionHandler，兜底任何没有被捕获的异常；第三，关键链路必须使用exceptionally或handle做显式结果兜底。
6.2 ThreadLocal上下文在异步线程中丢失
这是异步化最容易踩的坑，没有之一。主线程里设置了traceId、用户ID等ThreadLocal，丢到线程池执行后，子线程里读不到。很多人就用try-finally在任务里手动传递，但代码乱成一锅粥。
我推荐的通用方案是使用包装器传递。实现一个TaskDecorator：
public class ContextPropagatingDecorator implements TaskDecorator { @Override public Runnable decorate(Runnable task) { Map<String, String> contextMap = AgentCallContext.current().getContextMap(); return () -> { AgentCallContext previous = AgentCallContext.current(); AgentCallContext.setContextMap(contextMap); try { task.run(); } finally { AgentCallContext.setContextMap(previous.getContextMap()); } }; } }然后在线程池初始化时调用executor.setTaskDecorator(new ContextPropagatingDecorator())。SpringBoot的ThreadPoolTaskExecutor原生支持TaskDecorator，非常方便。这样每次线程池执行任务时自动做了上下文的导入导出，业务代码无需关心上下文传递。注意finally中的清理很重要，不然线程复用时会串上下文。
6.3 allOf().join()的超时问题
前面写了用了allOf().join()做等待，但这个方法没有超时参数。如果某个子任务网络卡死一直不返回，整个请求就一直卡到下游超时。更规范的做法是循环调用每个future的get(timeout)，例如：
CompletableFuture.allOf(f1, f2, f3).get(2, TimeUnit.SECONDS);注意allOf返回的CompletableFuture调get带超时，效果是整体等待2秒超时。但前面说过的，超时只中断等待，不中断任务。因此还是要配合下游自身超时。如果get抛TimeoutException，你需要决定是放弃这个请求返回降级结果，还是继续等待后台任务完成再异步补偿——这个策略必须在设计阶段定清楚，不要等出了故障再去想。
6.4 线程池被“异步任务自己”拖垮
一个隐蔽的问题：业务线程池里的任务又调用了CompletableFuture提交新任务到同一个线程池。这种嵌套提交可能形成依赖：如果池子里线程都被外层任务占满，内层任务永远得不到执行，外层任务又在等内层结果，这就触发线程池饥饿死锁。
出现这种情况时，线程池活跃线程常年满池，队列里任务一动不动，接口超时，但CPU占用率不高——因为线程都在等。排查这个问题的关键是要区分“线程池没被合理使用”和“确实任务太多”。最好的应对是：不要让业务代码在一个线程池任务的执行体内继续往同一个池子提交任务。如果真的需要嵌套，就把不同层级的任务拆分到不同线程池。
6.5 阻塞队列用无界队列导致OOM
之前讲队列选型时强调过：LinkedBlockingQueue如果没传入容量就是无界，任务无限堆积时内存直线往上走，最后Old区被打满，触发Full GC甚至OOM。排查手段是发现GC频繁后先看线程池的队列深度，打印出来看一眼就知道是不是无界队列在作祟。
把队列改成有界后，配套要准备好拒绝策略的日志告警。我习惯给rejectionHandler里加一个Metrics记录，计数标记到监控面板，这样一旦触发就立刻在告警上看到。别等线上出大问题了才回头翻日志。
6.6 任务有父子依赖但allOf当普通集合用
有一种错误比较隐晦：代码写成先提交两个任务，然后一个任务要用另一个任务的返回值，却直接在这个任务里又submit了一个新任务，外部用allOf等着所有future，结果那个依赖任务其实已经提交了但不在allOf集合里，导致最终结果不完整。
解决方案：所有依赖关系必须在CompletableFuture类型链上表达，用thenCompose/thenCombine，而不是在方法内部再submit——内部再submit的方式会让编排关系不透明，无法统一管理。这条属于设计层面的约束，靠Code Review和代码规范约束比靠个人记性靠谱。
7. 异步线程池与SpringBoot的“隐藏协作”
很多人在SpringBoot里自定义线程池时，关注点只在参数上，但忽略了Spring自身很多机制是依赖线程上下文的。
事务问题是其中一个典型的“隐藏协作”。假如你在CompletableFuture的任务方法上标注了@Transactional，这个方法在线程池中被执行时，事务管理器需要从当前线程获取连接绑定。你期待的是整个异步任务开启一个新事务，但如果你只是想“等这个异步任务完成后再在主线程里查刚才它插入的数据”，注意事务的提交时机——主线程和异步线程可能是不同的数据库连接，隔离级别和事务可见性可能导致查不到数据。我的建议是：异步任务尽量不要在内部开事务，要么使用REQUIRES_NEW明确隔离，要么把事务设计在外层调用方。
Servlet异步化与请求上下文是另一个隐藏协作。如果你把Main线程返回给Tomcat、让CompletableFuture在后台慢慢跑，Session、请求参数、国际化这些都要考虑。Spring的RequestContextHolder默认跟线程绑定，异步线程里拿不到request。如果确实需要，可以在任务提交前先捕获请求上下文的快照，封装成一个上下文对象传进去。不要天真地以为Spring会自动帮你“迁移上下文”。
优雅关闭顺序也很容易忽略。应用关闭时，Spring容器先销毁bean，如果线程池还在跑任务，可能任务还没执行完线程池就被强制终止了。前面配置了WaitForTasksToCompleteOnShutdown，还要注意bean销毁顺序。我的做法是让线程池bean的destroyMethod填写shutdown，并且排序在业务Service之前。否则可能出现Service还在执行，但线程池已经挂掉的怪问题。
8. 线程池监控与压测验证
8.1 最小可行监控方案
不引入重型监控系统，仅基于Actuator + Micrometer就能实现可用的线程池指标采集。ThreadPoolTaskExecutor自身暴露很多信息，关键是把它接入Micrometer：
@Bean public MeterBinder threadPoolMetrics(@Qualifier("bizThreadPool") ThreadPoolTaskExecutor executor) { return registry -> { Gauge.builder("biz.pool.core.size", executor, ThreadPoolTaskExecutor::getCorePoolSize) .description("核心线程数") .register(registry); Gauge.builder("biz.pool.active.count", executor, ThreadPoolTaskExecutor::getActiveCount) .description("活跃线程数") .register(registry); Gauge.builder("biz.pool.queue.size", executor, e -> e.getThreadPoolExecutor().getQueue().size()) .description("队列长度") .register(registry); Gauge.builder("biz.pool.reject.count", executor, e -> rejectedCount.get()) .description("拒绝任务数") .register(registry); }; }前三项是现成的，拒绝数需要在自定义拒绝策略里计数。在Grafana上配一个面板：正常时活跃线程数是核心线程数的30%~70%；如果活跃线程顶到maxPoolSize且持续不回落，说明流量超过设计水位；如果队列长度在非高峰期还长期有值，说明核心线程数偏小。光看一个指标没用，综合起来分析才是排查的正确姿势。
8.2 压测中如何“逼出”配置缺陷
用JMeter或者wrk对接口压测时，要设置梯度场景：从低并发放到高并发，每档维持5分钟。只跑一次性压测很多时候测不出问题——线程池刚开始是cold状态，核心线程逐步创建，吞吐量会发生“爬坡缓”的情况。等跑十分钟以后线程稳定了，数据才是真实的。
建议每档压测期间都盯着线程池指标：如果队列在增长，核心线程数不够用，要观察线程是否向maxPoolSize方向扩容；如果达到maxPoolSize时队列还是溢出的，要考虑是不是任务执行时间过长，而不是简单调大线程数。任务耗时分布、下游耗时曲线和线程池指标放在同一个时间轴上观察，这个信息量比单独看线程池大得多。
我压测时还发现过一个有意思的现象：某些RPC客户端的连接池本身就小，线程池放大了并发后，下游连接成了瓶颈。这时再加大线程数反而加剧下游压力，接口恶化。异步化改造的瓶颈不一定在应用线程池，而在下游资源。排查时要有全局视角，不要头痛医头。
8.3 参数调优的循环迭代方法
没有一次到位的参数，只有持续迭代的参数。我的节奏是：
- 先按估算公式设一组初始参数
- 压测验证，看5个关键指标：TPS、P99、活跃线程、队列深度、拒绝数
- 分析瓶颈在这个链路的哪个环节（应用线程、下游连接、DB慢查询）
- 针对性调整，重跑压测
- 灰度上线，观察7天线上监控
尤其是核心线程数，不能只看QPS。如果任务内部的逻辑有锁竞争、共享IO，线程增加可能适得其反。这类问题压测数据才能暴露，靠经验猜容易翻车。
9. 回顾与个人体会
做异步编排这几年，我自己最大的体会是：这套方案真正的难点不在CompletableFuture API本身，它只是工具，关键在于你是否有能力把一个业务场景拆成“哪些必须并行、哪些必须串行、哪些可以容忍失败、哪些必须强一致”的模型。拆对了，代码自然会写得轻巧；拆错了，再漂亮的CompletableFuture链也会在真实流量下崩塌。
线程池这块则要随时保留敬畏心。无论你的参数设计得多合理，线上流量从来不讲道理。预留监控、设计好拒绝策略、保持队列有界，这些不是可选项而是必选项。如果你只记得一个建议，那就是：一定要在生产环境看到线程池的真实运转数据后再停止优化。
在后端开发的长期演进中，CompletableFuture+线程池这类方案依然会持续扮演重要角色，代码风格可能随着Java版本升级而微调，但拆解问题、并行与编排的思维方式，比API本身保值得多。希望这篇总结对你有实际帮助。
