SpringBean循环依赖

循环依赖

所谓的循环依赖是指，A 依赖 B，B 又依赖 A，它们之间形成了循环依赖。

1、三级缓存解决循环依赖

Spring通过三级缓存的方式来解决循环依赖的问题。DefaultSingletonBeanRegistry类中的三个缓存变量

//一级缓存：单例缓存池，用于保存所有的完整单例bean 
private final Map singletonObjects = new ConcurrentHashMap<>(256);

//三级缓存：早期对象包装成ObjectFactory
private final Map> singletonFactories = new HashMap<>(16);

//二级缓存：早期对象，指的是bean刚刚调用了构造方法，还没给bean的属性进行赋值的对象
private final Map earlySingletonObjects = new HashMap<>(16);

2、代码执行流程梳理

假如存在两个类互相依赖，A 依赖 B，B 又依赖 A，形成循环依赖。

当通过getBean获取A时，先getSingleton从缓存中获取不到，所以通过createBean–>doCreateBean逻辑去进行创建，创建之前通过beforeSingletonCreation标记A正在创建；在doCreateBean中，如果符合条件earlySingletonExposure就把早期对象包装成ObjectFactory暴露到三级缓存singletonFactories中；随后进行属性赋值populateBean，在解析属性时发现依赖B，所以通过getBean去获取B；

通过getBean去获取B和获取A逻辑一样，直到解析属性时发现依赖A，所以再次通过getBean获取A；

再次获取A时，通过getSingleton去缓存中获取，此时一级缓存中还没有A，但是A已经被标记为正在创建，所以会进入if去找二级缓存；二级缓存没有去找三级缓存，从三级缓存中获取到ObjectFactory包装对象，然后获取到早期对象；把早期对象放到二级缓存并删除三级缓存中对象；

第二次获取A完成之后，返回到创建B的操作，将获取到的A赋值到B的a属性，直到创建B完成之后，返回到第一次创建A的操作，将B赋值到A的b属性，直至创建A的操作完成，整个循环依赖处理结束。继续往下走，再次调用getSingleton从二级缓存中获取到A返回。

原理分析

A创建时—>需要B---->B去创建—>需要A，从而产生了循环。打破循环，加缓存就可以了。

A 的 Bean 在创建过程中，在进行依赖注入之前，先把 A 的原始 Bean 放入缓存（提早暴露，只要放到缓存了，其他 Bean 需要时就可以从缓存中拿了），放入缓存后，再进行依赖注入，此时 A 的Bean 依赖了 B 的 Bean 。

如果 B 的 Bean 不存在，则需要创建 B 的 Bean，而创建 B 的 Bean 的过程和 A 一样，也是先创建一个 B 的原始对象，然后把 B 的原始对象提早暴露出来放入缓存中，然后在对 B 的原始对象进行依赖注入 A，此时能从缓存中拿到 A 的原始对象（虽然是 A 的原始对象，还不是最终的 Bean），B 的原始对象依赖注入完了之后，B 的生命周期结束，那么 A 的生命周期也能结束。

因为整个过程中，都只有一个 A 原始对象，所以对于 B 而言，就算在属性注入时，注入的是 A 原始对
象，也没有关系，因为A 原始对象在后续的生命周期中在堆中没有发生变化。

1、循环依赖场景

单例 bean 构造器参数循环依赖（⽆法解决）

从上面的图中可以看出，能解决循环依赖bean的实例化过程和属性依赖注入过程是分离的。采用构造器循环依赖是无法实现的，只能拋出 BeanCurrentlyInCreationException 异常，在解决属性循环依赖时，spring采⽤的是提前暴露对象的⽅法。

prototype 原型 bean循环依赖（⽆法解决）

对于原型bean的初始化过程中不论是通过构造器参数循环依赖还是通过setXxx⽅法产⽣循环依赖，Spring都会直接报错处理。

if (isPrototypeCurrentlyInCreation(beanName)) {
 throw new BeanCurrentlyInCreationException(beanName);
}

protected boolean isPrototypeCurrentlyInCreation(String beanName) {
 Object curVal = this.prototypesCurrentlyInCreation.get();
 return (curVal != null && (curVal.equals(beanName) || (curVal instanceof Set && ((Set)curVal).contains(beanName))));
}

只有单例bean通过setXxx或者@Autowired进⾏循环依赖

为什么需要第三级缓存singletonFactories ？

1、问题引出

从上面这个分析过程中可以得出，只需要一个缓存就能解决循环依赖了，那么为什么 Spring 中还需要 singletonFactories 呢？

基于上面的场景思考一个问题：

如果 A 的原始对象注入给 B 的属性之后，A 的原始对象进行了 AOP 产生了一个代理对象，此时就会出现，对于 A 而言，它的 Bean 对象其实应该是 AOP 之后的代理对象，而 B 的 a 属性对应的并不是 AOP 之后的代理对象，这就产生了冲突。

B 依赖的 A 和最终的 A 不是同一个对象。

那么如何解决这个问题？这个问题可以说没有办法解决。因为在一个 Bean 的生命周期最后，Spring提供了 BeanPostProcessor 可以去对 Bean 进行加工，这个加工不仅仅只是能修改 Bean 的属性值，也可以替换掉当前 Bean 。

在BeanPostProcessor 中可以完全替换掉某个 beanName 对应的 bean 对象。

而 BeanPostProcessor 的执行在 Bean 的生命周期中是处于属性注入之后的，循环依赖是发生在属性注入过程中的，所以很有可能导致，注入给 B 对象的 A 对象和经历过完整生命周期之后的 A 对象，不是一个对象。这就是有问题的。

所以在这种情况下的循环依赖，Spring 是解决不了的，因为在属性注入时，Spring 也不知道 A 对象后续会经过哪些 BeanPostProcessor 以及会对 A 对象做什么处理。

2、解决思想

某个 beanName 对应的最终对象和原始对象不是一个对象却会经常出现，这就是 AOP 。

AOP 就是通过一个 BeanPostProcessor 来实现的，在 Spring 中 AOP 利用的要么是 JDK 动态代理，要么 CGLib 的动态代理，所以如果给一个类中的某个方法设置了切面，那么这个类最终就需要生成一个代理对象。

一般过程就是：A 类—>生成一个普通对象–>属性注入–>基于切面生成一个代理对象–>把代理对象放入 singletonObjects 单例池中。

而 AOP 可以说是 Spring 中除开 IOC 的另外一大功能，而循环依赖又是属于 IOC 范畴的，所以这两大功能想要并存，Spring 需要特殊处理。

如何处理的，就是利用了第三级缓存 singletonFactories。

首先，singletonFactories 中存的是某个 beanName 对应的 ObjectFactory，在 bean 的生命周期中，生成完原始对象之后，就会构造一个 ObjectFactory 存入 singletonFactories 中。

// 添加三级缓存
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        //判断后置处理器是否实现了SmartInstantiationAwareBeanPostProcessor接口
        //调用SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference
        for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
            exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
        }
    }
    return exposedObject;
}

这个 ObjectFactory 是一个函数式接口，支持Lambda表达式：() ->getEarlyBeanReference(beanName, mbd, bean)。上面的Lambda表达式就是一个ObjectFactory，执行该Lambda表达式就会去执行getEarlyBeanReference方法。

public Object getEarlyBeanReference(Object bean, String beanName) {
   Object cacheKey = getCacheKey(bean.getClass(), beanName);
   this.earlyProxyReferences.put(cacheKey, bean); // 得到一个cachekey，cachekey就是beanName。
   return wrapIfNecessary(bean, beanName, cacheKey);
}

真正实现了该方法的类就是AbstractAutoProxyCreator，也就是通过@EnableAspectJAutoProxy注解导入的AOP核心接口AnnotationAwareAspectJAutoProxyCreator的父类。存入 singletonFactories 时并不会执行 lambda 表达式，也就是不会执行getEarlyBeanReference 方法。

从 singletonFactories 根据 beanName 得到一个 ObjectFactory ，然后执行 ObjectFactory ，也就是执行 getEarlyBeanReference 方法，此时会得到一个 A 原始对象经过 AOP 之后的代理对象，然后把该代理对象放入 earlySingletonObjects 中。

此时并没有把代理对象放入 singletonObjects 中，那什么时候放入到 singletonObjects 中呢？

此时，我们只得到了 A 原始对象的代理对象，这个对象还不完整，因为 A 原始对象还没有进行属性填充，所以此时不能直接把A的代理对象放入 singletonObjects 中，所以只能把代理对象放入earlySingletonObjects 。

假设现在有其他对象依赖了 A，那么则可以从 earlySingletonObjects 中得到 A 原始对象的代理对象了，并且是A的同一个代理对象。

当 B 创建完了之后，A 继续进行生命周期，而 A 在完成属性注入后，会按照它本身的逻辑去进行AOP，而此时我们知道 A 原始对象已经经历过了 AOP ，所以对于 A 本身而言，不会再去进行 AOP了，那么怎么判断一个对象是否经历过了 AOP 呢？

会利用上文提到的 earlyProxyReferences，在 AbstractAutoProxyCreator 的 postProcessAfterInitialization 方法中，会去判断当前 beanName 是否在 earlyProxyReferences，如果在则表示已经提前进行过 AO P了，无需再次进行 AOP。

对于 A 而言，进行了 AOP 的判断后，以及 BeanPostProcessor 的执行之后，就需要把 A 对应的对象放入 singletonObjects 中了，但是我们知道，应该是要 A 的代理对象放入 singletonObjects 中，所以此时需要从 earlySingletonObjects 中得到代理对象，然后入 singletonObjects 中。

至此，整个循环依赖解决完毕。
【注】循环依赖把A对象本来应该在属性注入后，进行的后置处理器操作（生成代理对象），提前到了B获取A做属性注入的时候。原始对象在三级缓存中，原始对象的代理对象存放在二级缓存中。当A属性结束后，不再进行该后置处理操作了。

总结（三级缓存的理解）

总结一下三级缓存：

「singletonObjects」：缓存某个 beanName 对应的经过了完整生命周期的bean；
「earlySingletonObjects」：缓存提前拿原始对象进行了 AOP 之后得到的代理对象，原始对象还没有进行属性注入和后续的 BeanPostProcesso r等生命周期；
「singletonFactories」：缓存的是一个 ObjectFactory ，主要用来去生成原始对象进行了 AOP之后得到的「代理对象」，在每个 Bean 的生成过程中，都会提前暴露一个工厂，这个工厂可能用到，也可能用不到，如果没有出现循环依赖依赖本 bean，那么这个工厂无用，本 bean 按照自己的生命周期执行，执行完后直接把本 bean 放入 singletonObjects 中即可，如果出现了循环依赖依赖了本 bean，则另外那个 bean 执行 ObjectFactory 提交得到一个 AOP 之后的代理对象（如果有 AOP 的话，如果无需 AOP ，则直接得到一个原始对象）。

参考资料

https://blog.csdn.net/a972669015/article/details/121496398（源码分析图非常好）

https://blog.csdn.net/weixin_44129618/article/details/122839774 （好文）