- 什么是循环依赖
- 循环依赖的常见场景
- spring解决循环依赖的方法:
- 在bean实例化完成,填充属性之前通过三级缓存提前暴露对象
- 缓存填充时机
- 为什么多例的Setter注入循环依赖不能解决:
- 为什么通过构造器注入依赖对象的循环依赖不能解决:
- 最简化的一种循环依赖模型是:A对象依赖于B对象,而B对象又依赖于A对象;
@Service public class TestService1 { @Autowired private TestService2 testService2; public void test1() { } } @Service public class TestService2 { @Autowired private TestService1 testService1; public void test2() { } }循环依赖的常见场景
- 单例(singleton)普通对象的setter注入:spring能够解决;
- 单例(singleton)代理对象的setter注入:spring有可能解决(主要看加载顺序以及触发代理增强的切入点)
- 多例(prototype)的setter注入:spring不能解决;
- 构造器注入:spring不能解决;
- 注解dependsOn循环依赖:spring不能解决;
- 三级缓存singletonFactories:存储生产单例对象实例的工厂ObjectFactory(解决循环依赖的重点之处)。ObjectFactory本质是一个模板函数,当对象间出现循环依赖时,会触发调用AbstractAutowireCapableBeanFactory#getEarlyBeanReference获取到一个早期公开的bean引用以解决循环依赖;
- 二级缓存earlySingletonObjects:存储已经实例化,并且已经应用SmartInstantiationAwareBeanPostProcessor进行代理增强的单例bean;二级缓存主要保证循环依赖中,被依赖的对象注入到其他对象中都是同一个实例(比如A依赖B、C,B依赖A,C依赖A,通过二级缓存earlySingletonObjects就可以保证注入到B、C对象中的A实例是同一个)
- 一级缓存singletonObjects:存储已经实例化、初始化的单例bean;
- 三级缓存在bean实例化完成之后进行填充:
- 二级缓存填充时机:在执行完从三级缓存获取到的ObjectFactory函数模板方法后,把提前暴露的bean实例放入二级缓存earlySingletonObjects
- 一级缓存填充时机:bean对象属性填充完毕,初始化完毕后放入一级缓存
从spring加载bean的源码中可以看到,当原型作用域的对象处于循环依赖时,会直接抛出异常。实质是原型作用域的对象每一次获取都必须重新实例化一个,也就不能够进行缓存提前暴露对象,所以spring解决循环依赖的三级缓存模型也就不适用了。
假设A依赖B,B依赖A
- 因为使用构造器加载对象A,会在实例化bean的时候去加载依赖的对象B(此时还没有把当前对象A加入到三级缓存中)。所以在getBean(B)时,又会触发加载A对象,但是最初的A对象并没有进入三级缓存,也就是没有提前暴露出来,所以spring无法解决;
- 可以使用@Lazy注解延迟加载某个对象从而破坏循环依赖;
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)