Spring中异步注解@Async的使用、原理及使用时可能导致的问题
https://mp.weixin.qq.com/s/s9YeTBn89m7xJERTtAdkXQ
前言
最近,很多同学碰到了下面这个问题,添加了Spring提供的一个异步注解@Async循环依赖无法被解决了,下面是一些读者的留言跟群里同学碰到的问题:


本着讲一个知识点就要讲明白、讲透彻的原则,我决定单独写一篇这样的文章对@Async这个注解做一下详细的介绍,这个注解带来的问题远远不止循环依赖这么简单,如果对它不够熟悉的话建议慎用。
文章要点

@Async的基本使用
这个注解的作用在于可以让被标注的方法异步执行,但是有两个前提条件
1. 配置类上添加@EnableAsync注解
2. 需要异步执行的方法的所在类由Spring管理
3. 需要异步执行的方法上添加了@Async注解
我们通过一个Demo体会下这个注解的作用吧
第一步,配置类上开启异步:
第二步,
第三步,测试异步执行
通过上面的例子我们可以发现,DmzAsyncService中的testAsync方法是异步执行的,那么这背后的原理是什么呢?我们接着分析
原理分析
我们在分析某一个技术的时候,最重要的事情是,一定一定要找到代码的入口,像Spring这种都很明显,入口必定是在@EnableAsync这个注解上面,我们来看看这个注解干了啥事(本文基于5.2.x版本)
上面这个注解做的最重要的事情就是导入了一个AsyncConfigurationSelector,这个类的源码如下:
这个类的作用是像容器中注册了一个ProxyAsyncConfiguration,这个类的继承关系如下:

我们先看下它的父类AbstractAsyncConfiguration,其源码如下:
再来看看ProxyAsyncConfiguration这个类的源码
这个类本身是一个配置类,它的作用是向容器中添加一个AsyncAnnotationBeanPostProcessor。到这一步我们基本上就可以明白了,@Async注解的就是通过AsyncAnnotationBeanPostProcessor这个后置处理器生成一个代理对象来实现异步的,接下来我们就具体看看AsyncAnnotationBeanPostProcessor是如何生成代理对象的,我们主要关注一下几点即可:
是在生命周期的哪一步完成的代理?
切点的逻辑是怎么样的?它会对什么样的类进行拦截?
通知的逻辑是怎么样的?是如何实现异步的?
基于上面几个问题,我们进行逐一分析
是在生命周期的哪一步完成的代理?
我们抓住重点,AsyncAnnotationBeanPostProcessor是一个后置处理器器,按照我们对Spring的了解,大概率是在这个后置处理器的postProcessAfterInitialization方法中完成了代理,直接定位到这个方法,这个方法位于父类AbstractAdvisingBeanPostProcessor中,具体代码如下:
果不其然,确实是在这个方法中完成的代理。接着我们就要思考,切点的过滤规则是什么呢?
切点的逻辑是怎么样的?
其实也不难猜到肯定就是类上添加了@Async注解或者类中含有被@Async注解修饰的方法。基于此,我们看看这个isEligible这个方法的实现逻辑,这个方位位于AbstractBeanFactoryAwareAdvisingPostProcessor中,也是AsyncAnnotationBeanPostProcessor的父类,对应代码如下:
实际上最后就是根据advisor来确定是否要进行代理,advisor实际就是一个绑定了切点的通知,那么AsyncAnnotationBeanPostProcessor这个advisor是什么时候被初始化的呢?我们直接定位到AsyncAnnotationBeanPostProcessor的setBeanFactory方法,其源码如下:
我们来看看AsyncAnnotationAdvisor中的切点匹配规程是怎么样的,直接定位到这个类的buildPointcut方法中,其源码如下:
代码很简单,就是根据cpc跟mpc两个匹配器来进行匹配的,第一个是检查类上是否有@Async注解,第二个是检查方法是是否有@Async注解。
那么,到现在为止,我们已经知道了它在何时创建代理,会为什么对象创建代理,最后我们还需要解决一个问题,代理的逻辑是怎么样的,异步到底是如何实现的?
通知的逻辑是怎么样的?是如何实现异步的?
前面也提到了advisor是一个绑定了切点的通知,前面分析了它的切点,那么现在我们就来看看它的通知逻辑,直接定位到AsyncAnnotationAdvisor中的buildAdvice方法,源码如下:
简单吧,加了一个拦截器而已,对于interceptor类型的对象,我们关注它的核心方法invoke就行了,代码如下:
导致的问题及解决方案
问题1:循环依赖报错
就像在这张图里这个读者问的问题,

分为两点回答:
第一:循环依赖为什么不能被解决?
这个问题其实很简单,我从两个方面分析了循环依赖的处理流程
简单对象间的循环依赖处理
AOP对象间的循环依赖处理
按照这种思路,@Async注解导致的循环依赖应该属于AOP对象间的循环依赖,也应该能被处理。但是,重点来了,解决AOP对象间循环依赖的核心方法是三级缓存,如下:

在三级缓存缓存了一个工厂对象,这个工厂对象会调用getEarlyBeanReference方法来获取一个早期的代理对象的引用,其源码如下:
看完上面的代码循环依赖的问题就很明显了,因为早期暴露的对象跟最终放入容器中的对象不是同一个,所以报错了。

解决方案
就以上面读者给出的Demo为例,只需要在为B注入A时添加一个@Lazy注解即可
这个注解的作用在于,当为B注入A时,会为A生成一个代理对象注入到B中,当真正调用代理对象的方法时,底层会调用getBean(a)去创建A对象,然后调用方法,这个注解的处理时机是在org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveDependency方法中,处理这个注解的代码位于org.springframework.context.annotation.ContextAnnotationAutowireCandidateResolver#buildLazyResolutionProxy
问题2:默认线程池不会复用线程
我觉得这是这个注解最坑的地方,没有之一!我们来看看它默认使用的线程池是哪个,在前文的源码分析中,我们可以看到决定要使用线程池的方法是org.springframework.aop.interceptor.AsyncExecutionAspectSupport#determineAsyncExecutor。其源码如下:
最终会调用到org.springframework.aop.interceptor.AsyncExecutionInterceptor#getDefaultExecutor这个方法中
可以看到,它默认使用的线程池是SimpleAsyncTaskExecutor。我们不看这个类的源码,只看它上面的文档注释,如下:

主要说了三点
为每个任务新起一个线程
默认线程数不做限制
不复用线程
就这三点,你还敢用吗?只要你的任务耗时长一点,说不定服务器就给你来个OOM。
解决方案
最好的办法就是使用自定义的线程池,主要有这么几种配置方法
在之前的源码分析中,我们可以知道,可以通过
AsyncConfigurer来配置使用的线程池
如下:
直接在@Async注解中配置要使用的线程池的名称
如下:
总结
本文主要介绍了Spring中异步注解的使用、原理及可能碰到的问题,针对每个问题文中也给出了方案。希望通过这篇文章能帮助你彻底掌握@Async注解的使用,知其然并知其所以然!
Last updated
Was this helpful?