哪些循环依赖问题Spring解决不了？

前言

大家都知道 Spring 解决了循环依赖的问题，网上也可以搜到 Spring 是使用三级缓存来解决循环依赖的。
但有些时候循环依赖问题还是会导致启动报错。
也就说明，在某些情况下，Spring 是没有办法解决循环依赖问题的。
我们就来探究一下，哪些循环依赖场景是 Spring 没办法解决的？

版本约定

Spring 5.3.9 (通过 SpringBoot 2.5.3 间接引入的依赖)

正文

场景一： prototype 类型的循环依赖
描述： A --> B --> A，且 A,B 都是 scope=prototype

@Service
@Scope("prototype")
public class A {
    @Autowired
    private B b;
}

@Service
@Scope("prototype")
public class B {
    @Autowired
    private A a;
}

这种场景下会报如下错误：

Exception in thread "main" org.springframework.beans.factory.UnsatisfiedDependencyException: 
Error creating bean with name 'c1Service': Unsatisfied dependency expressed through field 'c2Service'; 
nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'c2Service': Unsatisfied dependency expressed through field 'c1Service'; 
nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'c1Service': Requested bean is currently in creation: Is there an unresolvable circular reference?

分析：

A 实例创建后，populateBean 时，会触发 B 的加载。
B 实例创建后，populateBean 时，会触发 A 的加载。由于 A 的 scope=prototype，从缓存中获取不到 A，要创建一个全新的 A。
这样，就会进入一个死循环。Spring 肯定是解决不了这种情况下的循环依赖的。所以，提前进行了 check，并抛出了异常。

解决：

在需要循环注入的属性上添加 @Lazy 

场景二： constructor 注入的循环依赖

描述： A --> B --> A，且 都是通过构造函数依赖的

@Service
public class A {
    private B b;
    
    public A(B b) {
        this.b=b;
    }
}

@Service
public class B {
    private A a;
    
    public B(A a) {
        this.a=a;
    }
}

这种场景下会报如下错：

Exception in thread "main" org.springframework.beans.factory.UnsatisfiedDependencyException: 
Error creating bean with name 'c1' defined in file [/target/classes/com/kvn/beans/circle/constructor/C1.class]: Unsatisfied dependency expressed through constructor parameter 0; 
nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'c2' defined in file [/target/classes/com/kvn/beans/circle/constructor/C2.class]: Unsatisfied dependency expressed through constructor parameter 0; 
nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'c1': Requested bean is currently in creation: Is there an unresolvable circular reference?

分析：

A 实例在创建时(createBeanInstance)，由于是构造注入，这时会触发 B 的加载。
B 实例在创建时(createBeanInstance)，又会触发 A 的加载，此时，A 还没有添加到三级缓存中，所以就会创建一个全新的 A。
这样，就会进入一个死循环。Spring 是解决不了这种情况下的循环依赖的。所以，提前进行了 check，并抛出了异常。

解决：

在需要循环注入的属性上添加 @Lazy
例如：public A(@Lazy B b){...}

场景三：普通的 AOP 代理 Bean 的循环依赖–默认是可以的

描述：

A --> B --> A, 且 A,B 都是普通的 AOP Proxy 类型的 bean

普通的 AOP proxy 类型指：通过用户自定义的 @Aspect 切面生成的代理 bean，区别于 @Async 标记的类产生的 AOP 代理

Spring 默认解决了 普通的 AOP 代理 Bean 的循环依赖 问题，这里单独拿出来，是为了与 @Async 增强的代理 Bean 场景 进行对比。

分析：

通常情况下， AOP proxy 的创建是在 initializeBean 的时候，通过 BeanPostProcessor 处理的。
A 在 createBeanInstance 之后，添加到三级缓存。populateBean 时触发 B 的加载。
B 在 createBeanInstance 之后，添加到三级缓存。populateBean 时触发 A 的加载，这时，三级缓存中有 A，那么通过三级缓存 ObjectFactory#get() 可以获取到 bean 的早期引用。

获取 bean 的早期引用的逻辑如下：

// AbstractAutowireCapableBeanFactory#getEarlyBeanReference()  
/**
 * Obtain a reference for early access to the specified bean, typically for the purpose of resolving a circular reference.
 * 获取指定 bean 的早期引用，通常用于解析循环引用。
 */
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
            exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
        }
    }
    return exposedObject;
}

普通的 AOP 代理都是通过 AbstractAutoProxyCreator 来生成代理类的，而 AbstractAutoProxyCreator 实现了 SmartInstantiationAwareBeanPostProcessor，所以，在通过三级缓存 getEarlyBeanReference() 的时候，就可以提前获取到最终暴露到 Spring 容器中的代理 bean 的早期引用(正常是要在initializeBean 时生成代理，现在populateBean 就生成了代理，所以谓之提前)。

public abstract class AbstractAutoProxyCreator extends ProxyProcessorSupport
        implements SmartInstantiationAwareBeanPostProcessor, BeanFactoryAware {
    ......
}

所以，普通的 AOP 代理 bean 的循环依赖是没有问题的。

场景四：@Async 增强的 Bean 的循环依赖

描述：

A --> B --> A, 且 A 是被 @Async 标记的类

@Service
public class A {
    @Autowired
    private B b;
    
    @Async
    public void m1(){
    }
}

@Service
public class B {
    @Autowired
    private A a;
}

这种场景会报如下错：

Exception in thread "main" org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'p1Service': 
Bean with name 'p1Service' has been injected into other beans [p2Service] 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 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.

可能大家会有很深的疑问，刚刚场景三不是说 AOP 代理 bean 被循环依赖的场景是没有问题的，而 @Async 标记的类也是 AOP 代理，怎么就不行了呢？
那么，我们就要看 @Async 产生的代理和普通的 AOP 代理有什么区别了？

分析：

proxy 的创建是在 initializeBean 的时候，通过 BeanPostProcessor 处理的。
A 在 createBeanInstance 之后，添加到三级缓存。populateBean 时触发 B 的加载。
B 在 createBeanInstance 之后，添加到三级缓存。populateBean 时触发 A 的加载，这时，三级缓存中有 A，那么通过三级缓存 ObjectFactory#get() 可以获取到 bean 的早期引用。

普通的 AOP 代理都是通过 AbstractAutoProxyCreator 来生成代理类的，AbstractAutoProxyCreator 实现了 SmartInstantiationAwareBeanPostProcessor。
而 @Async 标记的类是通过 AbstractAdvisingBeanPostProcessor 来生成代理的，AbstractAdvisingBeanPostProcessor 没有实现 SmartInstantiationAwareBeanPostProcessor。

public abstract class AbstractAdvisingBeanPostProcessor extends ProxyProcessorSupport implements BeanPostProcessor {
    .......
}

所以，这时通过 A 的三级缓存来获取 bean 的早期引用时，获取到的是 bean 的原始对象的引用，而不会提前生成代理对象。
这时 B 中注入的 A 对象不是代理对象。最后会导致 B 中持有的 A 对象与 Spring 容器中的 bean A 不是同一个对象（Spring 容器中的 bean AinitializeBean 产生的代理）。
这种情况显然是有问题的，跟我们的预期是不相符的，所以，Spring 在 initializeBean 之后，做了 check，检验二级缓存中的 bean 与最终暴露到 Spring 容器中的 bean 是否是相同的，如果不同，就会报错。

综上，@Async 标记的类产生的代理 bean 发生了循环依赖， Spring 默认是解决不了的。

二级缓存中存放的是 bean 的早期引用，与最终暴露到容器中的 bean 的引用必须是相同的。
如果最终暴露的 AOP 代理 bean 与 三级缓存中获取到的早期引用 不是同一个对象引用的话，那就说明被循环依赖注入的 bean 与最终暴露到 Spring 容器中的 bean 不相同，这样是不被允许的。
Spring 通过检查的机制，check 检验二级缓存中的 bean 与最终暴露到 Spring 容器中的 bean 是否是相同的，如果不同，就会报错。
 

 解决：

在需要循环注入的属性上添加 @Lazy，或者A加上@DependsOn(value = "b") 或者修改B的类名使其先于A实例化（这里不太好修改，我们假设是 Test>Test1>Test，要Test1先于Test实例化，可以将Test1改成Tes,这种方式跟@DependsOn一个道理，但很不优雅）Spring之@DependsOn的实现原理

小结

Spring 为我们解决了循环依赖的问题。下面这些情况下，默认是解决不了循环依赖问题的：

prototype 类型的循环依赖
constructor 注入的循环依赖
@Async 类型的 AOP Bean 的循环依赖
这些解决不了的场景都可以通过 @Lazy 来解决掉。

思考：

可能大家又有疑问了：为什么使用了 @Lazy 之后，就可以解决掉这些情况下的循环依赖问题呢？
 

————————————————
版权声明：本文为CSDN博主「老王学源码」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wang489687009/article/details/120546430