spring中@async实现业务解耦需显式配置threadpooltaskexecutor，避免默认simpleasynctaskexecutor导致线程失控；必须命名线程池bean并精确指定@async("name")；合理设置corepoolsize、maxpoolsize、queuecapacity及拒绝策略；方法须为public非final且跨类调用；结合spring event可进一步解耦职责。
在 Spring 中用 @Async 实现业务解耦，关键不是“加个注解就完事”，而是让异步逻辑真正脱离主流程、不拖慢响应、不压垮系统——这必须靠显式配置的 ThreadPoolTaskExecutor 来兜底。
必须显式指定线程池 Bean 名
@Async 不写线程池名，默认走 SimpleAsyncTaskExecutor：每次调用新建线程、不复用、不限流、不回收。压测时线程数飙升、CPU 打满、JVM OOM 都是常态。日志里看到 SimpleAsyncTaskExecutor-127 这类命名，基本就是掉坑里了。
- 在配置类中定义带名字的线程池 Bean，例如：
@Bean("taskExecutor") public ThreadPoolTaskExecutor taskExecutor() - @Async 注解里严格写上这个名字：
@Async("taskExecutor")，大小写敏感，不能拼错 - 别依赖
AsyncConfigurer.getAsyncExecutor()全局设置——它只对无名 @Async 生效，覆盖不了显式命名场景
线程池参数要协同设计，不能拍脑袋
corePoolSize、maxPoolSize、queueCapacity 三者互相牵制。设得不合理，不是资源浪费，就是任务堆积失真。
- CPU 密集型任务：corePoolSize ≈
Runtime.getRuntime().availableProcessors()；IO 密集型可设为 2–4 倍 - maxPoolSize 通常设为 corePoolSize × 2，给突发流量留缓冲，但别盲目拉高
- queueCapacity 别设成
Integer.MAX_VALUE；建议 100–500，配合拒绝策略才能真实反映系统压力 - 务必设置拒绝策略：
setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy())，避免任务静默丢弃
@Async 方法本身有可见性约束
它靠 Spring AOP 代理生效，不是所有方法都能被“异步化”。
- 方法不能是 private、static 或 final
- 不能在同一个类里自调用（比如 A 方法调 this.B 方法），代理对象没介入，@Async 失效
- 目标类必须是 Spring 管理的 Bean（
@Service/@Component） - 最稳妥做法：把异步逻辑抽到独立的
@Service类中，用@Autowired注入后调用
搭配 Spring Event 可进一步解耦职责
@Async 解决“谁来异步执行”，Spring Event 解决“谁该知道这件事”。两者组合，能让注册、发券、通知等后续动作完全脱离主链路。
- 定义事件类（继承
ApplicationEvent），携带必要上下文（如 userId、订单号） - 在主业务中通过
ApplicationEventPublisher发布事件，不关心谁处理、是否成功 - 监听器方法加上
@Async("taskExecutor")，由统一池子消费事件 - 这样修改积分、发短信、更新搜索索引等都可以各自监听同一事件，互不影响
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
