1. 项目概述SpringBoot异步调用的核心需求与使用价值1.1 核心需求解析先说一个我在实际项目里常遇到的场景一个对外提供的接口内部要写操作日志、发通知消息、调用外部系统的接口如果这些都放在请求线程里同步执行接口响应时间会被拖到几百毫秒甚至几秒。用户在浏览器那边等得直跺脚实际上核心业务早就处理完了后面的日志、通知全是可有可无的“加分项”。这时候异步调用就派上用场了。所谓异步调用简单说就是让方法在独立的线程中执行调用方发起调用后立即返回不等待被调用方法执行完毕。SpringBoot里做这件事最主流的方式就是Async注解配合EnableAsync开启异步支持。这套方案的核心价值有三个降低接口响应时间把耗时操作挪到后台线程执行主线程快速返回结果。实现业务逻辑解耦核心业务和辅助业务分离互不阻塞。提高系统吞吐量线程不再干等着IO或者慢操作可以腾出来处理新请求。这篇文章适合谁看已经会用SpringBoot写CRUD、想优化接口性能的后端开发以及做毕业设计或企业项目时需要处理异步需求的同学。我会从底层线程模型讲起把Async的正确用法、线程池配置参数、事务与异步的组合玩法、以及一堆实际踩坑经验全部展开讲透。1.2 为什么推荐用Async而不是自己new Thread很多新手看到异步的第一反应是写new Thread(() - {...}).start()这在我早期的项目里也干过。后来发现这样写问题很大每次请求都创建一个线程线程的生命周期完全没有管理并发量一上来系统资源就吃紧。更麻烦的是没有统一的线程池监控、没有拒绝策略、没有异常处理机制线上出了问题排查起来非常痛苦。SpringBoot的Async本质上也是走线程池但它帮你把“提交任务到线程池”这件事封装好了。你只需要在方法上加一个注解Spring容器就会自动把方法调用包装成一次线程池任务提交。这意味着线程复用、队列缓冲、拒绝策略、异常处理这些都是可配置、可控的比手搓线程靠谱得多。还有一个原因是Spring的异步抽象和框架内的其他能力是打通的Async可以和Transactional组合使用可以通过CompletableFuture实现异步结果组装可以配合ApplicationEvent做异步事件发布。这些都是new Thread做不到的“基础设施红利”。2. 最小可用的异步调用实现2.1 开启异步支持EnableAsync先看最基础的两个注解。要在SpringBoot项目里启用异步功能第一步是在配置类或者启动类上加EnableAsyncSpringBootApplication EnableAsync public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }EnableAsync做的事很简单向容器中注册一个AsyncAnnotationBeanPostProcessor这个后置处理器会在Spring容器启动时扫描所有Bean发现有方法标注了Async就为该Bean生成一个代理对象。后续调用带Async注解的方法时实际走的是代理逻辑把方法调用提交到线程池执行而不是直接执行原方法。有一点需要注意EnableAsync默认情况下查找的线程池是ThreadPoolTaskExecutor如果没有自定义的线程池BeanSpring会使用SimpleAsyncTaskExecutor。这个名字看着挺友好实际上是个“大坑”——它不会复用线程每次都新开一个线程执行任务并发高的情况下性能很差。所以生产环境一定要自定义线程池这部分我在第3章重点讲。2.2 使用Async标注异步方法在需要异步执行的方法上加上Async注解即可。这里先给一个最简单的例子Service public class OrderService { Async public void sendSms(String phone, String content) { System.out.println(发送短信开始线程 Thread.currentThread().getName()); // 模拟耗时操作 try { Thread.sleep(2000); } catch (InterruptedException e) { Thread.currentThread().setInterrupted(); } System.out.println(短信发送完成线程 Thread.currentThread().getName()); } }调用方直接注入OrderService调用sendSms方法调用会立即返回实际执行在Spring管理的线程池中完成。观察控制台输出的线程名会发现执行线程不再是请求进来的http-nio-xxx线程而是线程池线程比如async-thread-1。这里要特意说明一个新手最容易踩的坑Async方法必须通过代理对象调用才生效。也就是说如果你在一个类内部写一个方法在同类中直接调用这个方法异步不会生效因为内部调用走的是this指向的本类对象不是Spring生成的代理对象。后面问到的“Async不生效”十有八九都是这个原因。2.3 带返回值的异步调用有些异步任务需要返回结果给调用方这时候方法返回值可以设为Future或者CompletableFuture。最简单的写法是FutureAsyncResultService public class DataService { Async public FutureString fetchData() { try { Thread.sleep(1500); } catch (InterruptedException e) { Thread.currentThread().setInterrupted(); } return new AsyncResult(数据加载完成); } }调用方拿Future后调用get()获取结果。需要注意的是get()是阻塞操作调用它会等异步任务执行完才返回所以不要把get()放在请求线程的关键路径上否则异步的“快速响应”意义就没了。更推荐的做法是用CompletableFuture可以做回调编排Async public CompletableFutureString asyncMethod() { try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().setInterrupted(); } return CompletableFuture.completedFuture(处理完成); }调用方可以这样用CompletableFutureString future dataService.asyncMethod(); // 不阻塞等结果出来再处理 future.thenAccept(result - System.out.println(结果 result));这种方式在“同时调用多个接口并聚合结果”的场景特别有用可以大幅度缩短整体等待时间。3. 自定义线程池异步调用稳定运行的关键3.1 默认线程池的缺陷与自定义必要性前面提到不在容器中定义线程池时Spring用的兜底实现是SimpleAsyncTaskExecutor。这个类的execute方法每次调用都会new Thread()创建一个新线程没有线程复用也没有最大并发数限制。一旦有大量异步任务涌入系统会创建大量线程内存被挤爆最终触发OutOfMemoryError。即使在Spring Boot 2.1以上版本中TaskExecutionAutoConfiguration会自动配置一个ThreadPoolTaskExecutor作为默认ApplicationTaskExecutor这个自动配置的线程池参数也比较保守核心线程数8最大线程数Integer.MAX_VALUE你没看错任务队列满了就直接无限加线程队列容量默认也是Integer.MAX_VALUE相当于无界队列。这意味着高并发下线程数会失控对资源管理很不利。所以生产环境必须自定义线程池Bean并且把核心参数写到配置文件里方便后续调优。3.2 核心线程池参数详解自定义线程池时最关键的四个参数是核心线程数、最大线程数、队列容量、拒绝策略。我以实际项目为例说明参数怎么定。Configuration public class AsyncConfig { Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心线程数正常情况下保持存活的线程数 executor.setCorePoolSize(10); // 最大线程数任务量高峰队列满时能创建的最大线程数 executor.setMaxPoolSize(50); // 队列容量核心线程都在忙时新任务进入队列等待 executor.setQueueCapacity(200); // 线程名称前缀方便日志排查 executor.setThreadNamePrefix(async-thread-); // 拒绝策略队列和最大线程都满时的兜底策略 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); // 线程空闲存活时间 executor.setKeepAliveSeconds(60); executor.initialize(); return executor; } }核心参数怎么定我给一个经验参考公式核心线程数一般设为CPU核心数 1如果是IO密集型任务可以适当调大比如CPU核心数 * 2。大多数业务系统属于IO密集型核心线程数设在10~20之间都合理。最大线程数核心线程数 * 24倍具体看任务量和系统资源。队列容量取决于你愿意让多少任务排队等待。队列填满后线程池才会创建新线程直到最大线程数所以队列上限决定“积压容忍度”。拒绝策略四种RejectedExecutionHandler里CallerRunsPolicy是最推荐的。它不会丢弃任务而是让提交任务的调用线程自己执行起到天然“降速”的效果。当Async方法上没有指定执行器名称时Spring会查找容器中的TaskExecutor类型的Bean或者名为taskExecutor的Bean。如果只定义一个线程池Bean并且为它起了名字记得在Async注解中显式指定执行器名称不然可能报找不到执行器的错。3.3 通过application.yml配置线程池参数把参数写死到Java代码里不便于调优我习惯用配置文件方式管理。先在配置类里读取Environment属性# application.yml async: task: core-pool-size: 10 max-pool-size: 50 queue-capacity: 200 thread-name-prefix: async-thread- keep-alive-seconds: 60Configuration public class AsyncConfig { Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor( Value(${async.task.core-pool-size}) int corePoolSize, Value(${async.task.max-pool-size}) int maxPoolSize, Value(${async.task.queue-capacity}) int queueCapacity, Value(${async.task.thread-name-prefix}) String threadNamePrefix, Value(${async.task.keep-alive-seconds}) int keepAliveSeconds) { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(corePoolSize); executor.setMaxPoolSize(maxPoolSize); executor.setQueueCapacity(queueCapacity); executor.setThreadNamePrefix(threadNamePrefix); executor.setKeepAliveSeconds(keepAliveSeconds); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }这样改配置不需要动代码运维调整参数更方便。3.4 多个线程池的场景业务隔离有的项目里异步任务类型差异很大一种是轻量级日志写入另一种是重量级数据同步。共用一个线程池会导致资源互相抢占数据同步任务堵满了队列日志写入排队等半天影响主流程的日志时效。这种情况最好的做法是按业务域拆分线程池。比如定义两个BeanBean(logTaskExecutor) public ThreadPoolTaskExecutor logTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(2); executor.setMaxPoolSize(5); executor.setQueueCapacity(100); executor.setThreadNamePrefix(log-thread-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy()); executor.initialize(); return executor; } Bean(syncTaskExecutor) public ThreadPoolTaskExecutor syncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(100); executor.setThreadNamePrefix(sync-thread-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }日志类任务用DiscardPolicy日志丢了影响不大不能拖垮业务数据同步用CallerRunsPolicy必须保证数据不丢。线程池隔离这个细节很多初学同学容易忽略等到线上出问题才后悔。4. 异常处理与事务组合4.1 异步方法异常处理Async方法是有返回值时异常会包装在Future或CompletableFuture里通过get()或whenComplete能拿到异常。没有返回值时异常默认被吞掉不会向调用方抛出。这就可能导致你异步任务失败了却不自知。解决思路是给异步任务配置统一的异常处理器。Spring的AsyncConfigurer接口提供了getAsyncUncaughtExceptionHandler方法可以在里面统一捕获并记录日志Configuration EnableAsync public class AsyncExceptionConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-thread-); executor.initialize(); return executor; } Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (throwable, method, params) - { System.err.println(异步方法调用异常方法 method.getName() 参数 Arrays.toString(params)); throwable.printStackTrace(); }; } }把抛出的异常信息打印到日志里配合报警通知基本上问题就不会漏了。也可以把异常信息发到消息队列或钉钉群但是要注意处理器里不能写太重的逻辑避免影响异步线程性能。4.2 Async与Transactional的联动效应有些接口需要异步执行数据库写入操作又想保证数据一致性。有人会直接在Async方法上再加TransactionalAsync Transactional public void updateUserInfo(User user) { // 数据库更新操作 }这样写有一个重要前提两注解同时生效时事务必须由代理对象发起。Async本身经过代理提交到线程池执行Transactional同样需要代理对象来开启事务在异步方法上组合使用时实际执行链路是从线程池线程开始的事务管理器基于线程绑定连接所以事务是生效的。不过有个细节要注意事务回滚只针对方法内抛出的异常而异步方法里如果你自己try-catch吞掉了异常事务自然就不会回滚。所以异常要么不处理要么处理完重新抛出。这里再提醒一句不要把大事务放在异步方法里。异步任务的数据写入如果耗时很长事务在后台线程中长时间占着数据库连接连接池容易被耗尽。我一般建议异步方法只负责轻量级的数据写操作重操作拆分成小任务逐步处理。5. 异步调用中的常见问题排查实录5.1 Async不生效的4个经典原因这个问题被问到的频率最高。排查的时候先看这几点第一启动类有没有加EnableAsync。漏了这个注解Async完全不会生效。第二方法是不是通过代理调用。在同一个类里this.callAsyncMethod()这种内部调用不会经过代理注解失效。解决方式是拆分一个单独的Service类注入后再调用。第三方法是不是static或private。Spring的AOP是基于动态代理实现的private方法和static方法都没法被代理拦截。这个坑最隐蔽因为IDE不会提示错误运行时也不会报异常就是不异步。第四线程池有没有被正确指定。如果容器里有多个线程池BeanAsync没指定名称会搜索不到合适的Executor。推荐的写法是在Async(asyncTaskExecutor)中显式指定Bean名称。5.2 线程池队列积压与任务丢失自定义线程池后最常见的线上问题是队列积压。症状是异步任务延迟很高或出现TaskRejectedException。排查时关注几点核心线程数是不是远低于任务高峰期所需的并发数量任务全部排队了。队列容量设置是否偏大导致消息积压还没触发扩容线程。拒绝策略是不是AbortPolicy是的话任务直接丢弃并抛出异常。我遇到一次严重事故定时任务每5分钟扫一次全量用户发营销短信线程池队列容量设的50一次进来几千个任务全部排队等着营销短信延迟了半个多小时才发完。后来把定时任务改成分批调用异步方法每批200个瞬间就顺畅了。所以异步不是无脑用任务量的控制同样重要。5.3 异步线程中ThreadLocal信息丢失ThreadLocal存用户信息的场景在Web应用里很常见过滤器把用户信息塞进ThreadLocal业务方法取出来用。但异步线程是线程池里的其他线程和请求线程不是同一个请求线程上的ThreadLocal数据自然就丢了。处理方式有几种在提交异步任务之前把需要的上下文信息作为参数显式传给异步方法。使用TransmittableThreadLocal阿里开源的一个TTL组件在线程池提交任务时自动拷贝父线程的变量。我目前在项目中用的是第二种方式给ThreadPoolTaskExecutor包装一下通过自定义TaskDecorator实现上下文传递Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-thread-); executor.setTaskDecorator(runnable - { // 这里可以包装Runnable把需要的上下文快照传到异步线程中 return () - { try { runnable.run(); } finally { // 清理相关上下文 } }; }); executor.initialize(); return executor; }ThreadPoolTaskExecutor提供了setTaskDecorator方法专门用来做这种上下文传递非常方便。如果你是SpringBoot 2.x以上版本这种方式比什么方案都省事。5.4 如何确定异步确实生效了写完了不知道怎么验证有没有真正异步执行我分享一个最简单的验证思路在调用方加一行打印“调用结束”在被调异步方法开头打印当前线程名。如果控制台显示先输出“调用结束”随后才输出异步方法的线程日志并且线程名跟请求线程不一样说明异步生效了。另一个验证思路是在异步方法里Thread.sleep(3000)调接口看响应时间如果接口毫秒级返回说明异步生效如果接口耗时3秒以上说明方法还是在同步执行。这个方法在开发联调阶段非常实用基本一眼就能发现问题。6. 工具选型与进阶玩法6.1 Spring事件监听与异步结合Spring容器的ApplicationEvent机制天然适配异步场景。定义了事件和监听器public class OrderCreateEvent extends ApplicationEvent { private String orderId; // getter/setter }监听器方法上直接加AsyncComponent public class OrderEventListener { EventListener Async(asyncTaskExecutor) public void onOrderCreate(OrderCreateEvent event) { // 异步处理订单创建后的通知、日志等 } }这种组合在业务上非常有价值发布订单创建事件后主流程不用关心后面有多少监听器新增监听器也不需要改动原业务代码解耦很彻底。事件监听异步执行的注意点监听器默认同步执行加了Async才会扔到线程池如果监听器内部有自定义异常处理逻辑记得在监听器方法内部捕获处理避免传入到Spring事件广播线程影响其他监听器执行。6.2 CompletableFuture编排多个异步任务如果一次要调用多个外部系统最后汇总结果CompletableFuture是利器。结合Async可以写“并行收集结果”的代码Async(asyncTaskExecutor) public CompletableFutureDouble fetchPriceFromA() { // 调用A系统 return CompletableFuture.completedFuture(100.5); } Async(asyncTaskExecutor) public CompletableFutureDouble fetchPriceFromB() { // 调用B系统 return CompletableFuture.completedFuture(98.6); } // 调用方汇总 CompletableFutureDouble futureA priceService.fetchPriceFromA(); CompletableFutureDouble futureB priceService.fetchPriceFromB(); CompletableFuture.allOf(futureA, futureB).join(); Double totalPrice futureA.get() futureB.get();这里allOf(futureA, futureB).join()会等待两个任务都完成整体耗时取决于最慢的那个任务相比串行调用节省了一半时间。任务多的时候效果更明显。有一个注意点注意线程池任务数量要匹配并发调用的数量。你一次性提交10个任务线程池核心线程只有5剩下5个排队整体耗时不会提高一倍可能就是两个批次的时间。6.3 监控线程池指标线程池配置完不监控等于白配。我在生产环境会给线程池加简单的监控定时打印核心指标。Scheduled(fixedRate 60000) public void printThreadPoolMetrics() { ThreadPoolTaskExecutor executor (ThreadPoolTaskExecutor) SpringContextHolder.getBean(asyncTaskExecutor); ThreadPoolExecutor threadPoolExecutor executor.getThreadPoolExecutor(); int activeCount threadPoolExecutor.getActiveCount(); long taskCount threadPoolExecutor.getTaskCount(); long completedTaskCount threadPoolExecutor.getCompletedTaskCount(); int queueSize threadPoolExecutor.getQueue().size(); System.out.println(活跃线程: activeCount , 总任务: taskCount , 完成任务: completedTaskCount , 队列剩余: queueSize); }getQueue().size()是最关键的一个指标它告诉你当前有多少任务在堆积。如果长期排队任务数超过队列容量的50%就要考虑扩线程或者拆分任务了。生产环境建议用Micrometer把这些指标暴露到Prometheus配好告警规则比人工看日志高效得多。7. 一个完整的异步调用配置实战参考这里把前面的内容汇总成一个能直接落地的完整方案大家可以照着抄。7.1 工程结构组织com.example.demo ├── Application.java ├── config │ └── AsyncConfig.java ├── service │ ├── OrderService.java │ └── NotifyService.java └── controller └── OrderController.java异步线程池配置单独放一个config包不要和其他配置类混在一起方便管理。7.2 核心代码展示首先是线程池配置类Configuration EnableAsync public class AsyncConfig { Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix(async-thread-); executor.setTaskDecorator(runnable - { MapString, String context TraceIdHolder.get(); return () - { TraceIdHolder.set(context); try { runnable.run(); } finally { TraceIdHolder.clear(); } }; }); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }业务服务类Service public class OrderService { Async(asyncTaskExecutor) public void processOrder(Order order) { // 更新订单状态 // 发送通知消息 // 记录流水日志 } }Controller调用RestController RequestMapping(/order) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } PostMapping(/create) public Result createOrder(RequestBody Order order) { // 核心订单入库逻辑 // 异步处理辅助业务 orderService.processOrder(order); return Result.success(); } }7.3 配置要点回顾这套配置的核心要点我总结成一张速查表配置项推荐值/做法说明核心线程数10~20IO密集型可适当多配最大线程数核心线程数的2~4倍防止线程无限膨胀队列容量100~500给任务排队留缓冲拒绝策略CallerRunsPolicy宁可调用线程执行也不想丢任务线程名前缀业务名-thread-日志排查关键依据TaskDecorator传递TraceId/用户上下文解决ThreadLocal丢失问题监控定时打印队列大小/活跃线程数提前发现线程池过载风险8. 写在最后一些过来人的经验体会我大概从Spring Boot 1.x时代就开始用Async中间踩过的坑比写出来的还多。刚开始最迷惑的是“注解加上了为什么不生效”后来慢慢理解了Spring代理机制很多问题其实都是同一个根因——没走代理。现在写代码前我都会先问自己一句这个方法会被谁调用是不是从另一个Bean注入进来的另外一个很重要的体会是异步不是性能优化的万能药。接口慢了先定位慢在哪如果是数据库查询慢、外部接口慢异步确实很有效。但如果业务逻辑本身就依赖实时结果异步就不合适。拿不准的时候就选同步同步至少不会出现“任务丢了还找不到”的情况。线程池参数也没有一劳永逸的最优值只能根据业务压测慢慢调整。建议每次调整后都记录当时的参数值和线上表现积累一两轮数据之后你的参数直觉会准很多。这套配置我放在项目的基座里已经稳定跑了一年多核心接口的p99响应时间从2.3秒降到了320毫秒。只要按文章里的配置思路来再加上监控指标你的异步调用方案也会很稳。如果大家在落地过程中遇到“异步任务丢失”“线程池满”之类的问题回头看一下拒绝策略和任务量控制这两块大概率就能找到原因。
1. 项目概述SpringBoot异步调用的核心需求与使用价值1.1 核心需求解析先说一个我在实际项目里常遇到的场景一个对外提供的接口内部要写操作日志、发通知消息、调用外部系统的接口如果这些都放在请求线程里同步执行接口响应时间会被拖到几百毫秒甚至几秒。用户在浏览器那边等得直跺脚实际上核心业务早就处理完了后面的日志、通知全是可有可无的“加分项”。这时候异步调用就派上用场了。所谓异步调用简单说就是让方法在独立的线程中执行调用方发起调用后立即返回不等待被调用方法执行完毕。SpringBoot里做这件事最主流的方式就是Async注解配合EnableAsync开启异步支持。这套方案的核心价值有三个降低接口响应时间把耗时操作挪到后台线程执行主线程快速返回结果。实现业务逻辑解耦核心业务和辅助业务分离互不阻塞。提高系统吞吐量线程不再干等着IO或者慢操作可以腾出来处理新请求。这篇文章适合谁看已经会用SpringBoot写CRUD、想优化接口性能的后端开发以及做毕业设计或企业项目时需要处理异步需求的同学。我会从底层线程模型讲起把Async的正确用法、线程池配置参数、事务与异步的组合玩法、以及一堆实际踩坑经验全部展开讲透。1.2 为什么推荐用Async而不是自己new Thread很多新手看到异步的第一反应是写new Thread(() - {...}).start()这在我早期的项目里也干过。后来发现这样写问题很大每次请求都创建一个线程线程的生命周期完全没有管理并发量一上来系统资源就吃紧。更麻烦的是没有统一的线程池监控、没有拒绝策略、没有异常处理机制线上出了问题排查起来非常痛苦。SpringBoot的Async本质上也是走线程池但它帮你把“提交任务到线程池”这件事封装好了。你只需要在方法上加一个注解Spring容器就会自动把方法调用包装成一次线程池任务提交。这意味着线程复用、队列缓冲、拒绝策略、异常处理这些都是可配置、可控的比手搓线程靠谱得多。还有一个原因是Spring的异步抽象和框架内的其他能力是打通的Async可以和Transactional组合使用可以通过CompletableFuture实现异步结果组装可以配合ApplicationEvent做异步事件发布。这些都是new Thread做不到的“基础设施红利”。2. 最小可用的异步调用实现2.1 开启异步支持EnableAsync先看最基础的两个注解。要在SpringBoot项目里启用异步功能第一步是在配置类或者启动类上加EnableAsyncSpringBootApplication EnableAsync public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }EnableAsync做的事很简单向容器中注册一个AsyncAnnotationBeanPostProcessor这个后置处理器会在Spring容器启动时扫描所有Bean发现有方法标注了Async就为该Bean生成一个代理对象。后续调用带Async注解的方法时实际走的是代理逻辑把方法调用提交到线程池执行而不是直接执行原方法。有一点需要注意EnableAsync默认情况下查找的线程池是ThreadPoolTaskExecutor如果没有自定义的线程池BeanSpring会使用SimpleAsyncTaskExecutor。这个名字看着挺友好实际上是个“大坑”——它不会复用线程每次都新开一个线程执行任务并发高的情况下性能很差。所以生产环境一定要自定义线程池这部分我在第3章重点讲。2.2 使用Async标注异步方法在需要异步执行的方法上加上Async注解即可。这里先给一个最简单的例子Service public class OrderService { Async public void sendSms(String phone, String content) { System.out.println(发送短信开始线程 Thread.currentThread().getName()); // 模拟耗时操作 try { Thread.sleep(2000); } catch (InterruptedException e) { Thread.currentThread().setInterrupted(); } System.out.println(短信发送完成线程 Thread.currentThread().getName()); } }调用方直接注入OrderService调用sendSms方法调用会立即返回实际执行在Spring管理的线程池中完成。观察控制台输出的线程名会发现执行线程不再是请求进来的http-nio-xxx线程而是线程池线程比如async-thread-1。这里要特意说明一个新手最容易踩的坑Async方法必须通过代理对象调用才生效。也就是说如果你在一个类内部写一个方法在同类中直接调用这个方法异步不会生效因为内部调用走的是this指向的本类对象不是Spring生成的代理对象。后面问到的“Async不生效”十有八九都是这个原因。2.3 带返回值的异步调用有些异步任务需要返回结果给调用方这时候方法返回值可以设为Future或者CompletableFuture。最简单的写法是FutureAsyncResultService public class DataService { Async public FutureString fetchData() { try { Thread.sleep(1500); } catch (InterruptedException e) { Thread.currentThread().setInterrupted(); } return new AsyncResult(数据加载完成); } }调用方拿Future后调用get()获取结果。需要注意的是get()是阻塞操作调用它会等异步任务执行完才返回所以不要把get()放在请求线程的关键路径上否则异步的“快速响应”意义就没了。更推荐的做法是用CompletableFuture可以做回调编排Async public CompletableFutureString asyncMethod() { try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().setInterrupted(); } return CompletableFuture.completedFuture(处理完成); }调用方可以这样用CompletableFutureString future dataService.asyncMethod(); // 不阻塞等结果出来再处理 future.thenAccept(result - System.out.println(结果 result));这种方式在“同时调用多个接口并聚合结果”的场景特别有用可以大幅度缩短整体等待时间。3. 自定义线程池异步调用稳定运行的关键3.1 默认线程池的缺陷与自定义必要性前面提到不在容器中定义线程池时Spring用的兜底实现是SimpleAsyncTaskExecutor。这个类的execute方法每次调用都会new Thread()创建一个新线程没有线程复用也没有最大并发数限制。一旦有大量异步任务涌入系统会创建大量线程内存被挤爆最终触发OutOfMemoryError。即使在Spring Boot 2.1以上版本中TaskExecutionAutoConfiguration会自动配置一个ThreadPoolTaskExecutor作为默认ApplicationTaskExecutor这个自动配置的线程池参数也比较保守核心线程数8最大线程数Integer.MAX_VALUE你没看错任务队列满了就直接无限加线程队列容量默认也是Integer.MAX_VALUE相当于无界队列。这意味着高并发下线程数会失控对资源管理很不利。所以生产环境必须自定义线程池Bean并且把核心参数写到配置文件里方便后续调优。3.2 核心线程池参数详解自定义线程池时最关键的四个参数是核心线程数、最大线程数、队列容量、拒绝策略。我以实际项目为例说明参数怎么定。Configuration public class AsyncConfig { Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心线程数正常情况下保持存活的线程数 executor.setCorePoolSize(10); // 最大线程数任务量高峰队列满时能创建的最大线程数 executor.setMaxPoolSize(50); // 队列容量核心线程都在忙时新任务进入队列等待 executor.setQueueCapacity(200); // 线程名称前缀方便日志排查 executor.setThreadNamePrefix(async-thread-); // 拒绝策略队列和最大线程都满时的兜底策略 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); // 线程空闲存活时间 executor.setKeepAliveSeconds(60); executor.initialize(); return executor; } }核心参数怎么定我给一个经验参考公式核心线程数一般设为CPU核心数 1如果是IO密集型任务可以适当调大比如CPU核心数 * 2。大多数业务系统属于IO密集型核心线程数设在10~20之间都合理。最大线程数核心线程数 * 24倍具体看任务量和系统资源。队列容量取决于你愿意让多少任务排队等待。队列填满后线程池才会创建新线程直到最大线程数所以队列上限决定“积压容忍度”。拒绝策略四种RejectedExecutionHandler里CallerRunsPolicy是最推荐的。它不会丢弃任务而是让提交任务的调用线程自己执行起到天然“降速”的效果。当Async方法上没有指定执行器名称时Spring会查找容器中的TaskExecutor类型的Bean或者名为taskExecutor的Bean。如果只定义一个线程池Bean并且为它起了名字记得在Async注解中显式指定执行器名称不然可能报找不到执行器的错。3.3 通过application.yml配置线程池参数把参数写死到Java代码里不便于调优我习惯用配置文件方式管理。先在配置类里读取Environment属性# application.yml async: task: core-pool-size: 10 max-pool-size: 50 queue-capacity: 200 thread-name-prefix: async-thread- keep-alive-seconds: 60Configuration public class AsyncConfig { Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor( Value(${async.task.core-pool-size}) int corePoolSize, Value(${async.task.max-pool-size}) int maxPoolSize, Value(${async.task.queue-capacity}) int queueCapacity, Value(${async.task.thread-name-prefix}) String threadNamePrefix, Value(${async.task.keep-alive-seconds}) int keepAliveSeconds) { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(corePoolSize); executor.setMaxPoolSize(maxPoolSize); executor.setQueueCapacity(queueCapacity); executor.setThreadNamePrefix(threadNamePrefix); executor.setKeepAliveSeconds(keepAliveSeconds); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }这样改配置不需要动代码运维调整参数更方便。3.4 多个线程池的场景业务隔离有的项目里异步任务类型差异很大一种是轻量级日志写入另一种是重量级数据同步。共用一个线程池会导致资源互相抢占数据同步任务堵满了队列日志写入排队等半天影响主流程的日志时效。这种情况最好的做法是按业务域拆分线程池。比如定义两个BeanBean(logTaskExecutor) public ThreadPoolTaskExecutor logTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(2); executor.setMaxPoolSize(5); executor.setQueueCapacity(100); executor.setThreadNamePrefix(log-thread-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy()); executor.initialize(); return executor; } Bean(syncTaskExecutor) public ThreadPoolTaskExecutor syncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(100); executor.setThreadNamePrefix(sync-thread-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }日志类任务用DiscardPolicy日志丢了影响不大不能拖垮业务数据同步用CallerRunsPolicy必须保证数据不丢。线程池隔离这个细节很多初学同学容易忽略等到线上出问题才后悔。4. 异常处理与事务组合4.1 异步方法异常处理Async方法是有返回值时异常会包装在Future或CompletableFuture里通过get()或whenComplete能拿到异常。没有返回值时异常默认被吞掉不会向调用方抛出。这就可能导致你异步任务失败了却不自知。解决思路是给异步任务配置统一的异常处理器。Spring的AsyncConfigurer接口提供了getAsyncUncaughtExceptionHandler方法可以在里面统一捕获并记录日志Configuration EnableAsync public class AsyncExceptionConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-thread-); executor.initialize(); return executor; } Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (throwable, method, params) - { System.err.println(异步方法调用异常方法 method.getName() 参数 Arrays.toString(params)); throwable.printStackTrace(); }; } }把抛出的异常信息打印到日志里配合报警通知基本上问题就不会漏了。也可以把异常信息发到消息队列或钉钉群但是要注意处理器里不能写太重的逻辑避免影响异步线程性能。4.2 Async与Transactional的联动效应有些接口需要异步执行数据库写入操作又想保证数据一致性。有人会直接在Async方法上再加TransactionalAsync Transactional public void updateUserInfo(User user) { // 数据库更新操作 }这样写有一个重要前提两注解同时生效时事务必须由代理对象发起。Async本身经过代理提交到线程池执行Transactional同样需要代理对象来开启事务在异步方法上组合使用时实际执行链路是从线程池线程开始的事务管理器基于线程绑定连接所以事务是生效的。不过有个细节要注意事务回滚只针对方法内抛出的异常而异步方法里如果你自己try-catch吞掉了异常事务自然就不会回滚。所以异常要么不处理要么处理完重新抛出。这里再提醒一句不要把大事务放在异步方法里。异步任务的数据写入如果耗时很长事务在后台线程中长时间占着数据库连接连接池容易被耗尽。我一般建议异步方法只负责轻量级的数据写操作重操作拆分成小任务逐步处理。5. 异步调用中的常见问题排查实录5.1 Async不生效的4个经典原因这个问题被问到的频率最高。排查的时候先看这几点第一启动类有没有加EnableAsync。漏了这个注解Async完全不会生效。第二方法是不是通过代理调用。在同一个类里this.callAsyncMethod()这种内部调用不会经过代理注解失效。解决方式是拆分一个单独的Service类注入后再调用。第三方法是不是static或private。Spring的AOP是基于动态代理实现的private方法和static方法都没法被代理拦截。这个坑最隐蔽因为IDE不会提示错误运行时也不会报异常就是不异步。第四线程池有没有被正确指定。如果容器里有多个线程池BeanAsync没指定名称会搜索不到合适的Executor。推荐的写法是在Async(asyncTaskExecutor)中显式指定Bean名称。5.2 线程池队列积压与任务丢失自定义线程池后最常见的线上问题是队列积压。症状是异步任务延迟很高或出现TaskRejectedException。排查时关注几点核心线程数是不是远低于任务高峰期所需的并发数量任务全部排队了。队列容量设置是否偏大导致消息积压还没触发扩容线程。拒绝策略是不是AbortPolicy是的话任务直接丢弃并抛出异常。我遇到一次严重事故定时任务每5分钟扫一次全量用户发营销短信线程池队列容量设的50一次进来几千个任务全部排队等着营销短信延迟了半个多小时才发完。后来把定时任务改成分批调用异步方法每批200个瞬间就顺畅了。所以异步不是无脑用任务量的控制同样重要。5.3 异步线程中ThreadLocal信息丢失ThreadLocal存用户信息的场景在Web应用里很常见过滤器把用户信息塞进ThreadLocal业务方法取出来用。但异步线程是线程池里的其他线程和请求线程不是同一个请求线程上的ThreadLocal数据自然就丢了。处理方式有几种在提交异步任务之前把需要的上下文信息作为参数显式传给异步方法。使用TransmittableThreadLocal阿里开源的一个TTL组件在线程池提交任务时自动拷贝父线程的变量。我目前在项目中用的是第二种方式给ThreadPoolTaskExecutor包装一下通过自定义TaskDecorator实现上下文传递Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-thread-); executor.setTaskDecorator(runnable - { // 这里可以包装Runnable把需要的上下文快照传到异步线程中 return () - { try { runnable.run(); } finally { // 清理相关上下文 } }; }); executor.initialize(); return executor; }ThreadPoolTaskExecutor提供了setTaskDecorator方法专门用来做这种上下文传递非常方便。如果你是SpringBoot 2.x以上版本这种方式比什么方案都省事。5.4 如何确定异步确实生效了写完了不知道怎么验证有没有真正异步执行我分享一个最简单的验证思路在调用方加一行打印“调用结束”在被调异步方法开头打印当前线程名。如果控制台显示先输出“调用结束”随后才输出异步方法的线程日志并且线程名跟请求线程不一样说明异步生效了。另一个验证思路是在异步方法里Thread.sleep(3000)调接口看响应时间如果接口毫秒级返回说明异步生效如果接口耗时3秒以上说明方法还是在同步执行。这个方法在开发联调阶段非常实用基本一眼就能发现问题。6. 工具选型与进阶玩法6.1 Spring事件监听与异步结合Spring容器的ApplicationEvent机制天然适配异步场景。定义了事件和监听器public class OrderCreateEvent extends ApplicationEvent { private String orderId; // getter/setter }监听器方法上直接加AsyncComponent public class OrderEventListener { EventListener Async(asyncTaskExecutor) public void onOrderCreate(OrderCreateEvent event) { // 异步处理订单创建后的通知、日志等 } }这种组合在业务上非常有价值发布订单创建事件后主流程不用关心后面有多少监听器新增监听器也不需要改动原业务代码解耦很彻底。事件监听异步执行的注意点监听器默认同步执行加了Async才会扔到线程池如果监听器内部有自定义异常处理逻辑记得在监听器方法内部捕获处理避免传入到Spring事件广播线程影响其他监听器执行。6.2 CompletableFuture编排多个异步任务如果一次要调用多个外部系统最后汇总结果CompletableFuture是利器。结合Async可以写“并行收集结果”的代码Async(asyncTaskExecutor) public CompletableFutureDouble fetchPriceFromA() { // 调用A系统 return CompletableFuture.completedFuture(100.5); } Async(asyncTaskExecutor) public CompletableFutureDouble fetchPriceFromB() { // 调用B系统 return CompletableFuture.completedFuture(98.6); } // 调用方汇总 CompletableFutureDouble futureA priceService.fetchPriceFromA(); CompletableFutureDouble futureB priceService.fetchPriceFromB(); CompletableFuture.allOf(futureA, futureB).join(); Double totalPrice futureA.get() futureB.get();这里allOf(futureA, futureB).join()会等待两个任务都完成整体耗时取决于最慢的那个任务相比串行调用节省了一半时间。任务多的时候效果更明显。有一个注意点注意线程池任务数量要匹配并发调用的数量。你一次性提交10个任务线程池核心线程只有5剩下5个排队整体耗时不会提高一倍可能就是两个批次的时间。6.3 监控线程池指标线程池配置完不监控等于白配。我在生产环境会给线程池加简单的监控定时打印核心指标。Scheduled(fixedRate 60000) public void printThreadPoolMetrics() { ThreadPoolTaskExecutor executor (ThreadPoolTaskExecutor) SpringContextHolder.getBean(asyncTaskExecutor); ThreadPoolExecutor threadPoolExecutor executor.getThreadPoolExecutor(); int activeCount threadPoolExecutor.getActiveCount(); long taskCount threadPoolExecutor.getTaskCount(); long completedTaskCount threadPoolExecutor.getCompletedTaskCount(); int queueSize threadPoolExecutor.getQueue().size(); System.out.println(活跃线程: activeCount , 总任务: taskCount , 完成任务: completedTaskCount , 队列剩余: queueSize); }getQueue().size()是最关键的一个指标它告诉你当前有多少任务在堆积。如果长期排队任务数超过队列容量的50%就要考虑扩线程或者拆分任务了。生产环境建议用Micrometer把这些指标暴露到Prometheus配好告警规则比人工看日志高效得多。7. 一个完整的异步调用配置实战参考这里把前面的内容汇总成一个能直接落地的完整方案大家可以照着抄。7.1 工程结构组织com.example.demo ├── Application.java ├── config │ └── AsyncConfig.java ├── service │ ├── OrderService.java │ └── NotifyService.java └── controller └── OrderController.java异步线程池配置单独放一个config包不要和其他配置类混在一起方便管理。7.2 核心代码展示首先是线程池配置类Configuration EnableAsync public class AsyncConfig { Bean(asyncTaskExecutor) public ThreadPoolTaskExecutor asyncTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix(async-thread-); executor.setTaskDecorator(runnable - { MapString, String context TraceIdHolder.get(); return () - { TraceIdHolder.set(context); try { runnable.run(); } finally { TraceIdHolder.clear(); } }; }); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }业务服务类Service public class OrderService { Async(asyncTaskExecutor) public void processOrder(Order order) { // 更新订单状态 // 发送通知消息 // 记录流水日志 } }Controller调用RestController RequestMapping(/order) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } PostMapping(/create) public Result createOrder(RequestBody Order order) { // 核心订单入库逻辑 // 异步处理辅助业务 orderService.processOrder(order); return Result.success(); } }7.3 配置要点回顾这套配置的核心要点我总结成一张速查表配置项推荐值/做法说明核心线程数10~20IO密集型可适当多配最大线程数核心线程数的2~4倍防止线程无限膨胀队列容量100~500给任务排队留缓冲拒绝策略CallerRunsPolicy宁可调用线程执行也不想丢任务线程名前缀业务名-thread-日志排查关键依据TaskDecorator传递TraceId/用户上下文解决ThreadLocal丢失问题监控定时打印队列大小/活跃线程数提前发现线程池过载风险8. 写在最后一些过来人的经验体会我大概从Spring Boot 1.x时代就开始用Async中间踩过的坑比写出来的还多。刚开始最迷惑的是“注解加上了为什么不生效”后来慢慢理解了Spring代理机制很多问题其实都是同一个根因——没走代理。现在写代码前我都会先问自己一句这个方法会被谁调用是不是从另一个Bean注入进来的另外一个很重要的体会是异步不是性能优化的万能药。接口慢了先定位慢在哪如果是数据库查询慢、外部接口慢异步确实很有效。但如果业务逻辑本身就依赖实时结果异步就不合适。拿不准的时候就选同步同步至少不会出现“任务丢了还找不到”的情况。线程池参数也没有一劳永逸的最优值只能根据业务压测慢慢调整。建议每次调整后都记录当时的参数值和线上表现积累一两轮数据之后你的参数直觉会准很多。这套配置我放在项目的基座里已经稳定跑了一年多核心接口的p99响应时间从2.3秒降到了320毫秒。只要按文章里的配置思路来再加上监控指标你的异步调用方案也会很稳。如果大家在落地过程中遇到“异步任务丢失”“线程池满”之类的问题回头看一下拒绝策略和任务量控制这两块大概率就能找到原因。
