做后端接口性能优化的这些年我有个很深的体会很多接口慢真不是因为主流程复杂而是因为把一堆没必要同步执行的事塞进了请求线程。举个例子用户下单后要发短信、送积分、写统计日志这三件事每件都要几十毫秒串行下来接口响应时间就多了小 200 毫秒。Spring 的 Async 注解就是把这些支线任务挪到独立线程池执行的“快车道”也是我在进程内做异步化解耦时用得最多的工具。这篇文章不打算写文档翻译只讲生产实践注解背后的代理机制、线程池参数怎么定、为什么有时候加了注解却不生效以及我在线上踩过的坑和数据复盘。1. 为什么 Async 能成为性能优化的“快车道”1.1 接口慢的真相主线程在替支线任务买单很多人一聊性能优化脑子里全是缓存、分库分表、搜索引擎这些大动作。但真实业务里的性能瓶颈往往没这么玄乎。我接手过的几个项目核心接口慢慢在大量“顺手做”的逻辑上。拿一个标准的注册接口来说插入用户表可能只要 20ms但后面跟着发欢迎邮件、发短信验证码、初始化用户配置、给推荐系统同步数据每项又是几十毫秒。这些支线任务有一个共同特点调用方不关心它们的返回值也不关心它们什么时候执行完。但在同步模型里它们全在 Tomcat 的请求线程里老老实实排队跑用户就必须干等着。这就是第一个关键点同步调用时接口耗时等于主流程和所有支线任务的耗时之和。而异步化之后主线程把任务丢给线程池马上返回接口耗时约等于主流程耗时。这个时间差就是 Async 带来的“快车道”。代价是你得接受一个事实——支线任务的结果可能晚到甚至可能失败重试。1.2 Async 的适用边界不是所有逻辑都适合异步越简单的工具越容易被用过头。Async 不是万能药我一般先做三个判断调用方是否需要马上拿到结果需要就不能用 Async应该用同步或 CompletableFuture 显式等待。任务可以容忍丢失或延迟吗可以就适合异步如果是对账、退款、库存扣减这类强一致性操作别指望 Async 替你兜底应该走消息队列加事务消息。执行线程池有足够的容量吗异步不等于免费只是把线程切换到了另一个池子里。池子不够大照样会堆积、拒绝。我常用的划分方式是这样的适合 Async 的场景不适合 Async 的场景短信/邮件/站内信通知库存扣减、余额变更操作日志、埋点上报必须返回流水号给前端的操作积分赠送、优惠券发放需要读取异步结果再拼接响应的逻辑缓存预热、索引构建强事务边界内的数据修改说白了Async 解决的是“非核心链路耗时过长”的问题而不是“核心链路并发能力不足”的问题。系统整体并发不够该扩容扩容该加缓存加缓存。1.3 为什么不是 new Thread也不是直接上 MQ很多初学者会问要异步我自己 new 一个线程不就行了或者直接引入 RocketMQ/Kafka 不是更彻底我的看法是这三者其实是三种不同粒度new Thread()最直接但没有任何复用和治理能力。每次请求都创建线程高并发下线程数爆炸OOM 是迟早的事。而且 Runnable 里 Spring Bean 的依赖注入、请求上下文全都要自己手工传递代码会变得又脏又难维护。Async适合进程内的异步解耦。调用方和被调用方在同一个 JVM 里不需要网络传输代码侵入极小原有 Spring Bean 的依赖注入完全不受影响。线程池还可以统一配置、监控、治理。MQ适合跨服务、跨进程的异步解耦。引入了新的中间件需要考虑消息丢失、重复消费、顺序性、积压等一系列问题成本高不少。所以我的选型原则很简单能在一个进程里解决的先用 Async必须跨系统解耦的才上 MQ。很多大厂内部的异步任务拆分第一步也是先把进程内的同步调用改成 Async等到业务量确实需要独立系统了再迁移到 MQ。2. 拆开黑盒Async 从注解到线程池执行的完整链路2.1 起点在 EnableAsync一个后置处理器引发的“代理”用 Async 之前你大概率会先在配置类上加 EnableAsync。这个注解很关键它往容器里注册了一个AsyncAnnotationBeanPostProcessor。从名字就能看出来这是一个 Bean 后置处理器Spring 在创建每个 Bean 实例之后都会让后置处理器“过目”一遍。这个后置处理器会扫描目标 Bean 里有没有带 Async 的方法。如果发现就说明这个 Bean 需要被增强Spring 会为它生成一个代理对象。后续所有对 Bean 的调用实际上先进了代理再由代理决定是直接执行原方法还是丢进线程池。这正是 Async 和 AOP 的关系它本质上就是基于 Spring AOP 的通知器Advisor。Spring 在创建代理时会把AsyncAnnotationAdvisor织入进来。这里有个很容易被忽略的细节代理是在 Bean 初始化阶段创建的所以Async 能否生效强烈依赖于调用方能不能拿到代理对象。后面第 4 部分讲的“自调用失效”根因就在这里。2.2 方法拦截器做了什么真正干活的是AsyncExecutionInterceptor。它实现了 Spring AOP 的MethodInterceptor也就是在目标方法调用前后做拦截。核心逻辑大致是这样的解析方法上的 Async 注解拿到指定的线程池名称如果有的话。如果没指定线程池就用默认线程池这个默认值后面有大坑。把被调用的方法封装成一个Callable或Runnable。交给线程池去执行调用线程立即返回。用伪代码表达就是public Object invoke(MethodInvocation invocation) throws Throwable { // 拿到线程池 Executor executor determineAsyncExecutor(invocation.getMethod()); // 把原方法调用封装成任务 CallableObject task () - invocation.proceed(); // 提交给线程池并返回 Future doSubmit(task, executor, invocation.getMethod().getReturnType()); // invoke 方法直接返回调用方不阻塞 }注意第 5 步这里由返回值类型决定“提交后干什么”方法返回void提交完就返回 null返回Future/CompletableFuture就把任务提交的结果返回给调用方返回其他类型比如直接返回某个业务对象Spring 其实是不支持的文档里明确要求返回值只能是void或 Future 类型。我在项目里见过有人尝试返回String结果调用方拿到的永远是 null排查半天才发现是自己用法不对。2.3 默认线程池的“埋伏”如果不在 Async 注解里指定线程池Spring 会按照这样一个优先级去找先从容器里找唯一的TaskExecutorBean或者唯一的ExecutorBean。如果找不到会尝试创建一个默认的SimpleAsyncTaskExecutor。这个SimpleAsyncTaskExecutor表面上是线程池实际每次提交任务都会 new 一个线程出来执行完就丢弃完全没有复用。我曾经在测试环境跑过一个小 demo接口被压了 2000 次这个“线程池”就创建了 2000 个线程直接把这个进程的句柄数打满。所以生产环境第一条铁律永远不要用默认的 SimpleAsyncTaskExecutor必须显式声明一个 ThreadPoolTaskExecutor 或别的线程池并且在 Async 注解里明确指定池子名称。这一点放进第 3 部分展开讲。3. 生产级线程池配置大厂落地最关键的一步3.1 ThreadPoolTaskExecutor 的默认参数其实很危险很多同学第一次配置线程池直接new ThreadPoolTaskExecutor()然后不设置任何参数。我要提醒一下ThreadPoolTaskExecutor的默认核心线程数是 1最大线程数是Integer.MAX_VALUE队列容量也是Integer.MAX_VALUE。这里就有一个经典的“没生效”现象你明明设置了maxPoolSize但线上永远只有 1 个线程在跑。原因在于线程池的扩容规则——当核心线程都忙、且队列还没满的时候新任务只会进队列排队不会新开线程。默认的队列是无界的意味着队列永远“不满”那么 maxPoolSize 形同虚设核心线程数 1 就变成了实际永远只有 1 个线程。所以我配置线程池的第一步永远是先把这三样显式写清楚Bean(bizAsyncExecutor) public ThreadPoolTaskExecutor bizAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); // 核心线程数 executor.setMaxPoolSize(16); // 最大线程数 executor.setQueueCapacity(200); // 有界队列容量 executor.setThreadNamePrefix(biz-async-); executor.setKeepAliveSeconds(60); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(30); executor.initialize(); return executor; }initialize()这一步很容易漏。Spring Boot 的Bean方法一般会自动初始化大部分 Bean但ThreadPoolTaskExecutor的initialize()不调用的话池子是没有真正启动的虽然任务提交时也会懒加载但最好手动调用避免后续配置了监听、优雅停机等逻辑时不生效。3.2 从业务指标推算线程数与队列线程池参数不是拍脑袋定的最基本的方法是用利特尔法则Littles Law估算所需线程数 ≈ 任务每秒提交量 × 单个任务平均执行时间秒。我举个例子。某个活动的积分赠送任务高峰期每秒提交 20 个任务每个任务平均执行 200ms那需要的线程数大约是 20 × 0.2 4。再加一些余量核心线程数取 8、最大线程数取 16在大多数业务场景下就够用了。队列容量则看你对削峰的诉求。如果业务方告诉你大促时 10 秒内会涌入 1000 个任务那队列至少得有 500~800 的容量不然线程数一旦打满任务直接触发拒绝策略。这里有个常见的认知误区队列越大任务积压越久数据延迟越高。不是容量设置大就是好事要结合任务本身允许的延迟时间来反推。假设任务允许延迟 30 秒线程池每秒能处理的任务数是QPS * 平均耗时决定的那队列里最多能堆每秒处理量 × 30个任务。超过这个数就该触发拒绝或降级而不是无限堆积。3.3 线程池隔离与命名大厂里可能同时有下单、营销、报表、消息推送等多个业务共用 Spring 容器如果全用同一个线程池一个业务的任务把池子占满了其他业务全部跟着遭殃。我经历过一次很典型的故障营销团队用默认线程池批量发推送把池子打满结果下单流程里的异步积分任务排队 20 秒用户以为下单卡死了疯狂重试最后流量放大压垮了数据库。从那以后我给自己定了一条规矩不同业务域必须用不同线程池并配典型的线程名前缀。线程名前缀不是用来好看的是在线上排障时执行jstack能一眼看出某个线程是哪个业务的。我的命名习惯是“业务模块-异步类型”比如order-notify-、marketing-push-、report-write-。另外有条件的话给每个线程池配一组监控指标至少要有活跃线程数、队列深度、拒绝任务次数、线程池完成任务总数。Spring 的ThreadPoolTaskExecutor本身暴露了getPoolSize()、getActiveCount()、getQueue()这些方法埋点到监控系统很简单。3.4 一个可落地的统一配置示例Spring Boot 2.1 之后推荐实现AsyncConfigurerCustomizer来统一定制线程池而不是直接 implementsAsyncConfigurer。一个相对完整的配置长这样Configuration EnableAsync(proxyTargetClass true) public class AsyncConfig implements AsyncConfigurerCustomizer { Override public void customize(ThreadPoolTaskExecutor executor) { executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(200); executor.setThreadNamePrefix(global-async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(30); executor.initialize(); return executor; } }等等AsyncConfigurerCustomizer的customize方法返回 void我上面这段是示意不能照抄。这种接口是用来对自动配置的ThreadPoolTaskExecutor做进一步定制的。更稳妥的做法是把所有线程池定义为Bean并在使用处用Async(池名)显示指定。这是我的主线方案全局默认池 各业务域独立池。全局池兜底业务池隔离入口统一在注解里写清楚。4. 失效陷阱为什么你的 Async 注解“写了等于没写”4.1 最典型的同类自调用这应该是 Async 相关最多的线上问题。代码长这样Service public class OrderService { public void createOrder(OrderDTO dto) { // 主流程 this.sendNotify(dto); // 看似异步实际同步执行 } Async(notifyExecutor) public void sendNotify(OrderDTO dto) { // 发短信、邮件 } }你在createOrder里用this.sendNotify()去调Spring 根本拦不到。原因前面第 2 部分说过Async 是靠代理对象生效的而this是原始目标对象不是代理对象。代理对象只有在外部注入时才会被 Spring 替换进去内部this永远绕过了代理。我第一次遇到这个情况时一直在查线程池配置是不是有问题后来打印了this.getClass()才发现类内部拿到的根本不是 CGLIB 代理类方向完全错了。4.2 失效场景清单我整理了一个 checklist每次写 Async 之前会过一遍同类调用this.xxx()一定失效哪怕方法上注解写得很完整。private 方法Spring AOP 无法增强 private 方法因为 CGLIB 无法生成访问 private 方法的子类代理。static 方法同样不会生效Async 只能作用于实例方法。final 类或 final 方法CGLIB 代理无法继承 final 类方法也无法重写。绕过代理的引用比如手动new出来的 Bean或者通过ApplicationContext.getBean但拿到的不是代理对象正常情况 getBean 拿到的是代理。代理方式不对某个类有接口但proxyTargetClassfalse默认强制用 JDK 动态代理时类内部调用同样失效这个本质还是自调用问题。4.3 绕开陷阱的三种改法我常用的有三招按推荐程度排序第一招把异步逻辑拆到独立的 Bean 里。这是最干净的方式也是我首选的方式。Service public class OrderService { private final NotifyService notifyService; public OrderService(NotifyService notifyService) { this.notifyService notifyService; } public void createOrder(OrderDTO dto) { notifyService.sendNotify(dto); // 走代理异步生效 } } Service public class NotifyService { Async(notifyExecutor) public void sendNotify(OrderDTO dto) { // 发短信、邮件 } }之前有人问我这样做会不会 Bean 循环依赖实际上只要规避双向依赖就不会Spring 处理代理对象比想象中要成熟得多。第二招拿到当前代理对象再调用。EnableAsync(proxyTargetClass true, exposeProxy true) Service public class OrderService { public void createOrder(OrderDTO dto) { OrderService proxy (OrderService) AopContext.currentProxy(); proxy.sendNotify(dto); } }注意exposeProxy true这个开关没开的话AopContext.currentProxy()会抛异常。这一招适合不想拆类的场景但在我看来代码可读性差一些而且容易踩坑比如在一个事务方法里调用AOP 代理是有嵌套的需要小心currentProxy到底指哪一层。第三招注入自己。用Autowired注入当前 Bean 的一个代理引用然后用注入对象调用异步方法。但这样等于人为制造了一个自我依赖Spring 能处理可设计上看着别扭我一般不建议。另外提一句如果你在同一个方法上同时加了 Async 和 Transactional事务在异步线程里默认是不生效的。道理很简单事务也是 AOP 代理实现的异步线程拿不到原本的数据库连接和事务上下文。正确做法是拆开异步方法里再调用一个带 Transactional 的方法。5. 线上灾难现场异常、上下文与拒绝策略5.1 异步方法里抛了异常谁来处理很多刚用 Async 的同学都以为异常会像同步调用一样抛给调用方然后被全局异常处理器接住。错了。如果异步方法返回void异常不会抛到调用线程而是直接由线程池的UncaughtExceptionHandler或者 Spring 的AsyncUncaughtExceptionHandler处理。默认情况下Spring 只是把异常打一下日志如果不是你主动去查日志异常几乎是静默的。这就可能导致一个很可怕的现象异步任务失败了业务方完全无感知对账时才发现少了一堆积分。我的做法是自定义异常处理器并接入监控告警Configuration public class AsyncExceptionConfig implements AsyncConfigurer { Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (ex, method, params) - { // 打印完整异常堆栈 log.error(异步任务执行失败方法: {}, method.getName(), ex); // 发送告警通知值班同学 alertService.send(异步任务异常, ex.getMessage()); }; } }如果异步方法返回的是CompletableFuture那调用方可以在get()时捕获ExecutionException。我之前接手的一个项目里积分赠送用的CompletableFuture.runAsync结果积分接口一直报空指针排查半天发现是任务内部丢了个请求参数异常全被 Future 包住了没来得及暴露出来。5.2 ThreadLocal 与链路追踪异步线程里的上下文在用 Async 的第二个大坑就是ThreadLocal 丢上下文。请求线程里通常会放用户信息、TraceId、租户 ID这些在同步调用中一路传递到了异步线程线程池里的线程根本复制不到请求线程的 ThreadLocal。结果就是异步任务里查不到当前用户是谁日志里找不到 TraceId全链路追踪断成一片。我踩过最疼的一次是在一个报表任务里需要根据租户 ID 查数据异步线程过去租户 ID 是 null查出了一堆别的租户的数据后来多亏有前端同学发现报表数据串了才紧急修复。从那以后我要求所有业务线程池都要配置TaskDecorator在线程执行前把上下文拷贝进去executor.setTaskDecorator(runnable - { // 保存请求线程的上下文快照 RequestContextHolder contextHolder RequestContextHolder.getRequestAttributes(); MapString, String mdcContext MDC.getCopyOfContextMap(); return () - { try { RequestContextHolder.setRequestAttributes(contextHolder); MDC.setContextMap(mdcContext); runnable.run(); } finally { MDC.clear(); } }; });这个装饰器不是在任务开头复制一次就行关键是finally里要清理不然线程池复用时上一次任务的上下文会污染下一次任务。这条细节我是在一次诡异的“数据错乱”故障里查出来的。5.3 拒绝策略不只是技术参数更是一种业务取舍线程池满、队列满之后新提交的任务会触发拒绝策略。Spring 的ThreadPoolTaskExecutor底层是ThreadPoolExecutor默认策略是AbortPolicy直接抛RejectedExecutionException。这个策略是最简单的但在生产环境要千万小心。任务被拒绝后取决于你在哪个环节提交的异步任务如果是在用户请求线程里顺手提交的这个异常会直接冒到接口层用户看到的就是 500。我一个项目里就出过这种问题业务增长后异步线程池配置跟不上平时没问题遇到活动高峰直接拒绝策略抛异常结果用户下单失败率 10%。我的建议是分场景选策略核心链路相关的异步任务用CallerRunsPolicy任务提交线程自己执行至少保证核心链路不丢任务。代价是如果任务太重调用线程会被拖住耗时上升。非核心、可丢弃的任务用自定义的丢弃策略比如记录日志后直接丢弃或者把任务持久化到本地表后续定时补偿。最不推荐无脑AbortPolicy除非你明确知道任务丢了也无所谓。另外CallerRunsPolicy不是没有代价。它把任务“退回”给提交线程执行如果提交线程是 Tomcat 请求线程高峰期等价于把异步压力重新压回了请求线程接口 RT 会明显上涨。所以这个策略要配合监控一起看。5.4 一个活动大促期间的线程池故障复盘分享一个我印象很深的案例。某个电商项目做大促预热营销团队把定向优惠券发放做成了异步任务高峰期每秒要发 3000 个任务。线程池配置的是核心 8、最大 16、队列 2000用的默认AbortPolicy。活动刚开始监控就报警了接口成功率下降错误日志里全是RejectedExecutionException。我做了三件事先看线程池监控发现 16 个线程全部跑满队列持续满说明容量不够。当时的业务方反馈优惠券晚发几分钟可以接受但不能丢。立即把拒绝策略改成CallerRunsPolicy同时加了告警让开发去扩容线程池。改完之后成功率恢复了但接口 P99 从 220ms 涨到 400ms原因就是CallerRunsPolicy把大量任务塞回了请求线程。后来我们把营销的异步任务拆到单独线程池并配置了更大的容量同时把非核心的名单推送改为批量削峰这个问题才算根治。这个案例让我记住一句话异步化不是把问题变没了只是把问题挪到了一个更容易被忽略的地方。线程池的容量规划、监控告警、拒绝策略才是真正的重头戏。6. 从数据到效果一次真实的接口性能优化复盘6.1 优化前的瓶颈数据说一个我离开之前项目时依然印象深刻的优化案例。订单详情页接口压测时 P99 接近 850ms业务方天天投诉。当时用 Arthas 做了 trace发现耗时主要分布是查询订单主表约 80ms查询商品信息约 120ms查询用户信息约 150ms发送订单状态变更通知约 200ms更新用户的积分和等级约 150ms记录用户行为日志约 100ms问题很明显后三项根本不需要阻塞在请求线程里。用户看订单详情为什么要等积分更新完、日志写完、通知发完这些完全可以在返回响应之后再做。6.2 异步化改造的关键步骤改造前我列了一个清单在主流程里把这些支线任务从同步调用改成Async(orderBizExecutor)。如果某些支线任务之间有依赖就用CompletableFuture串起来而不是简单全部丢进去。给异步线程池配好 TaskDecorator确保 TraceId 和用户上下文能穿透。给每个异步任务加上自助式监控在线程池里做埋点数据库层打点。核心代码大致是这样Service public class OrderDetailService { Async(orderBizExecutor) public void afterOrderQuery(OrderDTO order, UserDTO user) { // 三个支线任务并行执行 CompletableFutureVoid notifyFuture CompletableFuture.runAsync( () - notifyService.sendStatusChange(order), orderBizExecutor); CompletableFutureVoid pointFuture CompletableFuture.runAsync( () - pointService.updateUserPoint(user, order), orderBizExecutor); CompletableFutureVoid logFuture CompletableFuture.runAsync( () - behaviorLogService.record(order), orderBizExecutor); CompletableFuture.allOf(notifyFuture, pointFuture, logFuture).join(); } }这里我用join()等三个支线任务全部完成才返回目的是保证异步线程池里的异常能被这一层捕获而不是静默丢失。如果接口主流程需要立刻响应那join()都不需要完全交给线程池但异常处理就要靠前面第 5 部分的AsyncUncaughtExceptionHandler了二选一。6.3 优化效果与监控指标改造上线后的压测数据指标优化前优化后变化P99 响应时间850ms430ms下降 49%平均响应时间520ms240ms下降 54%请求线程占用率峰值接近 100%峰值约 65%大幅缓解异步任务成功率无统计99.98%可观测这里有个很微妙的地方P99 没有降到理论上的“主流程耗时”因为线程池里那几个任务虽然不阻塞请求线程但它们占用了数据库连接和外部服务资源间接影响了主流程。这也是一个需要提醒的经验——不要把异步化想象成纯免费的性能提升它释放了请求线程但可能让数据库、下游服务压力更集中监控依然要盯。6.4 可观测性是异步化的另一半异步任务一旦跑起来最怕的就是“黑盒”。我的建议是至少埋三个监控点线程池活跃数、队列深度、拒绝次数。这三个指标能帮你回答三个问题任务是不是在执行是不是堵在队列里是不是已经开始丢了我遇到过至少两次线程池队列涨到一万多业务方才跑来问“为什么我们报表数据延迟了这么久”。数据延迟的本质就是队列堆积而队列堆积的核心原因往往是任务执行耗时变长比如某个下游接口从 50ms 变成了 500ms。如果不看队列深度这类问题很难早期发现。所以我把队列深度超过阈值的报警设成了 P1 级跟接口成功率同一优先级。最后的一点个人经验如果想让我从所有坑里提炼一句话那就是加 Async 之前先回答自己三个问题——这个任务能接受延迟吗接受失败吗线程池满了之后怎么办想清楚这三件事比背再多底层原理都有用。另一个我坚持的习惯是每次配置完线程池都会在测试环境人为把线程数调到 2、把队列调到 5然后拿压测流量去打看拒绝策略、监控能不能按预期触发。这比任何 review 都靠谱。Async 的原理并不复杂但它背后牵涉的是对整个异步体系的把控线程池治理、上下文传递、异常兜底、容量规划。把这套体系建好它才是名副其实的性能优化“快车道”否则它可能是一条让你半夜爬起来处理告警的“慢车道”。