企业官网建设流程全解析

上周帮同事排查一个订单系统的性能问题，接口耗时从200ms涨到了680ms，业务逻辑是异步处理短信通知和优惠券发放，但日志里显示这些操作全都在请求线程里同步跑完了。代码检查了三遍，@Async注解明明白白写在方法上，@EnableAsync也加了，可就是不生效。

这个场景在SpringBoot项目里出现频率极高。我见过自调用导致的失效、代理方式配置不一致导致的失效、默认线程池导致的性能问题，还有异步异常吞掉导致线上故障难以定位的。网上资料确实不少，但很多只讲表象不讲原理，照着改可能暂时好了，换个场景又踩坑。

这篇文章把我这些年遇到的@Async失效问题重新盘了一遍，从@Async的底层代理机制讲起，到每种失效场景的复现、根因、修复方案，最后附一份可以直接抄的排查清单和避坑手册。不管你是刚接触SpringBoot的新手，还是被异步问题折磨过的老开发，应该都能从里面找到自己需要的答案。

1. 先搞清楚一件事：@Async到底是怎么工作的

1.1 异步不是魔法，是代理

很多同学对@Async的理解停留在"加了注解方法就会异步执行"这个层面，这会导致排查问题时完全没有方向感。实际上，@Async之所以能生效，靠的是Spring AOP（面向切面编程）的代理机制。

当你在配置类上加了@EnableAsync之后，Spring容器在启动阶段会对所有标注了@Async注解的Bean做一次特殊的"包装"。它不是直接修改你写的方法，而是为目标Bean生成一个代理对象。这个代理对象在逻辑上会拦截所有对目标方法的调用，如果发现方法上有@Async注解，就会把方法的执行从当前线程切换到线程池中的某个线程去运行。

我习惯用一个生活化的例子来解释这件事：你去银行办理业务，正常情况要在大厅排队，这相当于同步调用。但如果你是VIP客户，银行会把你引导到贵宾室，让你先提交业务单，后台操作完成后再通知你结果。贵宾室的前台就是代理对象，后台运行的大堂经理就是线程池里的线程。没有贵宾室这个"中转站"，VIP权益就无法生效。

理解这个机制后，排查失效问题的思路就非常清晰了：只要调用没有经过代理对象，@Async就一定会失效。

1.2 失效的典型现场表现

@Async失效后的表现比很多其他故障更隐蔽，因为大多数情况下它不报错，就是静悄悄地同步执行。

我总结了三个最常见的现场特征，如果你遇到的情况符合其中任意一条，基本可以锁定方向：

第一，接口响应时间没有下降。比如一个方法内部有某个耗时3秒的远程调用，你期望把它异步化后接口响应时间降到毫秒级，但加了@Async后接口仍然耗时3秒以上——这说明异步根本没生效。

第二，日志中的线程名始终是同一个。SpringBoot的默认日志输出格式里包含线程名，同步执行时日志里的线程名是http-nio-8080-exec-1这样的请求线程名；异步执行时日志里应该出现自定义的线程池前缀，比如后面我会讲到的async-task-1。如果方法内部的日志线程名和请求线程名一致，那就是同步执行。

第三，偶尔有效偶尔失效。这种情况最折腾人，通常和调用路径有关。比如某个方法在A场景下通过Spring注入的Bean调用，异步生效；在B场景下是通过this关键字内部调用，异步失效。问题代码不长，但隐藏得很深。

把这三个表现记在心里，排查时就有了抓手。接下来我们逐个拆解失效的根因。

2. 失效原因深度拆解：五个坑，一个一个踩

2.1 第一个坑：自调用问题

自调用是@Async失效最常见的原因，几乎占了我在实际项目中遇到的八成情况。

什么是自调用？就是一个类的内部方法直接调用同类中的另一个@Async方法。比如下面这段典型的错误示例：

@Component public class OrderService { public void createOrder() { long start = System.currentTimeMillis(); // 模拟订单校验和入库逻辑 sendNotification(); System.out.println("总耗时：" + (System.currentTimeMillis() - start)); } @Async public void sendNotification() { try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("通知发送完成"); } }

这段代码看起来没有任何问题，但运行时你会发现，createOrder方法依然要等sendNotification跑完3秒才结束。

为什么？因为this.sendNotification()中的this指向的是原始的对象，不是Spring容器生成的代理对象。我们刚才说过，@Async的异步逻辑是在代理对象上实现的，只有通过代理对象调用方法，切面逻辑才会触发。而在同一个类内部，this引用就是原始对象本身，相当于绕过了代理，直接执行了目标方法。Spring的AOP拦截器根本没有机会介入。

这个问题的隐蔽性在于：代码编译不报错，运行不报错，逻辑上看起来也完全合理。但它就是破坏了异步的契约。

2.2 第二个坑：代理方式与方法的可代理性

自调用问题解决之后，还有一类问题出在Spring选择的代理机制上。

SpringBoot 2.x默认使用CGLIB代理，也就是通过生成目标类的子类来实现代理。这种方式要求目标方法不能是final的，因为CGLIB重写方法靠的是生成子类并override，final方法无法被重写，代理自然无法介入。同时，private方法也不会被代理，因为子类无法访问父类的私有方法。

从SpringBoot 1.x升级到2.x的老项目特别容易踩这个坑。1.x时代在某些场景下默认使用JDK动态代理，JDK动态代理是基于接口实现的，它要求被代理的类必须实现接口，且只有接口中声明的public方法才会被代理拦截。

我遇到过一个非常典型的案例：老项目从SpringBoot 1.5升到2.1，原来的@Async方法放在接口实现类中，方法签名是接口里没有的扩展方法。升级前用JDK动态代理，这个扩展方法不会被拦截，但项目也没出过问题；升级后切到CGLIB，理论上应该能拦截了，结果反而因为某个final方法导致启动报错。这就是代理方式变化带来的副作用。

所以在排查@Async失效问题时，一定要同步确认三个点：方法是否是public的、类是否可以被继承（非final类）、被调方法是否在接口中声明（如果用JDK动态代理）。

2.3 第三个坑：线程池配置，最容易被忽视的性能隐患

如果说前两个坑是"异步完全失效"，那第三个坑就是"异步生效但埋下隐患"。

在没有自定义线程池的情况下，Spring的@Async默认使用SimpleAsyncTaskExecutor。看这个名字里带个"Simple"，它确实简单到简陋：每次提交一个异步任务，它就会new出一个新线程来执行。这个实现没有任何线程复用、没有等待队列、没有核心线程数和最大线程数限制。

高并发场景下，这会直接导致线程数暴涨。之前有个电商公司的朋友跟我说，他们的大促活动刚开始半小时，服务器负载直接拉满，一查线程数发现JDK默认能创建的线程快被打满了。罪魁祸首就是@Async默认线程池没有上限，每个异步任务都开新线程。

即便你的并发不高，频繁创建销毁线程本身也有开销，只不过这个开销在低并发时不明显。真正可怕的是，这个隐患平时发现不了，一旦流量上来就会变成线上事故。

所以我的建议是，只要项目里用了@Async，就一定配置一个专门的线程池。这不仅是性能优化问题，更是一个稳定性保障。

2.4 第四个坑：异常处理与事务问题

@Async方法里的异常处理方式，和普通同步调用完全不一样。

同步调用时，异常会沿着调用栈向上抛，最终由调用方通过try-catch捕获处理。但异步方法在另一个线程里执行，调用方线程早就返回了，异常根本没有地方可以抛。获取不到异常结果的情况下，异常会被Spring的默认策略打印到日志里。如果方法有返回值且返回的是Future，异常会被封装在Future.get()的结果里，调用方只有调用get()才能感知。

这个机制带来的两个直接后果：

第一，异步方法内部的try-catch必须自己做好兜底。如果有人抛出RuntimeException，至少要保证异常被记录下来，不能吞掉。很多项目排查线上问题时找不到错误日志，就是因为异步方法里的异常被Spring的异常处理策略悄悄记录到某个没人看的日志文件里了。

第二，事务无法参与。@Transactional和@Async一起使用时，如果方法报错，事务不会自动回滚。因为Spring的事务管理基于ThreadLocal，事务上下文绑定在开启事务的那个线程上。异步方法在另一个线程执行，它天然不在当前事务上下文中，也就无法触发回滚。

2.5 第五个坑：返回值类型的限制

@Async方法的返回值类型是有明确限制的。Spring官方规定，标注了@Async的方法返回值只能是void或者Future类型（Spring 4.2之后支持CompletableFuture和ListenableFuture）。

如果方法需要返回其他类型的值，编译器不会报错，但运行时会出现意想不到的行为。最常见的表现是：方法返回一个User对象，但调用方拿到的永远是null。因为异步方法在线程池里执行时，返回值无法直接传递给调用方线程。

正确的做法是改用CompletableFuture：

@Async public CompletableFuture<User> findUser(String id) { User user = userMapper.selectById(id); return CompletableFuture.completedFuture(user); } // 调用方 CompletableFuture<User> future = userService.findUser("1001"); User user = future.get(3, TimeUnit.SECONDS);

有一个容易被忽略的点：@Async方法返回Future时，方法内部的耗时逻辑不会阻塞调用方，但一旦调用future.get()，调用方还是会阻塞等待结果。所以如果你的业务不需要获取结果，直接用void方法就好，不要为了"未来可能用到"而强行返回Future，否则异步带来的性能收益会被get()的阻塞抵消。

3. 从复现到修复：一套完整的排查与解决流程

3.1 先做一个可复现的实验

排查这类问题，我习惯先写一个最小复现案例，确认问题现象后再对照排查清单。下面是一个可以直接复制跑的示例：

@RestController @RequestMapping("/async") public class AsyncTestController { @Autowired private AsyncTestService service; @GetMapping("/test") public String test() { long start = System.currentTimeMillis(); service.executeAsyncTask(); return "耗时：" + (System.currentTimeMillis() - start); } } @Service public class AsyncTestService { public void executeAsyncTask() { // 这里的方法体是同步执行的，日志会打印出当前线程名 System.out.println("方法开始执行，当前线程：" + Thread.currentThread().getName()); try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } } }

这个demo里executeAsyncTask没有加@Async，先把基线跑出来，确认接口耗时2秒。然后加上@Async，观察接口耗时的变化。如果加了注解后接口反而没有变化，就说明异步没有生效，进入排查流程。

3.2 拿到就用的检查清单

每次排查这类问题，我都按下面这张清单逐项核对，效率很高：

3.3 修复方案一：注入自我代理（治标）

最简单的修复方式是让对象自己注入自己，通过Spring容器获取代理对象来调用：

@Component public class OrderService { @Autowired private OrderService self; public void createOrder() { // 其他业务逻辑 self.sendNotification(); } @Async public void sendNotification() { // 异步执行的逻辑 } }

这种方式解决自调用问题很直接，网上很多教程也推荐这么做。但我不建议把它作为首选方案，原因有两个：第一，它把一个类里既有同步业务又有异步任务，本质上还是"揉在一起"的，不利于后续维护；第二，它依赖Spring的循环依赖解决机制，虽然SpringBoot 2.6+默认允许循环依赖，但在大型项目里循环依赖本身就应该尽量避免。

3.4 修复方案二：拆分类（治本，推荐）

更推荐的做法是把异步方法单独拆到一个独立的Bean里，让调用方通过依赖注入来调用。这样既解决了代理问题，也实现了职责分离：

@Component public class OrderService { @Autowired private NotificationService notificationService; public void createOrder() { // 订单核心逻辑 notificationService.sendNotification(); } } @Component public class NotificationService { @Async public void sendNotification() { // 发短信、发邮件、发优惠券等耗时的通知逻辑 // 这里可以安全地使用this调用同类中的其他方法 this.doInnerTask(); } public void doInnerTask() { // 异步方法内部的子任务，可以直接this调用 // 因为此时已经处于异步线程中，无需再加@Async } }

把异步方法抽到独立的NotificationService后，调用方通过依赖注入拿到的必然是Spring的代理对象，@Async就能正常拦截。而且NotificationService内部的方法互相调用也不需要再纠结代理问题——它们已经在异步线程里了，不需要再走一遍代理。

这个方案的额外收益是，异步相关的逻辑集中在一个类里，以后要加参数、改线程池、调异常处理，都只动一个类即可。

3.5 修复方案三：自定义线程池参数设计（进阶）

拆分类解决的是"异步不生效"的问题，但真正上线前还需要把线程池配置好。

我推荐的线程池配置如下：

import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor; import java.util.concurrent.Executor; import java.util.concurrent.ThreadPoolExecutor; @Configuration public class AsyncConfig { @Bean("taskExecutor") public Executor taskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); // 核心线程数：常驻线程数量 executor.setCorePoolSize(5); // 最大线程数：核心线程不够用且队列满了之后的最大扩展数 executor.setMaxPoolSize(20); // 队列容量：核心线程全忙时，新任务进入队列等待 executor.setQueueCapacity(100); // 非核心线程空闲存活时间 executor.setKeepAliveSeconds(60); // 线程名前缀，方便日志排查 executor.setThreadNamePrefix("async-task-"); // 拒绝策略：队列满且线程数达到最大值时，由调用方线程直接执行 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }

这里重点解释一下几个容易搞混的参数，因为很多同学在这上面翻过车。

corePoolSize是常驻线程数，相当于银行固定的柜台窗口。maxPoolSize是最大线程数，相当于银行在最忙时段临时加开的窗口总数。queueCapacity是等待区，相当于大厅里能容纳的等待人数。

任务提交后，执行流程是：先让核心线程处理；核心线程全部忙了，新任务进入队列等待；队列也满了，才创建新线程直到达到maxPoolSize；这三个都满了，就触发拒绝策略。

CallerRunsPolicy是我最喜欢的拒绝策略，它会把任务退回给调用方的线程去执行。这样做有好处也有坏处：好处是任务不会丢；坏处是如果任务量持续超过线程池处理能力，调用方线程会被拖住，接口RT会上升。但相比直接丢弃任务，把"削峰"的压力平滑到调用方，让调用方感知到系统繁忙，是一种更健康的降级方式。

关于核心线程数怎么设置，有一个经验公式可以适当参考：

• CPU密集型任务（大量运算、序列化、压缩）：核心线程数设为CPU核数+1
• IO密集型任务（远程调用、数据库读写、文件操作）：核心线程数设为CPU核数的2倍

大多数业务系统的异步任务属于IO密集型，比如发短信、查数据库、调第三方接口，所以5到10作为起步值是比较合理的。线上压测后再根据实际耗时调整。

另外，给线程加前缀是一个我强烈建议的习惯：async-task-。日志里一眼就能看出这个线程是哪个线程池的，排查问题不知道省了多少时间。

3.6 修复方案四：异步异常统一兜底

异步方法里的异常，需要在系统层面做一个统一兜底。Spring提供了两个接口配合使用：AsyncConfigurer和AsyncUncaughtExceptionHandler。

import org.springframework.aop.interceptor.AsyncUncaughtExceptionHandler; import org.springframework.context.annotation.Configuration; import org.springframework.scheduling.annotation.AsyncConfigurer; import org.springframework.scheduling.annotation.EnableAsync; import java.lang.reflect.Method; import java.util.concurrent.Executor; @Configuration @EnableAsync public class AsyncConfig implements AsyncConfigurer { @Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(100); executor.setThreadNamePrefix("async-task-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } @Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return new AsyncUncaughtExceptionHandler() { @Override public void handleUncaughtException(Throwable ex, Method method, Object... params) { // 这里可以记录日志、接入告警平台、甚至落库 System.err.println("异步方法执行异常，方法：" + method.getName() + "，异常信息：" + ex.getMessage()); ex.printStackTrace(); } }; } }

需要注意，这个异常处理器针对的是"没有返回值的void异步方法"。如果方法返回Future，异常是在调用future.get()时抛出的，需要调用方自己捕获处理。

还有一个细节：实现AsyncConfigurer接口的配置类，在容器中只能有一个。如果有多个类实现了这个接口，Spring会警告并随机选一个，容易产生不可预期的问题。所以我把线程池和异常处理配置放在同一个配置类里，统一管理。

4. 常见问题速查表与避坑实战技巧

4.1 高频问题对照表

我在实战中把常见的@Async相关问题整理成了速查表，方便遇到问题时快速定位：

4.2 排查顺序的独家建议

排查@Async失效问题，我建议按照"从外到内、从配置到代码"的顺序来做，不要上来就怀疑代码有问题。

先确认@EnableAsync是否开启，这是最低级的可能，但往往最容易被忽略。然后确认调用方是否通过Spring注入的Bean调用目标方法——这一步排除了自调用这一最大的坑。再确认目标方法修饰符和类修饰符是否满足代理条件。之后检查返回值类型是否正确，最后才看线程池和异常处理配置。

我见过一个团队排查了两天的问题，最后发现是启动类上压根没加@EnableAsync。因为最初写代码的人是在某个配置类上加的，后来配置类被重构删掉了，但所有人都在盯着@Async注解本身，完全没往@EnableAsync方向想。所以第一件事永远是确认基础开关。

4.3 异步日志链路追踪：MDC的坑

生产环境下排查异步问题时，遇到最多的问题是日志无法串联。主线程的traceId（链路追踪ID）在异步线程里丢了，排查问题时一条业务链路的日志散落在各处，根本没法串起来看。

这个问题的根因是日志框架的MDC（Mapped Diagnostic Context）是基于ThreadLocal实现的。ThreadLocal是线程私有的，主线程设置的traceId无法传递给子线程。异步方法在线程池中执行时，拿到的是一个全新的MDC上下文。

解决方案是在执行异步方法前手动传递MDC上下文。Spring从4.3开始提供了TaskDecorator，可以在任务提交前包装一下：

@Bean("taskExecutor") public Executor taskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); // ... 省略其他配置 executor.setTaskDecorator(new MdcTaskDecorator()); executor.initialize(); return executor; } public class MdcTaskDecorator implements TaskDecorator { @Override public Runnable decorate(Runnable runnable) { // 获取主线程的MDC上下文 Map<String, String> contextMap = MDC.getCopyOfContextMap(); return () -> { try { // 设置到异步线程中 MDC.setContextMap(contextMap); runnable.run(); } finally { // 执行完必须清理，否则线程池复用时会污染下个任务 MDC.clear(); } }; } }

这块代码有两个注意点：MDC.getCopyOfContextMap()可能返回null，需要做空判断；异步任务执行完后必须清理MDC，否则线程池复用线程时会把上个任务的traceId带到下个任务里，造成日志串线。

4.4 事务和异步混用的经验

@Async和@Transactional一起用的时候，坑特别多。我再强调一次：只要方法上标了@Async，Spring的事务管理就管不到它了，因为事务上下文是通过ThreadLocal绑定在线程上的。

正确做法是：异步方法内部自己开启事务。也就是说，把@Transactional标注在异步方法本身上，让事务在异步线程内开启和提交。比如：

@Async @Transactional public void processOrder() { // 这里的事务将在异步线程内开启 // 方法内任何运行时异常都会触发回滚 }

还有一种做法是事务放在调用方，异步方法只做"落库"之后的通知动作。这需要根据具体业务判断。我的原则是：事务的粒度和线程的生命周期保持一致，不要在A线程开启事务，然后期待在B线程里回滚。

4.5 定时任务里的@Async

Spring的@Scheduled定时任务和@Async组合使用时也有经典问题。比如：

@Component public class ScheduleTask { @Scheduled(cron = "0 0/5 * * * ?") public void execute() { // 定时任务方法 asyncService.doSomething(); // 调用其他Bean的异步方法，正常 } @Async public void selfAsync() { // 同类的异步方法，依然是自调用失效 } }

定时任务类内部的自调用问题，和Controller里this调用的原理完全一样。解决办法也是拆Bean，或者注入自己。

另外一个容易踩的坑：@Scheduled方法的执行线程默认是单线程的，如果一个定时任务执行时间过长，下一个任务会被阻塞排队。所以定时任务里调异步方法时，要确认定时任务本身不会因为异步化而被打乱节奏。

最后说几句体己话

盘完这几个坑，最想说的一点是：@Async的失效问题，本质上不是注解的问题，而是对Spring代理机制理解不透的问题。明白了代理是这一切生效的前提，很多"莫名其妙"的情况其实都有答案。

我个人的习惯是，在项目里定一条规矩：使用@Async的方法必须放在独立的Spring Bean中，且必须是public方法，调用方只能通过依赖注入的Bean来调用。代码评审时专门检查这一条，自调用直接打回。这条规矩执行下来，异步相关的问题基本上从源头就堵住了。

另外，每接手一个新项目，我第一件做的事就是看项目里有没有自定义线程池。没有的话，我会先按文中给出的基础配置补上去，再结合压测调优。别等上线了出现线程爆炸才来找原因，到那时候排查成本会高得多。

这个内容后续其实还可以扩展很多方向，比如如何基于CompletableFuture做异步任务编排、如何对异步任务做监控和告警、动态线程池参数调整中心的实现思路。如果你在项目里也遇到过类似的@Async诡异问题，希望这篇文章能给你提供一些排查和解决的思路。