Spring 解析@Async引起的循环依赖

啊，昨晚发版又出现了让有头大的[循环依赖](https://so.csdn.net/so/search?q=%E5%BE%AA%E7%8E%AF%E4%BE%9D%E8%B5%96&spm=1001.2101.3001.7020)问题，按理说 Spring 会为我们解决循环依赖，但是为什么还会出现这个问题呢？为什么在本地、UAT 以及 PRE 环境都没有出现这个问题，但是到了 PROD 环境就出现了这个问题呢？本文将从事故时间线、及时止损、复盘分析等几个方面为大家带来详细的分析，干货满满！

##### 事故时间线

本着`"先止损、后复盘分析"`的原则，我们来看一下这次发版事故的时间线。

- 2021 年 11 月 16 日晚 23 点 00 分 00 秒开始发版，此时集团的 devops 有点慢
- 2021 年 11 月 16 日晚 23 点 03 分 01 秒，收到发版失败的消息，登录服务器发现发生了循环依赖，具体错误如下图，从日志中可以看到是`dataCollectionSendMessageService`这个 bean 出现了循环依赖
![](/media/202303/2023-03-30_094929_3442710.04001952843803269.png)
- 问题发现了就需要先解决，然后再去分析为什么。看到这个报错日志我心里也大概知道是为什么了，所以很快就解决了，解决方案如下：给`DataCollectionSendMessageService`加上`@Lazy`注解
![](/media/202303/2023-03-30_094948_3571180.9011421204768713.png)
- 2021 年 11 月 16 日晚 23 点 07 分 16 秒，使用重新集成的代码开始发版，大概 10 分钟后线上节点全部发版完成。从时间线来看从发现问题到解决问题，前后一共用了接近 15 分钟（这期间代码集成和发布用了过多的时间），也算是做到了及时止损，没有让问题继续扩大。

##### 猜想

我大胆的猜想是因为打了`@Aysnc注解`的 bean 生成了对象的代理，导致 Spring bean 最终加载的不是一个原始对象导致了此次问题的发生，那么对不对呢，接下来我们通过源码详细分析一下。

##### 什么是循环依赖

所谓循环依赖就是`Spring IOC容器`在加载 bean 时会按照顺序加载，先去实例化 beanA。然后发现 beanA 依赖于 beanB，接在又去实例化 beanB。实例化 beanB 时，发现 beanB 又依赖于 beanA。如果容器不处理循环依赖的话，容器会无限执行上面的流程，直到内存溢出，程序崩溃，所以这个时候就会抛出`BeanCurrentlyInCreationException`异常，也就是我们常说的循环依赖，下面是两种常见循环依赖的场景。

- 几个 Bean 之间的循环依赖
```
  @Component
  public class A {

@Autowired
      private B b;

}

@Component
  public class B {

@Autowired
      private C c;

}

@Component
  public class C {

@Autowired
      private A a;

}
```
效果图如下：
![](/media/202303/2023-03-30_095010_3242930.6848937573358196.png)

- 自己依赖自己
```
  @Component
  public class A {

@Autowired
      private A a;

}
```
效果图如下：
![](/media/202303/2023-03-30_095052_5775630.6003292558972471.png)

##### Spring 是如何解决循环依赖的

![](/media/202303/2023-03-30_095108_7509620.13762211807733415.png)

首先 Spring 维护了三个 Map，也就是我们通常说的三级缓存

- `singletonObjects`：俗称单例池，缓存创建完成的单例 Bean
- `singletonFactories`：映射创建 Bean 的原始工厂
- `earlySingletonObjects`：映射 Bean 的早期引用，也就是说这个 Map 里的 Bean 不是完整的，只是完成了实例化，但还没有初始化

Spring 通过三级缓存解决了循环依赖，其中一级缓存为单例池（singletonObjects），二级缓存为早期曝光对象 earlySingletonObjects，三级缓存为早期曝光对象工厂（singletonFactories）。

当 A、B 两个类发生循环引用时，在 A 完成实例化后，就使用实例化后的对象去创建一个对象工厂，并添加到三级缓存中，`如果A被AOP代理，那么通过这个工厂获取到的就是A代理后的对象，如果A没有被AOP代理，那么这个工厂获取到的就是A实例化的对象`。

当 A 进行属性注入时，会去创建 B，同时 B 又依赖了 A，所以创建 B 的同时又会去调用 getBean(a)来获取需要的依赖，此时的 getBean(a)会从缓存中获取，第一步，先获取到三级缓存中的工厂；第二步，调用对象工工厂的 getObject 方法来获取到对应的对象，得到这个对象后将其注入到 B 中。

紧接着 B 会走完它的生命周期流程，包括初始化、后置处理器等。当 B 创建完后，会将 B 再注入到 A 中，此时 A 再完成它的整个生命周期。至此，循环依赖结束！

简单一句话说：`先去缓存里找Bean，没有则实例化当前的Bean放到Map，如果有需要依赖当前Bean的，就能从Map取到。`

##### 什么是@[Async](https://so.csdn.net/so/search?q=Async&spm=1001.2101.3001.7020)

`@Async`注解是 Spring 为我们提供的异步调用的注解，`@Async`可以作用到类或者方法上，标记了`@Async`注解的方法将会在独立的线程中被执行，调用者无需等待它的完成，即可继续其他的操作。从源码中可以看到标记了`@Async`注解的方法会被提交到`org.springframework.core.task.TaskExecutor`中异步执行
![](/media/202303/2023-03-30_095207_3495790.9080683196438979.png)

或者我们可以通过`value`来指定使用哪个自定义线程池，比如这样子：

@Async("asyncTaskExecutor")

##### 被@Async 标记的 bean 注入时机

我们从源码的角度来看一下被`@Async`标记的 bean 是如何注入到 Spring 容器里的。在我们开启`@EnableAsync`注解之后代表可以向 Spring 容器中注入`AsyncAnnotationBeanPostProcessor`，它是一个后置处理器，我们看一下他的类图。
![](/media/202303/2023-03-30_095233_0036960.09226366371636807.png)

真正创建代理对象的代码在`AbstractAdvisingBeanPostProcessor`中的`postProcessAfterInitialization`方法中，以下代码有所删减，只保留核心逻辑代码
```
    	// 这个map用来缓存所有被postProcessAfterInitialization这个方法处理的bean
    	private final Map<Class<?>, Boolean> eligibleBeans = new ConcurrentHashMap<>(256);

// 这个方法主要是为打了@Async注解的bean生成代理对象
    	@Override
    	public Object postProcessAfterInitialization(Object bean, String beanName) {
    		// 这里是重点，这里返回true
    		if (isEligible(bean, beanName)) {
    			// 工厂模式生成一个proxyFactory
    			ProxyFactory proxyFactory = prepareProxyFactory(bean, beanName);
    			if (!proxyFactory.isProxyTargetClass()) {
    				evaluateProxyInterfaces(bean.getClass(), proxyFactory);
    			}
    			// 切入切面并创建一个代理对象
    			proxyFactory.addAdvisor(this.advisor);
    			customizeProxyFactory(proxyFactory);
    			return proxyFactory.getProxy(getProxyClassLoader());
    		}
    		// No proxy needed.
    		return bean;
    	}

protected boolean isEligible(Class<?> targetClass) {
    		// 首次从eligibleBeans这个map中一定是拿不到的
    		Boolean eligible = this.eligibleBeans.get(targetClass);
    		if (eligible != null) {
    			return eligible;
    		}
    		// 如果没有advisor，也就是切面，直接返回false
    		if (this.advisor == null) {
    			return false;
    		}
    		// 这里判断AsyncAnnotationAdvisor能否切入，因为我们的bean是打了@Aysnc注解，这里是一定能切入的，最终会返回true
    		eligible = AopUtils.canApply(this.advisor, targetClass);
    		this.eligibleBeans.put(targetClass, eligible);
    		return eligible;
    	}
```
至此打了`@Aysnc注解`的 bean 就创建完成了，结果是生成了一个`代理对象`。

##### 循环依赖到底是怎么生成的

经过上面的源码分析，我们可以知道有`@Aysnc注解`的 bean 最后生成了一个代理对象，我们结合 Spring bean 创建的流程来分析这次问题。

- `beanA`开始初始化，`beanA`实例化完成后给`beanA`的依赖属性`beanB`进行赋值
- `beanB`开始初始化，`beanB`实例化完成后给`beanB`的依赖属性`beanA`进行赋值
- 因为`beanA`是支持循环依赖的，所以可以在`earlySingletonObjects`中可以拿到`beanA`的早期引用的，但是因为`beanB`打了`@Aysnc注解`并不能在`earlySingletonObjects`中可以拿到早期引用
- 接下来执行执行`initializeBean(Object existingBean, String beanName)`方法，这里`beanA`可以正常实例化完成，但是因为`beanB`打了`@Aysnc注解`，所以向 Spring IOC 容器中增加了一个代理对象，也就是说`beanA`的`beanB`并不是一个原始对象，而是一个代理对象
- 接下来进行执行`doCreateBean`方法时对进行检测，以下代码有所删减，只保留核心逻辑代码

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
  throws BeanCreationException {

if (earlySingletonExposure) {
      		Object earlySingletonReference = getSingleton(beanName, false);
      		if (earlySingletonReference != null) {
      			if (exposedObject == bean) {
      				exposedObject = earlySingletonReference;
      			}
      			else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
      				String[] dependentBeans = getDependentBeans(beanName);
      				Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
      				// 重点在这里，这里会遍历所有依赖的bean，如果beanA依赖beanB和缓存中的beanB不相等
      				// 也就是说beanA本来依赖的是一个原始对象beanB，但是这个时候发现beanB是一个代理对象，就会增加到actualDependentBeans
      				for (String dependentBean : dependentBeans) {
      					if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
      						actualDependentBeans.add(dependentBean);
      					}
      				}
      				// 发现actualDependentBeans不为空，就发生了我们最开始截图的错误
      				if (!actualDependentBeans.isEmpty()) {
      					throw new BeanCurrentlyInCreationException(beanName,
      							"Bean with name '" + beanName + "' has been injected into other beans [" +
      							StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
      							"] in its raw version as part of a circular reference, but has eventually been " +
      							"wrapped. This means that said other beans do not use the final version of the " +
      							"bean. This is often the result of over-eager type matching - consider using " +
      							"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
      				}
      			}
      		}
      	}

// Register bean as disposable.
      	try {
      		registerDisposableBeanIfNecessary(beanName, bean, mbd);
      	}
      	catch (BeanDefinitionValidationException ex) {
      		throw new BeanCreationException(
      				mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
      	}

return exposedObject;
      }

##### 解决循环依赖的正确姿势

- `@Lazy`注解
- 代码优化，不要让`@Async`的 Bean 参与循环依赖

至此我们就知道为什么发生了此次问题。