如果你接手过一个接口越跑越慢的项目大概率会碰到同一个矛盾数据量不大但每个环节都卡在网络等待、文件写入、外部服务响应上。springboot 异步操作说到底是调整任务在线程里的执行顺序把耗时的活从请求线程中挪出去让主线程先解放出来。这篇文章我会从最基础的线程池选型讲起一直写到异常处理、事务边界、优雅关闭这些生产环境必须面对的问题适合正在用 Spring Boot 做后端接口、但又对异步任务心里没底的人。我不会上来就铺一堆配置代码因为异步操作里最容易出错的地方恰恰是对“异步到底改变了什么”没有概念。先把这个想清楚后面的代码只是顺势而为。1. “异步”解决的真实问题不是为了让代码更快而是为了把耗时挪走1.1 同步链路里最容易被拖垮的是调用线程HTTP 请求进来之后Spring MVC 会让 Tomcat 容器里的一个线程从头执行到尾。如果你的业务里有一段逻辑要调用第三方接口等对方返回平均要 200ms那这个请求线程就得在这 200ms 里干等着。并发一上来Tomcat 的线程池很快被打满新请求开始排队用户的直观感受就是接口越来越慢。异步操作的第一个价值就是把这类“等待型耗时”挪到另一个线程里去执行。请求线程只要能确认“任务已经交给后台了”就可以立刻返回。任务还是那 200ms但它不再占用前端请求线程的时间。这里要特别强调一个容易误解的点异步并没有让业务总耗时变短它只是让调用方不用再等这段耗时。如果业务要求必须拿到外部接口结果才能继续那你无论如何也省不掉这段等待。1.2 适合放到异步线程池里的业务特征我一般会拿三个特征判断一个任务适不适合异步化。第一调用方对任务完成时间不敏感。比如发送通知、清理临时文件、导出报表、生成缩略图这些场景用户只需要知道“你已经在处理了”并不需要在接口返回那一瞬间看到结果。第二任务本身存在大量阻塞等待而不是疯狂占 CPU。外部 HTTP 调用、数据库查询、读写磁盘都属于阻塞异步线程池能把等待时间填满让有限的线程同时做更多事。第三任务可以接受失败重试或延迟补偿。异步任务因为脱离了请求线程出错了不好直接反馈给用户所以必须要有日志、告警、重试这类兜底机制。反过来像“先扣库存再下单”这种强一致性链路异步反而会制造麻烦。订单创建的下一步依赖库存结果你强行把校验库存放进异步用户那边订单已经返回成功了后台才发现没库存这种体验比同步多点超时更糟糕。1.3 Spring Boot 异步操作的三种使用层次Spring Boot 里的异步操作可以粗略分成三个层次。最基础的是Async注解配合EnableAsync使用由框架帮你把方法调用扔进线程池。这是绝大多数项目最开始接触的方式简单但坑也不少后面我会专门讲。再进一步是使用CompletableFuture做任务编排。比如一批任务要全部跑完再汇总或者任意一个失败就整体快速失败只靠Async返回 void 是不够的需要拿到任务句柄去组合。最上层是消息队列方案比如把任务放到本地延迟队列或者外部消息队列里由独立消费者慢慢处理。严格说这不属于 Spring Boot 的异步范畴但它能解决线程池崩溃后任务丢失的问题。如果你的任务量已经大到影响了服务本身或者需要多实例分摊那应该尽早考虑消息队列而不是在应用内硬扛。我的建议是一个项目里不要把异步方案用得五花八门。能统一用Async加自定义线程池解决的就用这一套要编排、要保证可靠投递的再考虑消息队列。两套方案混在一起最后维护成本会很高。2. 先搭对线程池springboot 异步操作的性能上限取决于这里2.1 默认线程池能扛业务吗Spring Boot 确实会自动装配一个TaskExecutor但我的经验是生产环境基本不能直接依赖它。原因有几个。第一如果不做任何配置异步任务执行器的默认表现并不等于普通意义上的“有界线程池”。一旦任务提交速度超过处理速度任务会在队列里积压你会看到接口虽然返回了但后台任务越堆越多内存压力居高不下。第二默认线程池的线程名是task-1、task-2这种。出了问题去翻日志你很难一眼看出这段任务来自哪个业务模块。排查问题时线程名前缀是一个非常便宜但非常有效的线索。第三默认执行器的拒绝策略不一定符合你的业务预期。任务太多的时候是抛异常让调用方感知还是丢掉最旧的任务还是让调用线程帮忙执行不同业务需要的策略完全不同。默认设置通常是统一的一套用起来确实省事但省事的代价是遇到流量尖峰时行为不可控。所以我在实际项目里基本都会自定义一个ThreadPoolTaskExecutorBean把线程名前缀、队列容量、拒绝策略、优雅关闭参数全部显式声明出来。2.2 一个可落地的线程池参数推算过程配置线程池最忌讳的就是凭感觉写几个数字。核心线程数、最大线程数、队列容量这三者的关系完全取决于你的任务特性和目标吞吐量。考虑一个最简单的公式并发线程数约等于“每秒钟要处理的请求数 × 单个任务耗时秒”。这个公式来自排队论里的利特尔法则虽然背后是数学但理解起来很直观——要达到一定的吞吐就必须有足够的任务同时在跑。举个例子。假设你的异步任务平均耗时 300ms而业务目标是每秒处理 200 个任务。那么理想并发线程数就是200 × 0.3 60。再考虑线程切换开销、GC 停顿这类因素我会把核心线程数定在 60 到 70 之间最大线程数留出两倍左右的余量防止瞬时峰值把队列打穿。如果是纯粹的 CPU 密集型任务线程数反而不能太大一般按 CPU 核数加一设置就够了。因为跑再多线程也只是在争抢 CPU 时间片。如果任务主要做数据库查询、外部接口调用这类 IO 密集型任务可以尽量把等待时间换成并发线程数可以设得大一些。一个粗略的经验是CPU 核数 × (1 等待时间 / 计算时间)但实际很难算准所以更多时候我是靠压测拿数据而不是停在凭空估算。线程数还有一个容易被忽略的约束如果异步任务里要操作数据库那么线程数不能超过数据库连接池的上限。假设你的 HikariCP 连接池最大是 20线程池却配了 60高峰时 60 个任务同时去抢连接等待连接的线程反而挤占了后台线程资源。线程池参数必须和连接池、下游服务容量一起评估单看一个池子是看不出问题的。2.3 队列长度和拒绝策略别拍脑袋定队列在这套体系里承担的是缓冲作用当线程都在忙着新任务可以先进队列排队。问题在于队列大了可能把大量任务闷在内存里队列小了又容易触发拒绝策略。队列长度怎么定我习惯先看任务的“可承受延时”。假设一个异步通知任务用户最晚 10 秒内收到就可以接受任务本身耗时 300ms理论上队列里能容纳10 / 0.3 ≈ 33个任务再考虑流量抖动我会留出两到三倍缓冲比如队列容量 100。当然这只是初始设定真正定型还是要靠压测去观察队列积压和任务延迟。拒绝策略我做过一张对比放在项目里非常有用。策略行为适合场景AbortPolicy直接抛异常任务丢失不可接受的场景CallerRunsPolicy调用线程自己执行任务不想丢任务但会拖慢调用方DiscardPolicy静默丢弃对丢任务不敏感、允许延迟补偿DiscardOldestPolicy丢弃队列最旧任务只关心最新数据的场景比如实时状态刷新我自己用得最多的组合是核心线程数按常态流量算最大线程数是核心数的两倍队列容量不要太大拒绝策略选 CallerRunsPolicy。这样做的逻辑是万一真的扛不住了任务会回到调用线程执行至少不丢数据同时调用方会感受到压力链路能自然流量回退而不是线程池默默把任务丢掉。3. Async 的执行链路与生效边界3.1 启动开关、代理对象、Bean 作用域三要素Async能生效底层依赖的是 Spring 的 AOP 代理机制。你调用一个加了Async的方法时实际上调用的是代理对象代理对象会先拿到线程池把方法提交到线程池里执行。听起来简单但要让这个链路成立必须同时满足几个前提。首先需要在配置类或者启动类上加EnableAsync。这个开关负责往容器里注册异步执行的后置处理器。很多项目异步方法一直没生效第一步排查就漏了这个。其次异步方法所在的类必须是 Spring 管理的 Bean。如果自己new了一个对象出来Spring 根本不知道这个对象存在代理自然也就无从谈起。最后方法必须通过代理对象调用。这个约束最隐蔽因为它在代码层面几乎看不出区别我下面单独展开说。3.2 自调用为什么让异步静默失效自调用失效是Async最经典的坑没有之一。看下面这段代码Service public class OrderService { Async(notifyExecutor) public void sendNotify(String orderId) { // 真正耗时的推送逻辑 } public void createOrder() { // 业务逻辑... sendNotify(orderId); } }createOrder方法内部通过this.sendNotify()调用异步方法。问题在于this是原始对象不是代理对象。异步后处理器只拦截代理对象上的方法调用this调用等于绕过了代理方法就变成了同步执行。最气人的是它不会报错日志里好像也正常执行了只是完全没有达到异步效果。解决办法有两个方向。最简单的是把异步方法拆到独立的 Bean 里让需要调用它的业务类通过注入的方式去调用Component public class OrderNotifyService { Async(notifyExecutor) public void sendNotify(String orderId) { // 推送逻辑 } }另一个办法是在业务类里注入自身的代理对象绕开thisService public class OrderService { Autowired private OrderService self; public void createOrder() { // 通过代理调用异步才能生效 self.sendNotify(orderId); } }我更喜欢拆独立 Bean 的方案因为职责更清晰也不容易在后续维护中一不小心又踩回this调用。3.3 返回值为 void / Future / CompletableFuture 时的差异Async方法的返回值直接决定了调用方能拿到的信息。如果方法是void调用方提交完任务就完事不关心执行结果。异常会交给异步任务异常处理器处理调用方线程完全感知不到。这是最省心、也最容易丢异常的写法。如果方法返回FutureT调用方可以future.get()等待结果或者future.isDone()判断是否完成。Spring 提供了AsyncResult来承接返回值。Async(notifyExecutor) public FutureString pushAndGet(String target) { boolean ok doSend(target); return AsyncResult.forValue(ok ? success : fail); }如果方法返回CompletableFutureT就可以做更灵活的任务编排比如等所有任务都完成再汇总。返回时要用CompletableFuture.completedFuture(result)包一层因为方法体本身已经跑在线程池里框架处理这个返回值时需要一个成型的 Future 作为结果载体。Async(notifyExecutor) public CompletableFutureBoolean pushOne(String target) { boolean ok doSend(target); return CompletableFuture.completedFuture(ok); }写到这里要提醒一句很多人以为 Async 方法里配合CompletableFuture.supplyAsync等于双重异步实际上没必要。方法体已经在你的目标线程池里执行了再内部开一个线程池只会多一层上下文切换和资源争夺。想要编排把Async方法的返回值设为CompletableFuture在调用侧组合这些 Future 就够了。4. 一个批量推送场景的并行编排实战4.1 把一批任务拆给多个线程并行处理先上一个完整的批量推送场景。假设业务是给一批用户发送个性化通知目标用户有 200 个单个用户推送耗时约 200ms。如果在一个线程里串行执行总耗时是200 × 0.2 40秒这个速度在用户体感上没法接受。线程池的目标就是把这 200 个任务拆开并行执行。核心线程数按前面提到的方法推算比如 40 左右。任务提交时用Async方法逐个返回CompletableFutureBoolean然后统一收集。ListCompletableFutureBoolean futures targetUsers.stream() .map(user - pushService.pushOne(user)) .collect(Collectors.toList());这里有个细节pushService.pushOne(user)只是提交任务不会真等推送完成才返回。它返回的是一个 Future 对象真正的推送逻辑已经进入了线程池。所以收集 Future 列表的速度非常快耗时不会随着目标用户数线性增长。4.2 全部完成后再汇总的正确写法如果业务要求所有通知都推送完成后才能返回统计结果可以用CompletableFuture.allOf。CompletableFutureVoid allDone CompletableFuture.allOf( futures.toArray(new CompletableFuture[0]) ); allDone.get(30, TimeUnit.SECONDS); long successCount futures.stream() .filter(future - future.join()) .count();allOf的作用是等所有 Future 都完成。注意allDone.get(30, TimeUnit.SECONDS)一定要设置超时否则线程池一旦被拖垮调用线程会无限等下去。等全部完成之后再遍历每个 future用join()取结果。join()和get()的区别要拎清楚。get()会抛出受检异常强制你处理join()不抛受检异常但会包装成CompletionException。在这个场景里我建议用join()因为异常已经统一在上一层的get()超时控制里兜底了后续遍历只关心结果值。4.3 想要快速失败该怎么组合还有一种场景是所有任务里有一个失败整体就不等了。比如批量生成订单其中一个生成失败你再等剩下几个完成没有意义。CompletableFuture.anyOf能在第一个完成的 Future 触发时就返回但这不完全是“快速失败”因为如果第一个完成的是成功任务你还得继续等。更精确的做法是先给每个子任务挂上异常处理CompletableFutureBoolean anyFail CompletableFuture.allOf( futures.toArray(new CompletableFuture[0]) ).handle((res, ex) - { if (ex ! null) { // 记录失败原因 return false; } return true; });调用侧拿到的anyFail在整体异常时变 false正常时变 true。但要注意即使调用侧提前返回了“失败”结果后台已经在执行的那些任务不会自动停止线程池也不会因此取消任务。真要具备“一个失败就取消其他任务”的能力得用CompletableFuture.completeExceptionally配合自定义编排复杂度会明显上升。我个人的建议是大多数业务并不需要这么激进的取消语义能抓住异常、能记录日志、能及时返回失败已经够用了。5. 事务、上下文、异常异步之后最容易翻车的三个地方5.1 Transactional 和 Async 叠加时的真实边界Async和Transactional一起出现时很多人默认它们能完美配合但实际行为完全不同。事务的本质是 ThreadLocal 绑定连接资源。Spring 的事务管理器在进入事务方法时会把连接绑定到当前线程。而Async会把整个方法的执行挪到另一个线程里所以事务只会在任务线程内部建立和提交。调用方线程在方法返回前根本不知道后台事务提交了没有。这带来的直接影响是你不能用异步方法去保证“主流程事务提交后再做某事”。比如用户下单成功后要发通知如果你在主事务里调了一个异步发送通知的方法通知方法自己开新事务这个新事务的提交时机你是把握不住的。更要命的是如果异步方法里事务回滚了主流程已经成功返回给用户了。正确的姿势是把“事务内要干的事”和“事务后要干的异步事”拆开。主流程先保证自己的数据落库并提交然后通过事务同步器在提交后触发异步任务TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCommit() { notifyService.sendNotify(orderId); } });这样至少能保证通知只在主事务提交之后才发不会出现订单还没提交、通知先出去这种诡异情况。5.2 ThreadLocal 与链路追踪上下文跨线程传递异步任务在线程池里运行最直接的问题是拿不到主线程里的 ThreadLocal 数据。典型的例子是用户身份信息和日志链路追踪 ID。在同步调用里你可以直接在业务代码中读取当前登录用户。但任务一旦进入线程池它跑在另一个线程上那个线程里的 ThreadLocal 是空的。你在异步方法里读取用户只能读到 null然后整条链路就出问题了。解决方案是在提交任务时把上下文快照一并传递出去。最通用的做法是包装Runnable和Callablepublic class ContextAwareExecutor extends ThreadPoolTaskExecutor { Override public T FutureT submit(CallableT task) { MapString, String context MDC.getCopyOfContextMap(); return super.submit(() - { MapString, String old MDC.getCopyOfContextMap(); MDC.setContextMap(context); try { return task.call(); } finally { if (old null) { MDC.clear(); } else { MDC.setContextMap(old); } } }); } }这里我用日志框架的 MDC 做示范它的作用就是跨线程传递日志上下文。用户信息、traceId 这类数据也可以用同样的快照恢复思路处理。注意一件事不要直接在线程池回调里修改原来线程的对象要把数据复制一份再带过去否则并发执行时会互相污染。5.3 异步任务的异常处理与兜底策略Async的 void 方法异常处理是重灾区。如果你不自己声明异常处理器Spring 默认只会把异常打印到日志里很多时候根本不知道任务已经失败了。实现AsyncUncaughtExceptionHandler可以统一兜底Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (throwable, method, params) - { log.error(异步任务执行失败, method{}, method.getName(), throwable); }; }返回Future或CompletableFuture的方法则不同异常会被封装进 Future调用方要么在get()时拿到异常要么在join()时收到CompletionException。这个异常处理通道比 void 方法可控得多所以我更推荐异步方法返回CompletableFuture至少在调用方还有机会感知异常。但兜底不能只靠捕获异常。建议给每个异步任务带上业务编号和幂等键。既然任务脱离了请求线程失败后没人提醒用户你就需要靠日志里的业务编号去恢复现场。重试要做但不要无限重试最多三次每次间隔递增否则下游服务会被你的重试打垮。6. 上线前要补的配置优雅关闭与线程池监控6.1 容器关闭时如何让在跑任务安全收尾服务发版、重启的时候如果线程池里的任务还在跑强制退出会导致任务后半段丢失。数据库操作可能执行到一半外部通知也可能刚发了一半。ThreadPoolTaskExecutor提供了两个非常关键的参数executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(60);第一个参数表示关闭线程池时等待已提交的任务执行完第二个参数设置最大等待时间。我一般设置为 60 秒超过 60 秒还没执行完的任务就只能按失败处理了。这里要理解等待的粒度。waitForTasksToCompleteOnShutdown(true)等的是已经提交到线程池的任务不包括任务提交后被放进队列继续等待的后续任务。如果你的任务排队特别深60 秒可能只够把正在执行的任务跑完队列里积压的任务还是要丢。所以优雅关闭并不能解决所有问题它只是让正常发版时尽量少丢任务。真正可靠的方案还是要给任务加持久化标识发版前确认积压程度必要时先摘流量等队列清空再重启。这个流程虽然麻烦但它能把不确定性降到最低。6.2 线程池健康指标怎么采集线程池配置得再好不监控等于盲跑。我见过太多线程池被慢慢耗尽日志里全是任务延迟告警查出来才发现队列早就爆了。采集指标不需要引入一套特别复杂的监控系统可以先从本地日志开始。用一个定时任务每半分钟打印一次线程池关键指标ThreadPoolExecutor pool executor.getThreadPoolExecutor(); log.info(active{}, poolSize{}, queueSize{}, completed{}, pool.getActiveCount(), pool.getPoolSize(), pool.getQueue().size(), pool.getCompletedTaskCount());观察一段时间之后你会对正常的活跃线程数和队列积压量有感觉。一旦发现队列持续上涨、活跃线程贴到最大线程数说明线程池已经饱和需要扩容或者排查下游瓶颈了。如果项目已经接了监控系统优先把activeCount、queueSize、rejectedCount这几个指标暴露出去配上告警。拒绝次数是最需要盯的它说明业务曾经出现过任务被丢弃或被迫回压的瞬间而日志里根本不会自然浮现。6.3 一个排查异步不生效的完整思路最后给一张排查清单当你怀疑Async没生效时按这个顺序查基本都能定位。第一步确认配置类上有EnableAsync。没有它后面一切都是白费。第二步确认异步方法所在的类被 Spring 管理不是自己 new 出来的对象。第三步确认调用方式是跨 Bean 调用。如果是类内部this.send()立刻拆 Bean。第四步确认异步方法是用public修饰的。CGLIB 代理对非 public 方法的支持有限私有方法无法被代理你写了注解也不会生效。第五步确认线程池执行器名称。Async(notifyExecutor)里的名字必须和线程池 Bean 的名字完全一致。拼错时 Spring 可能不会立刻报错而是退回到默认执行器你会看到线程名变成了task-xx而不是预期的前缀。第六步打开 DEBUG 日志看提交任务时有没有走进代理拦截器。Spring 的异步拦截器在方法执行前会打印“通过异步执行”相关日志看不到这一行说明代理没拦住。这一套检查下来绝大多数“异步没生效”的问题都能找到答案。7. 最后说点我的实际体会异步代码写起来不复杂真正复杂的是把线程池、事务、上下文、异常、重启这几件事放在一起权衡。我见过太多项目一开始只是加了个Async后来慢慢暴露出任务堆积、事务错乱、线程泄漏的连锁问题。解决的办法也很简单就是回到最初搞清楚这个任务能不能异步线程池参数有没有依据任务失败是否有人知道服务重启会不会丢数据。把这四件事都确认了springboot 异步操作才算是真正能用。