【Spring源码三千问】哪些循环依赖问题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，并抛出了异常。

如果对三级缓存的使用不清楚的话，可以点击传送门： Spring 是怎样解决循环依赖的

解决：
在需要循环注入的属性上添加 @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 的早期引用。

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 在 initializeBean 之后，做了 check，检验二级缓存中的 bean 与最终暴露到 Spring 容器中的 bean 是否是相同的，如果不同，就会报错。

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

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

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

小结

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

1. prototype 类型的循环依赖
2. constructor 注入的循环依赖
3. @Async 类型的 AOP Bean 的循环依赖

这些解决不了的场景都可以通过 @Lazy 来解决掉。

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

后续的文章会继续解开这个疑惑…

传送门：【Spring源码三千问】@Lazy为什么可以解决特殊的循环依赖问题？

---

SpringIoC源码视频讲解：

课程	地址
SpringIoC源码解读由浅入深	https://edu.51cto.com/sd/68e86

---

如果本文对你有所帮助，欢迎点赞收藏!

源码测试工程下载：
老王读Spring IoC源码分析&测试代码下载
老王读Spring AOP源码分析&测试代码下载

公众号后台回复：下载IoC 或者 下载AOP 可以免费下载源码测试工程…

阅读更多文章，请关注公众号: 老王学源码

---

系列博文：
【老王读Spring IoC-0】Spring IoC 引入
【老王读Spring IoC-1】IoC 之控制反转引入
【老王读Spring IoC-2】IoC 之 BeanDefinition 扫描注册
【老王读Spring IoC-3】Spring bean 的创建过程
【老王读Spring IoC-4】IoC 之依赖注入原理
【老王读Spring IoC-5】Spring IoC 小结——控制反转、依赖注入

相关阅读：
【Spring源码三千问】@Resource 与 @Autowired 的区别
【Spring源码三千问】bean name 的生成规则
【Spring源码三千问】BeanDefinition详细分析
【Spring源码三千问】Spring 是怎样解决循环依赖问题的?
【Spring源码三千问】哪些循环依赖问题Spring解决不了？
【Spring源码三千问】@Lazy为什么可以解决特殊的循环依赖问题？
【Spring源码三千问】BeanDefinition注册、Bean注册、Dependency注册有什么区别？
【Spring源码三千问】Bean的Scope有哪些？scope=request是什么原理？
【Spring源码三千问】为什么要用三级缓存来解决循环依赖问题？二级缓存行不行？一级缓存行不行？