@Async是提升并发性能最轻量方式，核心是释放Web容器线程；需满足不破坏事务、不依赖上下文、结果非实时等条件；必须自定义线程池并规范调用与监控。
直接用 @Async 把耗时操作从主线程摘出来，是提升核心业务并发速度最轻量、见效最快的方式之一。关键不是“加了异步就快”，而是让线程资源用在刀刃上——把 Web 容器线程（比如 Tomcat 的 worker 线程）及时释放，避免被发邮件、调第三方接口、生成报表这类 I/O 密集型任务长期占用。
明确哪些操作适合套 @Async
不是所有方法都该异步，核心原则是：不影响主流程一致性、不依赖当前事务上下文、结果无需实时返回给用户。
- 用户注册成功后发送欢迎邮件或短信（不阻塞注册响应）
- 订单创建后异步写操作日志、触发风控扫描、通知库存服务
- 后台批量导出数据、生成统计图表、清理过期缓存
- 调用外部 HTTP 接口（如支付回调验证、地址解析服务）
要避开的典型反例：在同一个事务内更新数据库后再异步改另一张表（事务已提交，异步里失败无法回滚）；或者把数据库 insert + update 套 @Async —— 这会破坏数据强一致性。
必须自定义线程池，别用默认的
Spring 默认用 SimpleAsyncTaskExecutor，每次调用都新建线程，无复用、无限制、易 OOM。生产环境必须配 ThreadPoolTaskExecutor，并按业务特征调参：
立即学习“Java免费学习笔记（深入）”；
- corePoolSize：设为 CPU 核数 × 2～4（I/O 密集型任务，如 HTTP 调用，线程常等待，可多些）
- maxPoolSize：略高于峰值并发任务数，避免无限扩容拖垮系统
- queueCapacity：建议设为 100～500 的有界队列，防止突发流量把内存撑爆
- rejectedExecutionHandler：推荐 CallerRunsPolicy，让调用方线程自己执行，起到自然降级作用
配置示例中线程名带前缀（如 "async-order-"），方便在日志和监控里快速定位异步任务来源。
正确声明与调用方式
@Async 生效有硬性前提，漏掉任一环节都会静默失效：
- 启动类或配置类上必须有 @EnableAsync
- 目标方法必须是 public，且定义在 Spring 管理的 Bean（如 @Service）里
- 不能在同类中直接调用（this.asyncMethod()），必须通过 Spring 代理调用（注入自身 Bean 再调）
- 返回类型建议用 CompletableFuture<T>，便于组合、超时控制和异常捕获；void 也可，但异常容易丢失
例如：一个订单服务里，createOrder() 同步返回订单号，再调用 asyncNotifyOrderCreated(orderId) 发消息——后者必须由另一个注入的 AsyncService 实例来触发，而非 this.
加上基础监控和兜底措施
异步任务跑在后台，出问题不易察觉。上线前至少补两件事：
- 在自定义线程池 bean 上暴露指标，比如用 Micrometer 暴露 active count、queue size、completed tasks 数，接入 Prometheus
- 对 CompletableFuture 返回的方法，统一用 .whenComplete() 或 .exceptionally() 记录关键异常，避免“无声失败”
- 对重要异步任务（如扣库存），加幂等标识 + 补偿机制（比如定时扫表重试），不能只靠“一次成功”
做到这几点，@Async 就不再是锦上添花的装饰，而是稳住高并发链路的压舱石。
