Spring 的 @Async 为什么会失效？异步方法的线程池和异常怎么处理？

知识点详解：异步不是方法的一种标签，而是一条调用路径

调用必须先经过能够拦截它的对象

咱们假设报表服务里有一个异步生成方法。另一个 Bean 调用这个服务代理时，代理可以识别异步规则，将执行安排给线程池。

如果同一个对象内部通过自身引用调用方法，常见代理模式下并不会绕回代理入口。方法依旧可能在当前线程执行。

Spring 的异步调度文档明确说明了默认代理模式与本地调用限制。AspectJ 等其他模式有不同条件，所以应说清“常见代理模式”，不要把一种机制当成所有配置。

排查时先记录调用入口和执行线程，再检查 Bean、异步启用与代理条件。不要上来就扩大线程池，因为代理根本没生效时，线程池大小解决不了问题。

经过代理以后，任务进入的是执行器

调用方通常不再等待业务方法完整执行，而是由执行器安排任务。是否有队列、最多多少线程、任务多了怎么办，都由相应执行器配置决定。

异步并不必然更快。数据库和外部接口可能已经饱和，增加线程只会增加等待和压力。队列太长时，调用方很快返回，但任务可能很久以后才执行。

因此，需要记录排队时长、执行时长和拒绝次数。不能只看 Web 请求返回速度，就认为异步设计改善了整个任务延迟。

对于不能丢失的任务，也要评估进程退出后的恢复。内存线程池不是持久任务系统，重要工作可能需要可靠队列或任务存储。

异常不能因为调用返回了就消失

返回 Future 或 CompletableFuture 时，任务失败会体现在相应结果中，需要读取或注册处理逻辑。只提交任务却永远不观察结果，会让失败变得难以发现。

void 方法没有可供调用方等待的返回对象，通常需要 AsyncUncaughtExceptionHandler 等机制处理未捕获异常。它不是一次普通同步调用，因此不能期待外层 try/catch 必然抓到稍后发生的错误。

实际项目也应给任务标识和日志关联，知道哪次提交失败。只打印一段异常堆栈，却找不到业务对象，仍然不利于恢复。

原线程的事务与上下文，不会自然搬过去

Spring 常见事务上下文绑定在线程上。新线程执行异步任务，并不自动加入调用方原来的事务。

假设调用方先保存一条数据，再异步查询它。如果调用方事务还没有提交，异步任务可能看不到最终状态。可以根据需求在提交后触发，或通过可靠事件机制安排后续处理，而不是随意加睡眠等待。

日志上下文、身份信息和其他 ThreadLocal 数据也需要明确传递或重建。传递身份时还要重新检查权限，不能因为来自旧线程就无条件信任。

本题没有提供 TS、Python 的注解翻译：它们没有 Spring @Async 的同一套代理语义，类似的异步功能也不能作为官方对应 API。

面试官继续追问

方法加了 public 就一定有效吗？

不一定。还要看容器管理、代理方式、调用入口和配置。可见性只是条件的一部分，不是整体保证。

@Async 和 @Transactional 一起使用怎么办？

要按实际调用路径确认事务在哪个线程、哪个代理入口建立。异步任务可以拥有自己的事务，但不能默认继承调用方事务。

线程池满了该怎么处理？

先明确任务是否允许拒绝、降级或等待，再配置有界队列和相应策略。不能用无限队列把过载藏成越来越长的延迟。

面试速记卡

• 首要条件：调用经过异步代理。
• 常见失效：自身调用、非容器对象或配置不满足。
• 执行责任：线程池容量、排队和拒绝策略。
• 异常责任：结果对象与 void 方法分别处理。
• 线程边界：事务和 ThreadLocal 不自动继承。