目录
什么是spring循环依赖
什么情况下循环依赖可以被处理?
spring 如何解决循环依赖
创建A这个Bean的流程
答疑
疑问:在给B注入的时候为什么要注入一个代理对象?
初始化的时候是对A对象本身进行初始化,而容器中以及注入到B中的都是代理对象,这样不会有问题吗?
三级缓存为什么要使用工厂而不是直接使用引用?换而言之,为什么需要这个三级缓存,直接通过二级缓存暴露一个引用不行吗?
假设我们在这里直接使用二级缓存的话,那么意味着所有的Bean在这一步都要完成AOP代理。这样做有必要吗?
总结
什么是spring循环依赖
对于一个对象的字段,在spring里面我们都是通过自动的依赖注入来完成该对象的初始化。
正常的spring创建流程是对象的创建->对象的属性填充->对象的初始化->放入IOC容器。
依赖注入就是a依赖于b,而b又依赖于a,a初始化的时候发现需要实例b,但是b没有创建,就会进入b的创建逻辑。
在b的创建逻辑里面,当b进行初始化的时候又发现a没有创建完毕(a正在创建中),然后又进入a的创建逻辑,如此循环往复。
循环依赖又分为:
- 字段循环依赖
- 构造函数循环依赖
//构造函数循环依赖
@Component
public class A {
// A中注入了B
@Autowired
private B b;
public A(B b) {
}
}
@Component
public class B {
// B中也注入了A
@Autowired
private A a;
public B(A a) {
}
}
//当然,这是最常见的一种循环依赖,比较特殊的还有
// 自己依赖自己
@Component
public class A {
// A中注入了A
@Autowired
private A a;
}
什么情况下循环依赖可以被处理?
在回答这个问题之前首先要明确一点,Spring解决循环依赖是有前置条件的
1、出现循环依赖的Bean必须要是单例
2、依赖注入的方式不能全是构造器注入的方式
其中第一点应该很好理解,第二点:不能全是构造器注入是什么意思呢?
//构造函数循环依赖
@Component
public class A {
public A(B b) {
}
}
@Component
public class B {
public B(A a){
}
}
在上面的例子中,A中注入B的方式是通过构造器,B中注入A的方式也是通过构造器,这个时候循环依赖是无法被解决,如果你的项目中有两个这样相互依赖的Bean,在启动时就出以下错误:Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name
'a'
: Requested bean is currently in creation: Is there an unresolvable circular reference
spring 如何解决循环依赖
spring在创建Bean的过程中分为三步
实例化,对应方法:AbstractAutowireCapableBeanFactory中的createBeanInstance方法
属性注入,对应方法:AbstractAutowireCapableBeanFactory的populateBean方法
初始化,对应方法:AbstractAutowireCapableBeanFactory的initializeBean
实例化,简单理解就是new了一个对象
属性注入,为实例化中new出来的对象填充属性
初始化,执行aware接口中的方法,初始化方法,完成AOP代理
场景驱动一下,还是a依赖于b,b依赖于a的情况。
a1.a的对象工厂通过构造函数实例化并提前暴露a(在三级缓存中存放a的对象工厂)
a2.a完成属性填充后,进行field的初始化,发现b没有创建,进入到b的创建逻辑。
b1.b的对象工厂通过构造函数实例化并提前暴露b(在三级缓存中存放b的对象工厂)
b2.b完成属性填充后,进行field的初始化。
先通过一级缓存(singletonObjects存储的是所有创建好了的单例Bean)去查看是否有已经完成bean创建的a实例,没有,然后再通过二级缓存(earlySingletonObjects完成实例化,但是还未进行属性注入及初始化的对象)去查看是否有提前暴露的a实例,没有,再通过三级缓存(singletonFactorys提前暴露的一个单例工厂,二级缓存中存储的就是从这个工厂中获取到的对象)去查看有没有提前暴露的a实例。有,将a从三级缓存升级到二级缓存,并通过setter完成b对a的依赖注入。
a3.b完成创建,a可以直接通过一级缓存获得b的实例。
创建A这个Bean的流程
从上图中我们可以看到,虽然在创建B时会提前给B注入了一个还未初始化的A对象,但是在创建A的流程中一直使用的是注入到B中的A对象的引用,之后会根据这个引用对A进行初始化,所以这是没有问题的。
答疑
疑问:在给B注入的时候为什么要注入一个代理对象?
答:当我们对A进行了AOP代理时,说明我们希望从容器中获取到的就是A代理后的对象而不是A本身,因此把A当作依赖进行注入时也要注入它的代理对象
初始化的时候是对A对象本身进行初始化,而容器中以及注入到B中的都是代理对象,这样不会有问题吗?
答:不会,这是因为不管是cglib代理还是jdk动态代理生成的代理类,内部都持有一个目标类的引用,当调用代理对象的方法时,实际会去调用目标对象的方法,A完成初始化相当于代理对象自身也完成了初始化
三级缓存为什么要使用工厂而不是直接使用引用?换而言之,为什么需要这个三级缓存,直接通过二级缓存暴露一个引用不行吗?
答:这个工厂的目的在于延迟对实例化阶段生成的对象的代理,只有真正发生循环依赖的时候,才去提前生成代理对象,否则只会创建一个工厂并将其放入到三级缓存中,但是不会去通过这个工厂去真正创建对象
我们思考一种简单的情况,就以单独创建A为例,假设AB之间现在没有依赖关系,但是A被代理了,这个时候当A完成实例化后还是会进入下面这段代码:
// A是单例的,mbd.isSingleton()条件满足
// allowCircularReferences:这个变量代表是否允许循环依赖,默认是开启的,条件也满足
// isSingletonCurrentlyInCreation:正在在创建A,也满足
// 所以earlySingletonExposure=true
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
// 还是会进入到这段代码中
if (earlySingletonExposure) {
// 还是会通过三级缓存提前暴露一个工厂对象
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
看到了吧,即使没有循环依赖,也会将其添加到三级缓存中,而且是不得不添加到三级缓存中,因为到目前为止Spring也不能确定这个Bean有没有跟别的Bean出现循环依赖。
假设我们在这里直接使用二级缓存的话,那么意味着所有的Bean在这一步都要完成AOP代理。这样做有必要吗?
不仅没有必要,而且违背了Spring在结合AOP跟Bean的生命周期的设计!Spring结合AOP跟Bean的生命周期本身就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来完成的,在这个后置处理的postProcessAfterInitialization方法中对初始化后的Bean完成AOP代理。如果出现了循环依赖,那没有办法,只有给Bean先创建代理,但是没有出现循环依赖的情况下,设计之初就是让Bean在生命周期的最后一步完成代理而不是在实例化后就立马完成代理。
总结
面试官:”Spring是如何解决的循环依赖?“
答: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在实例化后就要完成AOP代理,这样违背了Spring设计的原则,Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理,而不是在实例化后就立马进行AOP代理。