1. 核心设计与适用场景解析1.1 Async 到底解决什么问题先聊一个最基础的问题为什么需要Async。大多数 Web 应用的请求处理链路是同步的——用户点击一个按钮请求打到 ControllerService 层执行逻辑返回响应。如果 Service 层里有一个耗时操作比如调用第三方接口、生成报表、发送通知用户的请求就会一直阻塞在那里等到所有事情做完才拿到响应。实测下来一个同步接口一旦出现一个 5 秒的第三方调用接口响应时间就奔着 5 秒去了用户体验和系统吞吐都很难看。Async做的事情就是把这类耗时且和主流程无关的业务逻辑“扔”到另一个线程里去执行主线程立刻返回。放在生活里类比就是你去餐厅吃饭点完菜之后不需要站在后厨门口等厨师做完再入座而是先回座位等着菜做好了服务员再给你端上来。对应到代码里Controller 请求线程就是“你”异步线程池就是“后厨”Async方法就是那道慢慢做的菜。但这里有个容易踩的误区Async不等于“快”。它恰恰是把一个任务的执行时间从“响应时间”里剥离出去让主链路不被拖慢。所以它适合的场景非常明确——非核心、可延迟、允许失败的任务。典型的就是操作日志记录。用户做了一个操作系统要记录日志这个操作挂了不能影响用户主流程。通知发送。注册成功后发邮件、发短信发送失败不能导致注册接口直接报错。数据同步。业务完成后把数据同步到搜索引擎、缓存或者其他系统。报表导出、文件生成。这类任务通常要花几秒甚至几十秒不可能让用户等着下载接口返回。1.2 什么时候不该用 Async我自己在实际项目中吃过亏的教训是不是所有耗时操作都适合异步化。有几种情况你用了Async反而会更糟第一主流程强依赖的操作不能异步。比如下单后扣减库存如果扣库存失败了这个订单就不能创建成功。这种操作必须和主事务在同一个线程里同步执行保证事务的原子性。把它丢到异步线程里主流程已经提交事务了异步线程再扣库存失败整个系统的数据一致性就崩了。第二对结果有强实时性要求的操作不能异步。比如用户查询订单状态你说“稍后再看”业务上无法接受那就得同步查询。第三异步线程池没有监控、没有异常兜底的情况下不能异步。异步线程池里的异常是拿不到调用方的try-catch的如果你只是把代码丢进异步线程出错了连日志都没留排查问题的成本会非常高。这一块后面异常处理那节详细讲。所以用Async的第一步不是写代码而是判断——这个操作真的适合异步吗我的习惯是先列三个问题主流程能忍受它失败吗用户能接受结果延迟出现吗异步执行失败了我们有补偿机制吗三个问题都回答“是”才考虑Async。2. 三大基础条件与应用范式2.1 启动异步能力EnableAsync 与代理机制想用Async第一件事是在配置类上加EnableAsync。这个注解是 Spring 异步功能的“总开关”它会在 Spring 容器启动时注册一个AsyncAnnotationBeanPostProcessor专门负责扫描Async标注的方法并为它们生成代理对象。没有这个注解你写的Async方法会被当成普通方法同步执行而且没有任何报错提示——这一点非常坑很多人配置完发现“异步没生效”排查半天才发现是漏了这一行。EnableAsync有几个常用属性值得说一下mode默认是AdviceMode.PROXY表示通过 JDK 动态代理或 CGLIB 代理实现。如果设置为ASPECTJ可以脱离 Spring 容器使用 AspectJ 织入但那是另一种玩法了常规项目用默认值即可。proxyTargetClass默认false即优先使用 JDK 动态代理。JDK 动态代理要求目标类有接口如果目标类没有接口Spring 会自动降级到 CGLIB。为了让代理机制更可靠我一般会显式设置proxyTargetClass true强制使用 CGLIB避免“有接口走 JDK 代理、没接口走 CGLIB”这种不一致带来的诡异问题。使用方式上启动类里直接标注示例SpringBootApplication EnableAsync public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }2.2 三种典型调用方式与自调用陷阱Async标注的位置不同调用方式也不同最常见的三种类型是Service public class AsyncTaskService { // 方式一无返回值fire-and-forget Async public void sendNotification(Long userId) { // 发送短信、邮件等 } // 方式二返回 Future可获取执行结果 Async public FutureString asyncGenerateReport(Long reportId) { return new AsyncResult(report_ reportId _done); } // 方式三返回 CompletableFuture支持异步编排 Async public CompletableFutureString asyncFetchUserData(Long userId) { // 模拟耗时操作 return CompletableFuture.completedFuture(user_ userId); } }三种方式该怎么选我的经验是没有返回值、不需要关心执行结果的用void。日志记录、通知发送这类场景最常用。需要拿到执行结果判断成功与否的用Future配合AsyncResult封装。注意Future.get()是阻塞的后面异常处理部分我会专门说这个坑。需要多个异步任务并行执行、全部完成后汇总结果的用CompletableFuture。这是单一Async注解不够用时的升级方案。上面三种用法其实都有一个隐藏前提异步方法必须通过 Spring 容器中的代理对象调用不能是同一个类内部的 this 调用。因为 Spring 的异步能力靠 AOP 代理实现实际调用流程是“调用方 → 代理对象 → 拦截器 → 真正的方法”如果你写的代码是Service public class OrderService { Async public void sendMessage() { // ... } public void createOrder() { // 自调用直接调用本类方法绕过代理异步失效 sendMessage(); } }这里createOrder()内部直接调用了sendMessage()因为调用方是this本身压根没有经过 Spring 容器里的代理对象所以Async的拦截器根本没机会执行sendMessage()会退化为同步调用而且没有任何错误日志。要解决这个问题可以注入自身代理Autowired自己来调用或者把异步方法拆到另一个 Bean 里。后面原理部分会讲透为什么。2.3 最小可运行示例先给你一个可以直接跑起来的最小实现后面再深入原理。AsyncTaskServiceService public class AsyncTaskService { private static final Logger log LoggerFactory.getLogger(AsyncTaskService.class); Async public void executeAsyncTask(String taskName) { log.info(异步任务开始执行{}线程{}, taskName, Thread.currentThread().getName()); try { Thread.sleep(2000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } log.info(异步任务执行完成{}, taskName); } }ControllerRestController RequestMapping(/api/tasks) public class TaskController { private final AsyncTaskService asyncTaskService; public TaskController(AsyncTaskService asyncTaskService) { this.asyncTaskService asyncTaskService; } GetMapping(/run/{name}) public String run(PathVariable String name) { log.info(请求进入主线程{}, Thread.currentThread().getName()); asyncTaskService.executeAsyncTask(name); return 任务已提交请求线程已返回; } }这样写完之后请求接口会立刻返回“任务已提交”而executeAsyncTask里的两秒耗时会放到线程池去执行。你可以观察到接口响应的线程名和异步任务执行的线程名是不一致的这就是异步生效的证据。3. 线程池选型与参数计算3.1 为什么必须自定义线程池很多人第一次用Async的时候直接不加参数就开跑看起来一切正常。但如果你不显式配置线程池Spring 会走它默认的SimpleAsyncTaskExecutor。这个实现有个致命问题——它每次执行异步任务都会 new 一个线程没有线程复用高并发下线程数会无限制增长最终导致系统资源耗尽。生产环境里这么用一旦流量上来轻则频繁创建线程导致 CPU 飙升重则 OOM属于必须避免的雷区。所以在正式项目里请务必自定义一个线程池 Bean并显式声明让Async使用它。具体做法是实现AsyncConfigurer接口重写getAsyncExecutor()或者直接定义一个ThreadPoolTaskExecutor类型的 BeanConfiguration public class AsyncConfig implements AsyncConfigurer { Bean(name taskExecutor) public ThreadPoolTaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(100); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix(async-task-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy()); executor.initialize(); return executor; } Override public Executor getAsyncExecutor() { return taskExecutor(); } }配置好后在Async里指定使用这个线程池Async(taskExecutor) public void executeAsyncTask(String taskName) { // ... }如果不指定线程池名称Spring 会优先找唯一的ExecutorBean如果项目里有多个ExecutorBean就必须显式指定名称否则会因为找不到唯一的执行器而抛出异常。实际项目里线程池往往不止一个所以我的习惯是每个Async方法都显式写上线程池名称避免依赖隐式绑定。3.2 核心参数怎么定ThreadPoolTaskExecutor的几个核心参数corePoolSize、maxPoolSize、queueCapacity、keepAliveSeconds和拒绝策略。很多刚接触线程池的读者会照着网上的配置抄一遍数字看着都差不多但并不知道这些值是怎么算出来的。这里我给一个可复用的推算逻辑。核心线程数corePoolSize的估算公式是期望的每秒任务数 × 单个任务耗时秒。假设系统峰值 QPS 为 200其中异步任务占比大概 20%也就是每秒 40 个任务每个任务平均耗时 50ms那么需要的活跃线程数就是40 × 0.05 2个。再留一些冗余落到 8 个核心线程比较合理。当然这只是粗算实际还要结合硬件资源比如机器是 8 核的核心线程数 8 是一个比较稳妥的起点。**队列容量queueCapacity**决定的是系统能承接多少“积压”的任务。如果核心线程都在忙新任务会先进入队列等待。队列容量设置太大任务会大量堆积内存压力大而且业务处理延时越来越高设置太小任务很快会进入扩容甚至被拒绝。我的参考值queueCapacity 核心线程数 × 单个任务执行时间秒 × 每秒最大任务数但实际项目中我通常采用queueCapacity 100起步再根据压测结果调整。任务量小、执行速度快队列小一点没关系任务量大、执行时间长队列就得放宽。最大线程数maxPoolSize的触发条件是核心线程全部忙、队列已经满了这个时候线程池才会启动扩容逻辑。这里有个非常容易踩的坑——并不是核心线程满了就立刻扩容而是先排队队列满了才扩容。所以corePoolSize8、queueCapacity100、maxPoolSize16的组合实际运行中线程数从 8 到 16 的“扩容”过程意味着队列里已经堆积了 100 个任务。换句话说线程数到 16 的时候系统已经处于满负荷运转状态了。我用一个模拟计算帮助理解。假设异步任务平均耗时 200ms核心线程数 8那么一个线程每秒能处理 5 个任务8 个线程每秒最多处理 40 个任务。如果每秒进来 60 个任务多出的 20 个任务就会积压到队列里队列 100 的容量大约能撑 5 秒。超过 5 秒后线程池认为“消化不过来了”才开始扩容出 16 个线程。16 个线程每秒能处理 80 个任务刚好消化掉 60 的流量。这套推算逻辑在容量规划里很有用你可以直接套用到自己的业务数据上。3.3 配置注入与常见坑线程池参数不建议写死在代码里放到配置文件application.yml里可以方便调整spring: task: execution: pool: core-size: 8 max-size: 16 queue-capacity: 100 keep-alive: 60 thread-name-prefix: async-task-这些配置会绑定到TaskExecutionPropertiesSpring Boot 会自动创建一个默认的ThreadPoolTaskExecutor。但这里有一个大坑TaskExecutionProperties自动配置的线程池 Bean 叫applicationTaskExecutor而你自定义Configuration时如果直接Async(taskExecutor)名称对不上异步方法会执行但不会走你配置的线程池参数。还有一点如果你在配置类里写了Bean(name taskExecutor)又用了EnableAsyncSpring 容器里会有多个TaskExecutor类型的 Bean这时 Spring 的异步拦截器只会选择唯一的ExecutorBean如果存在多个且你没有在Async里显式指定就会启动报错。另外提醒一下ThreadPoolTaskExecutor的initialize()方法不需要在Bean里手动调——Spring 容器在 Bean 初始化阶段会自动调用afterPropertiesSet()。不过我在前面的示例里写了executor.initialize()这只是为了在单元测试里单独new出来时确保线程池能正常使用项目代码里我会省略这一行交给 Spring 管理生命周期。4. 原理拆解调用背后发生了什么4.1 AOP 代理与拦截器如何介入从使用层面跳到原理层面理解Async真正执行的关键在于Spring AOP 代理机制。当 Spring 启动扫描到EnableAsync时会注册一个AsyncAnnotationBeanPostProcessor它是一个BeanPostProcessor在所有 Bean 实例化完成后介入检查这个 Bean 里有没有Async标注的方法。如果有就为这个 Bean 生成代理对象并往代理链上挂一个AnnotationAsyncExecutionInterceptor。这个拦截器是整个异步执行的核心。调用方实际上拿到的不是原始 Bean而是那个代理对象。当调用Async方法时请求首先进入代理对象代理对象再把调用委托给拦截器拦截器拿到对应的方法信息后会去查这个方法是否标注了Async接着取出注解里指定的线程池或者默认执行器构造一个Callable任务提交到线程池里最后直接返回。原方法真正的执行发生在异步线程里而不是当前调用线程里。这里就解释了为什么自调用会失效——OrderService.createOrder()里的this.sendMessage()this是原始 Bean 对象不是代理对象压根没有经过拦截器Async注解对它来说就是一个普通的、没有行为的标记。4.2 拦截器的完整执行流程AnnotationAsyncExecutionInterceptor的父类AsyncExecutionAspectSupport里有一个关键方法doSubmit它定义了异步执行的完整流程。我把核心步骤拆解给你看确定目标方法。从调用的Method对象中获取方法名和参数类型列表然后找这个方法上是否有Async注解。如果Async标在类上则类里所有方法都会被当成异步方法处理。确定执行器。Async(taskExecutor)如果指定了线程池名称就按名称从容器中拿对应的Executor对象如果没有指定走默认逻辑——先去容器里找唯一的ExecutorBean找不到再去AsyncConfigurer.getAsyncExecutor()里拿再没有就退化到SimpleAsyncTaskExecutor。提交任务并返回。有返回值的方法要分情况处理。返回值是Future类型则把任务包装成Callable提交到线程池返回Future给调用方返回值是void直接提交任务到线程池调用方立即返回null。异常处理。异步线程里如果抛出未捕获的异常调用方拿不到异常堆栈拦截器会把这些异常交给AsyncUncaughtExceptionHandler统一处理这个处理器也可以在AsyncConfigurer里自定义。从第 3 步可以看出来Async方法的返回值不是所有类型都能随便写——只有void、Future、CompletableFuture和ListenableFuture是 Spring 官方支持的返回类型。如果写成一个普通的String返回值Spring 无法在提交任务后立刻拿到结果所以在处理时不会当作异步方法而是把它当成同步方法调用执行——这也是个暗坑方法虽然标了Async但返回普通对象时不会报错异步却“静默失效”。4.3 再看自调用问题为什么一定失效前面已经提到过两次自调用问题这里再从原理上彻底讲透。Spring AOP 的代理有两种方式JDK 动态代理和 CGLIB。JDK 动态代理代理类实现了目标接口调用方法时通过InvocationHandler.invoke()转发到拦截器。要求目标类必须有接口。CGLIB 代理代理类是目标类的子类通过方法拦截器MethodInterceptor拦截方法调用。目标类没有接口时走下去。无论哪种方式代理对象和目标对象是两个不同的对象而且代理对象里持有目标对象的引用target。Spring 容器在注入AsyncTaskService到其他 Bean 时注入的实际上是代理对象。但this永远指向目标对象本身——这就是问题所在。你调this.sendMessage()时调用链是“目标对象 → 目标对象的方法”完全没有代理对象参与拦截器不会触发。要解决自调用问题我的建议是把异步方法拆到独立的 Bean 里。这样最干净也最容易理解。如果确实不想拆类可以用Autowired注入自己Service public class OrderService { Autowired private OrderService self; public void createOrder() { self.sendMessage(); } Async public void sendMessage() { // ... } }因为self是通过 Spring 容器注入的代理对象调用self.sendMessage()会正确触发拦截器。5. 异常处理与异步返回值5.1 void 方法 全局异常处理器Async方法一旦抛异常异常发生在异步线程里调用方拿不到。如果不对异常做兜底处理日志里连个记错都没有任务静默失败——这是异步系统最危险的地方。因此处理异步异常的第一原则是异步方法必须有专门的异常兜底。对于void返回类型的异步方法可以自定义AsyncUncaughtExceptionHandlerConfiguration public class AsyncConfig implements AsyncConfigurer { Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (throwable, method, params) - { // 记日志、上报监控 log.error(异步任务执行异常方法{}参数{}, method.getName(), Arrays.toString(params), throwable); }; } }这样所有异步线程里未被捕获的异常都会统一走到这个 handler 里你可以在这里做日志记录、告警通知、或者把任务信息写入失败表做后续补偿。需要特别说明这个 handler 只对void方法生效。如果异步方法返回的是Future或CompletableFuture异常会被包装进Future里留给调用方通过Future.get()或CompletionStage处理不会走到 handler。这一点在项目上经常有人搞混。5.2 Future 的 get() 阻塞陷阱Future能拿到异步执行结果但如果用错效果适得其反。最典型的错误写法Async public FutureString asyncGetResult() { Thread.sleep(3000); return new AsyncResult(done); } // 调用方 FutureString future asyncTaskService.asyncGetResult(); String result future.get(); // 板块3秒future.get()是一个阻塞调用它会让当前线程一直等待异步任务完成。很多人在 Controller 里这么写接口响应时间并没有任何提升因为主线程还是在等异步结果所谓的“异步”只剩下线程切换的开销。如果整体链路里只有一个异步任务同步做反而更快如果是为了多个异步任务并行执行正确写法是先把所有任务都提交出去最后统一get()ListFutureString futures new ArrayList(); for (Long id : userIds) { futures.add(asyncTaskService.asyncFetchData(id)); } // 此时所有任务已经并行提交再统一取结果 for (FutureString future : futures) { String result future.get(3, TimeUnit.SECONDS); // 建议加超时 }这样多个任务真正并行总耗时约等于最慢那个任务而不是所有任务耗时的总和。另外get()一定要加超时时间不加超时的话一旦异步任务被某个下游服务卡住调用方线程也会跟着无限期阻塞。5.3 CompletableFuture更强的异步编排能力单靠Async完成不了太复杂的编排比如“三个任务并行、都完成后汇总”、“一个成功就继续”、“异常时走降级”。CompletableFuture是更好的选择它可以和Async结合Service public class DataAggregationService { Async(taskExecutor) public CompletableFutureDouble fetchScore(Long userId) { // 模拟远程调用耗时不同 return CompletableFuture.completedFuture(Math.random() * 100); } Async(taskExecutor) public CompletableFutureInteger fetchLevel(Long userId) { return CompletableFuture.completedFuture(5); } }调用方做编排CompletableFutureDouble scoreFuture dataAggregationService.fetchScore(userId); CompletableFutureInteger levelFuture dataAggregationService.fetchLevel(userId); // 两个任务并行执行完成后合并结果 CompletableFutureString combined scoreFuture .thenCombine(levelFuture, (score, level) - score score , level level) .exceptionally(ex - { log.error(数据聚合失败, ex); return default; }); String result combined.join(); // join 也可以加超时get(2, TimeUnit.SECONDS)用AsyncCompletableFuture有个好处——异步线程池的管理逻辑统一在 Spring 容器里同时你在方法体里不需要自己创建线程池线程命名、参数配置、监控都能统一管理。6. 最佳实践与踩坑实录6.1 线程池隔离别把所有异步任务塞一个池子我见过很多项目把邮件发送、日志记录、数据同步、报表生成全部丢到同一个线程池里出问题的时候很难收拾一旦某一个任务的执行时间特别长把线程池里的线程全占满其他异步任务全部排队或直接被拒绝。这就像一条单车道混着自行车和泥头车自行车堵死后面泥头车也过不去。我的做法是按业务重要性和执行特征拆分线程池。比如taskExecutor通用任务池处理日志、通知等轻量任务。核心线程 8队列 100。reportExecutor报表导出池任务耗时往往几十秒核心线程数不用太多但队列容量要大。核心线程 4队列 500。syncExecutor数据同步池对接外部系统可能被外部接口拖慢。单独设一个池避免拖垮其他业务。每个线程池给不同的线程名前缀排查问题时一眼就能从线程 dump 里看出任务是哪个业务线的。6.2 子线程里的上下文传递问题Async把任务丢到另一个线程一个隐藏问题是上下文信息丢失。用户请求线程里设置的ThreadLocal比如登录用户信息、TraceId、当前的租户 ID在异步线程里默认是拿不到的。这对日志排查、权限校验影响很大——如果你在异步方法里打日志发现丢了用户 ID 或 TraceId别慌这是ThreadLocal的天然特性。解决方案有几种自己封装TaskDecorator。Spring 的ThreadPoolTaskExecutor提供了setTaskDecorator()方法提交任务时可以包一层把主线程的上下文快照复制到子线程执行完毕后再清理。这个方案通用性好。数据同步、日志记录这类场景可以在异步方法里只依赖方法参数传递必要信息不去读ThreadLocal最简单也最稳妥。更复杂的全链路线程上下文传递需要引入阿里巴巴的TransmittableThreadLocalTTL它解决的问题是线程池中的线程复用导致上下文串号的问题。我这边环境中已经做了严格的安全过滤不会涉及任何风险信息这里我们仅从技术角度理解如果你有高并发场景并且需要跨线程传递大量上下文信息这是一个值得研究的方案常规项目用TaskDecorator就够了。6.3 事务和异步一对需要谨慎处理的组合Async和Transactional同时使用时要注意执行线程的差异。Transactional的事务是绑定在调用线程上的它的实现原理是通过 AOP 在方法执行前后开启/提交事务。当Async把方法丢到新线程时事务的开启和提交也在新线程上完成所以事务本身是能生效的。真正的问题出在跨线程的数据一致性上。举个例子主线程里先往数据库写了一条订单记录事务还没提交然后调用异步方法去处理“这条订单记录”。如果异步线程立刻去查数据库可能查不到——因为主事务还没有提交数据对其他事务不可见。这会让异步方法里出现诡异的空指针或“数据不存在”异常。我的处理建议先提交主事务再触发异步任务。可以把异步调用放在事务提交后的回调里——Spring 提供了TransactionSynchronizationManager.registerSynchronization()可以在afterCommit阶段触发异步任务。异步方法里不要依赖调用方上下文中还没提交的数据如果必须依赖把数据作为参数传进异步方法并且确保数据已经落库。不要天真地给异步方法加上Transactional让它去改数据库异步任务的事务隔离级别、传播行为都容易在排查时把人搞晕。6.4 监控异步线程池必须纳入可观测范围异步系统最怕“任务丢了都不知道”。我强烈建议至少做三件事记录任务指标。对每个线程池监控活跃线程数、队列深度、任务提交数、完成任务数、拒绝任务数。Spring Boot 项目可以引入 Micrometer把线程池指标接入 Prometheus Grafana。在异步方法里打日志。日志至少包含任务进入时间、线程池名称、线程名、任务参数、执行结果。日志里带上 TraceId方便和调用主链路串起来排查。拒绝策略要明确。AbortPolicy是默认策略任务提交不进去会直接抛异常。你自己测试的时候可以试试接受不了就换成CallerRunsPolicy调用方线程自己执行或DiscardPolicy丢弃任务但要清楚每种策略的业务后果。我自己的习惯是业务上重要的异步任务不用DiscardPolicy宁可丢到死信队列或者记录失败表任务丢了就再也找不回来了。7. 常见问题排查速查7.1 高频问题与解决对照表现象可能原因解决方案异步方法同步执行没有走新线程漏加EnableAsync方法被同类内部自调用Async注解写在私有方法上检查启动类注解拆分 Bean私有方法改 public异步方法报“找不到唯一 Executor”容器里有多个ExecutorBeanAsync未指定线程池名称在Async(beanName)中显式指定线程池参数配置了但不生效配置的 Bean 名称和Async里写的名称不一致Bean 被多次初始化检查名称是否精确匹配避免同一个配置类里重复定义异步任务异常没有日志使用Future返回类型异常被包装进Future调用get()处理异常或者改用CompletableFuture回调异步线程里拿不到用户上下文ThreadLocal不跨线程传递使用TaskDecorator或方法参数传递项目启动后进程无法正常退出线程池没有关闭一直有活跃线程注册ShutdownHook调用executor.shutdown()任务被拒绝线程池队列已满达到最大线程数调大队列容量、核心线程数改用合理的拒绝策略7.2 排查走过的弯路再分享几个我实际排查过程中的心得。最常见的问题出在“看起来生效了实际没生效”。比如日志里明明看到异步任务执行了但执行线程名是http-nio-8080-exec-1说明任务还在请求线程里跑异步根本没生效。排查顺序是先查EnableAsync是否存在再查调用方式是不是本类自调用最后查方法修饰符Async不能标在private方法上标注了也没效果。这三步能解决八成“异步不生效”的问题。线程命名是排查的头号线索。给每个线程池起清晰的名字比如async-task-、report-pool-当线上出问题时你只要jstack看一眼线程名就能判断请求是卡在哪个线程池里。如果所有异步线程都叫pool-1-thread-1排查成本会高很多。默认的SimpleAsyncTaskExecutor是个隐藏炸弹。有次排查线上任务堆积时发现线程数已经到几千了就是因为某人在某个边缘逻辑里忘配线程池走了默认执行器。每次任务都新建线程创建了不销毁系统负载一直降不下来。从此我严格要求每个Async都必须显式指定线程池没有例外。7.3 优雅关闭让应用退出时任务不丢在微服务集群部署里应用发布、缩容是常态。如果直接用kill -9杀掉进程线程池里正在执行的任务会直接中断。更优雅的做法是处理关闭流程Configuration public class AsyncShutdownConfig { PreDestroy public void shutdownExecutors() { // 假设有多个线程池逐一关闭 // 等待已提交任务最多 30 秒 // executor.shutdown(); // try { executor.awaitTermination(30, TimeUnit.SECONDS); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }在 Spring Boot 项目里配置好PreDestroy或者监听ContextClosedEvent在关闭时先停止接收新任务再等待已有任务执行完成或超时。这块做得好能避免很多线上“发布后丢消息、丢任务”的问题。最后再聊一点实际感触。Async看着只是一个注解真正用它的时候要考虑的东西远超“异步执行”这四个字。线程池参数要根据业务流量去测算异常不要指望调用方兜底线程上下文要在设计时就规划好传递方式。我最初接手一个老项目时里面的异步任务是到处乱用的有的方法耗时很久还占着通用线程池有的自调用根本没有任何异步效果修了一段时间才慢慢理清楚。如果这篇文章的某个思路能帮你少踩一个坑那就值了。异步是个好工具但它只适合用在真正“解耦、加速主链路”的地方用好它需要从整体架构的角度去做设计而不是为了用而用。