企业官网建设流程全解析

1. 复盘背景：一个没跑起来的“异步任务”

先说结论：SpringBoot里@Async失效，十次有九次是自调用问题，剩下一次在代理、线程池或配置细节里。这个东西我第一次踩坑是在一个订单回调项目里，当时往老代码里加了个@Async给用户发短信，结果同步接口响应倒是快了，短信死活不发。翻日志、查线程、查配置，折腾了一晚上，最后发现是同一个类里的方法互相调用，代理直接被跳过，注解形同虚设。

这篇文章把@Async失效的完整复盘过程写出来，包括底层原理、排查手段、解决思路和线上避坑经验。适合谁看？刚把@Async用起来的SpringBoot开发，以及被异步不生效坑过、想彻底搞懂代理机制的中级开发者。看完你会明白：不是注解没用，是你没走到代理那条路上去。

2. 失效现象：先定位“哪里没执行”

2.1 线上问题描述

项目用的是SpringBoot 2.x，业务场景是用户注册后异步发送欢迎短信和初始化默认数据。代码大致长这样：

@Service public class UserRegisterService { @Autowired private UserMapper userMapper; public void register(User user) { userMapper.insert(user); sendWelcomeSms(user.getMobile()); initDefaultData(user.getId()); } @Async public void sendWelcomeSms(String mobile) { // 调用短信服务商接口，耗时约300ms smsProvider.send(mobile, "欢迎注册"); } @Async public void initDefaultData(Long userId) { // 初始化积分、优惠券等，耗时约500ms initService.init(userId); } }

压测时发现问题：register()方法整体耗时还是包含短信和初始化的时间，异步完全没有生效。再加上日志里根本没有异步线程的执行记录，可以初步判定：@Async注解压根没起作用，方法仍然在调用线程里同步执行。

2.2 初步排查：先排除配置缺失

我当时的排查顺序是先看配置，因为@Async要发挥作用，第一步必须开启异步支持。缺少@EnableAsync是最低级的错误，但也是线上最常出现的错误。检查了启动类：

@SpringBootApplication @EnableAsync public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

配置没漏。再看方法修饰符，@Async官方文档明确要求方法必须是public，两个方法都满足。@Async不能加在private、static、final方法上，这点我也确认过。

配置没问题，方法也符合要求，那问题只可能出在调用链路上。这时候我意识到，register()方法里直接调用了sendWelcomeSms()和initDefaultData()，这是典型的同类自调用（self-invocation）。

3. 失效根因：AOP代理机制是绕不开的坎

3.1 Spring是怎么“拦截”@Async的

要理解自调用为什么失效，得先明白Spring如何实现@Async。Spring在处理@Async时依赖的是AOP（面向切面编程）。容器启动后，Spring扫描到带有@Async或@EnableAsync声明的方法时，会为对应的Bean生成一个代理对象（Proxy）。

这个代理对象包裹着真实的目标对象。当你从外部注入这个Bean并调用方法时，你拿到的是代理对象，调用会先经过代理的拦截器链，代理再决定是同步执行还是丢给线程池异步执行。整个过程可以理解为：代理是一个“门卫”，@Async就是门卫手里的任务单，只有你从门口（代理）进去，门卫才会按任务单执行；你从内部侧门绕进去，门卫压根看不见你。

代码里体现得更直接。Spring容器中注册的Bean名称是userRegisterService，但真实对象是UserRegisterService$$EnhancerBySpringCGLIB之类的代理类。当其他类@Autowired注入这个Bean时，注入的是代理。

3.2 自调用为什么绕过了代理

回到问题代码。register()是UserRegisterService类自己的方法，它内部调用sendWelcomeSms()时，用的是Java隐式的this引用：

public void register(User user) { // ... this.sendWelcomeSms(user.getMobile()); // 实际上是 this 调用 }

this指向的是真实目标对象，不是代理对象。调用直接从真实对象的方法入口进入，代理拦截器根本没机会介入，@Async自然形同虚设。这也是AOP类功能（事务@Transactional、异步@Async、缓存@Cacheable）在同类自调用时集体失效的统一原因。

这个机制用一句话概括：AOP代理只拦截“外部进入”的调用，不拦截“内部自发”的调用。

3.3 不只是自调用：这些场景同样失效

排查过程中我整理了@Async可能失效的全部常见场景，不只是自调用这一种：

从构造函数里调用异步方法这个坑比较隐蔽。Spring创建Bean的顺序是先实例化目标对象，再通过BeanPostProcessor生成代理。构造方法执行时，代理还不存在，this是原始对象，注解肯定不生效。这种场景常见于在构造方法里做了太多初始化逻辑的“坏味道”代码。

3.4 顺带科普：JDK代理与CGLIB代理的区别

说到代理，面试常问的JDK动态代理和CGLIB代理也值得提一句，因为它们和@Async的失效有间接关系。Spring Boot 2.x默认采用CGLIB代理（spring.aop.proxy-target-class=true），生成的是目标类的子类代理。这就是为什么被代理的类不能被final修饰、被代理的方法不能是final方法——子类没法覆盖final方法。

JDK代理则要求目标类实现接口，代理对象是接口的实现类。如果项目里配置了proxy-target-class=false且目标类没有实现接口，代理就不会生成，@Async同样失效。

4. 排查实操：怎么确认代理到底有没有生效

4.1 看Bean的Class类型

最直接的验证方式：把注入的Bean的类名打出来。如果被代理了，打印出来的是UserRegisterService$$EnhancerBySpringCGLIB$$xxxxx，如果没被代理，打印的是com.example.service.UserRegisterService。

@Autowired private UserRegisterService userRegisterService; @PostConstruct public void checkProxy() { System.out.println(userRegisterService.getClass().getName()); }

输出如果带$$EnhancerBySpringCGLIB$$字样，说明代理已生成；如果就是原类名，说明代理没生成，得回头查配置和类定义。

4.2 用日志和线程名做运行时验证

代理生成了，也不代表@Async就一定生效。我习惯在异步方法里加一行线程名日志：

@Async public void sendWelcomeSms(String mobile) { log.info("当前线程: {}", Thread.currentThread().getName()); // 业务逻辑 }

Spring默认的异步执行器SimpleAsyncTaskExecutor创建的线程名是SimpleAsyncTaskExecutor-1这种格式，自定义线程池则以配置的threadNamePrefix开头。如果方法在Tomcat工作线程（比如http-nio-8080-exec-3）上打印日志，说明异步没生效，方法还在请求线程里同步跑。

4.3 断点调试看调用栈

如果上面两步还定位不了，直接上断点。在sendWelcomeSms()方法第一行打断点，触发调用后看调用栈（Call Stack）：

• 如果栈帧里出现UserRegisterService$$EnhancerBySpringCGLIB$$...和MethodInterceptor相关类，说明调用经过了代理，异步机制在正常工作。
• 如果栈帧直接是UserRegisterService.register()到UserRegisterService.sendWelcomeSms()，中间没有任何代理拦截器，那就是自调用，实锤。

4.4 一个容易忽略的点：启动类扫描范围

还有一次帮同事排查，@EnableAsync加在了启动类上，但启动类所在的包和业务Bean不在同一个包层级下。SpringBoot默认只扫描启动类所在包及其子包，结果业务Service压根没被扫描进容器，@Async自然失效。这种问题属于Bean都没有，比自调用更基础。

注意：@EnableAsync加在启动类上时，启动类位置决定了组件扫描范围，业务代码务必放在启动类所在包及子包下。

5. 解决思路：三种修复方案对比

5.1 方案一：把异步逻辑拆到独立Bean

这是我最推荐的做法，也是Spring官方隐含推荐的做法。把异步方法从原类中拆出去，放到专门的Bean里：

@Service public class SmsNotifyService { @Async public void sendWelcomeSms(String mobile) { smsProvider.send(mobile, "欢迎注册"); } } @Service public class UserRegisterService { @Autowired private SmsNotifyService smsNotifyService; public void register(User user) { userMapper.insert(user); smsNotifyService.sendWelcomeSms(user.getMobile()); } }

拆出来之后，UserRegisterService调用的是SmsNotifyService的代理对象，调用从外部进入，拦截器生效。这个方案的好处是职责清晰，顺带解决了类过大的问题，也避免了后续其他AOP注解在同一类里叠加的隐患。

5.2 方案二：注入自身代理

如果不想拆类，可以在类内部注入自己。Spring是允许的，因为容器里已经存在该Bean的代理：

@Service public class UserRegisterService { @Autowired private UserRegisterService self; public void register(User user) { userMapper.insert(user); self.sendWelcomeSms(user.getMobile()); } @Async public void sendWelcomeSms(String mobile) { // ... } }

注意：不能注入this，必须注入容器中的代理实例。字段名命名为self是为了语义清晰，避免和this混淆。这个方案虽然可行，但有一个隐患：如果类上有循环依赖，@Autowired自身可能会在处理循环依赖时出问题。Spring Boot 2.6之后默认不允许循环依赖，自注入在这种场景下可能直接启动报错。

5.3 方案三：AopContext.currentProxy()

Spring提供了AopContext，可以拿到当前代理对象：

@EnableAspectJAutoProxy(exposeProxy = true) @SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } // 业务代码 public void register(User user) { userMapper.insert(user); UserRegisterService proxy = (UserRegisterService) AopContext.currentProxy(); proxy.sendWelcomeSms(user.getMobile()); }

使用AopContext.currentProxy()的前提是配置了exposeProxy=true，否则拿到的是null。这个方案在业务代码里耦合了AOP上下文，不够优雅，而且每次调用都要强转，我个人只用在不方便拆类的历史代码里。值得一提的是，有人在网上用这个方案制造了“@Async失效的终极解法”的标题党内容，实际上它只是一个可选项，优先度排在拆分Bean之后。

5.4 三种方案怎么选

我的原则：能用方案一就不用方案二，方案三作为最后手段。拆分Bean不仅解决了@Async失效，还让异步逻辑可以被独立测试。异步方法本质上是独立的任务单元，它本来就不应该和同步方法挤在同一个类里。

6. 线程池配置：异步生效后还要防的坑

6.1 默认执行器的隐患

@Async生效之后，紧接着要面对的是线程池问题。SpringBoot默认情况下如果没有指定TaskExecutor，Spring会使用SimpleAsyncTaskExecutor作为兜底。这个执行器的特点是：来一个任务new一个线程，没有线程复用，没有队列上限。高并发下大量异步任务同时涌入，系统线程数会飙升，最后要么OOM，要么线程上下文切换把CPU打满。

一位朋友的电商项目就是血泪教训：给所有短信通知加了@Async，没配线程池，大促瞬间涌进来几十万条通知，线程数直接冲上几千，应用挂掉。所以@Async不是加了就完事，配套的线程池必须自己定义。

6.2 生产级线程池配置

推荐用ThreadPoolTaskExecutor配合AsyncConfigurer接口进行统一配置：

@Configuration @EnableAsync public class AsyncConfig implements AsyncConfigurer { @Bean(name = "taskExecutor") public ThreadPoolTaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); // 核心线程数：根据业务并发量评估 executor.setCorePoolSize(8); // 最大线程数：避免线程数无限膨胀 executor.setMaxPoolSize(16); // 队列容量：缓冲峰值流量 executor.setQueueCapacity(200); // 线程名前缀：方便日志排查 executor.setThreadNamePrefix("async-biz-"); // 拒绝策略：由调用线程执行，保证任务不丢失 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(60); executor.initialize(); return executor; } @Override public Executor getAsyncExecutor() { return taskExecutor(); } }

这套配置有几个关键点：

• 核心线程数corePoolSize：常驻线程数，按业务平均并发估算，启动就创建，空闲也不会回收。
• 最大线程数maxPoolSize：上限保护，防止线程无限制增长。
• 队列容量queueCapacity：核心线程忙不过来时，任务先排队，队满再扩容到最大线程数。这个顺序很多人搞反，以为先扩线程再排队，实际上是先排队后扩容。
• 拒绝策略CallerRunsPolicy：队列和线程都满了，任务不丢弃，由调用方线程（比如请求线程）同步执行。虽然这会拖慢请求，但比丢任务强。

还有一个隐藏细节：ThreadPoolTaskExecutor的initialize()方法。如果这个ExecutorBean被Spring管理，通常无需手动调用，Spring生命周期会自动初始化。但如果AsyncConfigurer.getAsyncExecutor()里返回的是一个未初始化的Executor，就可能在提交任务时抛NotInitializedException。我的习惯是统一配置标准写法，确保initialize()一定被调用。

6.3 多线程池的按需划分

业务大了之后，单一线程池不够用。短信通知、日志记录、数据同步，不同任务的重要性和耗时差异很大。如果共用线程池，低优先级的任务可能把高优先级的堵在队列里。可以拆分成多个Executor：

@Bean(name = "smsExecutor") public ThreadPoolTaskExecutor smsExecutor() { // 独立线程池配置 } @Bean(name = "dataSyncExecutor") public ThreadPoolTaskExecutor dataSyncExecutor() { // 独立线程池配置 }

使用时通过@Async("smsExecutor")指定：

@Async("smsExecutor") public void sendWelcomeSms(String mobile) { // ... }

7. 边界情况：@Async和事务、异常的爱恨纠葛

7.1 @Transactional与@Async组合的陷阱

有段时间我们有个需求：异步方法里要更新数据库状态。自然写成了这样：

@Async @Transactional public void updateOrderStatus(Long orderId, Integer status) { orderMapper.updateStatus(orderId, status); }

看起来没问题，但这里有个重要前提：**@Async方法的事务是独立开启的，与调用方事务无关。**如果是外部Bean调用这个异步方法，事务注解会生效，事务在异步线程内开启和提交。但如果在同类里自调用，@Async和@Transactional一起失效，数据库操作就在毫无事务保护的情况下执行。

还有一种情况更隐蔽：**异步线程里的@Transactional注解生效，但事务管理器用的数据源连接来自哪个线程，和请求线程完全不同。**如果业务代码里使用了ThreadLocal来传递数据源路由（比如多租户系统的DynamicDataSource），异步线程里拿不到调用方线程的上下文，事务可能落到错误的库上。这个问题我见过不止一次，排查起来非常费劲。

7.2 异步方法的异常丢失

同步方法里抛异常，调用方可以try-catch兜底。异步方法不同，任务被丢进线程池后，异常发生在线程池的工作线程里，调用方线程根本感知不到。而且默认情况下，ThreadPoolTaskExecutor会吞掉任务异常，日志里可能什么都没有。

要兜住异步异常，需要实现AsyncUncaughtExceptionHandler：

public class CustomAsyncExceptionHandler implements AsyncUncaughtExceptionHandler { @Override public void handleUncaughtException(Throwable ex, Method method, Object... params) { log.error("异步方法执行异常, method={}, params={}", method.getName(), params, ex); // 附加告警通知等 } }

在配置类里指定：

@Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return new CustomAsyncExceptionHandler(); }

注意：这个异常处理器只能捕获没有返回值（void）的异步方法的异常。如果@Async方法返回Future，异常会封装在Future.get()里抛出，需要调用方在获取结果时处理。使用CompletableFuture作为返回类型的话，异常在链式回调中传递，可以用exceptionally()或whenComplete()兜底。

7.3 日志链路追踪：MDC上下文丢失

异步线程拿到请求线程的日志链路ID（比如traceId）？拿不到。MDC（Mapped Diagnostic Context）是基于ThreadLocal实现的，线程池里的线程和请求线程不是同一个，子线程不会继承父线程的MDC内容。

这导致的直接后果：异步方法里打的日志搜不到对应的traceId，全链路追踪在异步节点断掉。临时解决可以提交任务前手动传递MDC内容：

@Async public void sendWelcomeSms(String mobile) { MDC.put("traceId", TraceIdHolder.get()); try { // 业务逻辑 } finally { MDC.remove("traceId"); } }

更优雅的做法是自定义TaskDecorator，在线程池执行任务前自动包装MDC上下文，这里不展开，知道有这个问题即可。

8. 常见问题速查与避坑清单

8.1 @Async失效排查表

8.2 项目规范建议

踩完这些坑，我在团队里立了几条规矩，分享出来供参考：

第一，@Async标注的方法必须放在独立Service中。代码评审时如果看到@Async和同步业务方法在同一个类里，直接打回。

第二，统一使用自定义线程池。项目里只允许用配置类中定义的Executor，不给Spring默认执行器兜底的机会。核心参数按业务评估，不允许拍脑袋填。

第三，异步方法必须有明确的日志和异常兜底。入口日志打线程名和参数，异常处理器必须实现，否则出问题连原因都查不到。

第四，能不用@Async就不用。这句话可能有点反直觉，但对于延迟要求不高的场景，比如历史数据归档、低频通知，用@Scheduled定时批量处理、或者消息队列异步解耦，可比@Async稳妥得多。@Async适合的就是调用方不关心结果的轻量级任务，用错地方就是给自己埋雷。

9. 复盘总结：从失效到原理，从修复到规范

这次排查下来，@Async失效的问题归根结底是对Spring AOP代理机制理解不透。代理只拦截外部调用，内部自调用直接穿透，这是所有AOP注解失效的共同底层逻辑。解决了这个问题，@Transactional、@Cacheable的同类自调用失效就都能触类旁通。

排查时最大的心得是不要迷信日志，先验证线程名。日志可能因为各种原因缺行、延迟、被过滤，但Thread.currentThread().getName()不会骗人。任何异步问题排查，第一步都是确认代码到底在哪个线程跑的，这一步确定之后，问题范围缩小一大半。

最后分享一个排查小技巧：如果项目里接入了actuator，可以通过/actuator/beans端点查看Bean的实际类型，快速确认某个Bean是否被代理。在被代理的Bean条目里，能看到$$EnhancerBySpringCGLIB标志，比写代码打印类名更快，也适合排查线上环境。这个习惯我现在一直保留着，排查Bean相关问题时比翻代码效率高得多。