1.单例Bean循环依赖-setter产生的循环依赖
1.1 原理
为单例搞的三个 map:
- 一级缓存,singletonObjects,存储所有已创建完毕的单例 Bean (完整的 Bean)
- 二级缓存,earlySingletonObjects,存储所有仅完成实例化,但还未进行属性注入和初始化的 Bean
- 三级缓存,singletonFactories,存储能建立这个 Bean 的一个工厂,通过工厂能获取这个 Bean,延迟化 Bean 的生成,工厂生成的 Bean 会塞入二级缓存
getBean()步骤:
- getSingleton(beanName) 依次从三个缓存中获取
- 实例化
- addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
- 属性注入
- 初始化
一个大致过程: getBean(A),AB循环依赖
- A执行属性注入,这个时候 A 发现需要注入 B,所以去 getBean(B),此时又会走一遍上面描述的逻辑。
- 到了 B 的属性注入这一步,此时 B 调用 getBean(A),这时候一级缓存里面找不到,但是发现 A 正在创建中的,于是去二级缓存找,发现没找到,于是去三级缓存找,然后找到了。
并且通过上面提前在三级缓存里暴露的工厂得到 A,然后将这个工厂从三级缓存里删除,并将 A 加入到二级缓存中。
然后结果就是 B 属性注入成功。
紧接着 B 调用 initializeBean 初始化,最终返回,此时 B 已经被加到了一级缓存里 。 - 这时候就回到了 A 的属性注入,此时注入了 B,接着执行初始化,最后 A 也会被加到一级缓存里,且从二级缓存中删除 A。
1.2 getSingleton()
getSingleton()并发安全问题?以及5.3后变了,为啥变了?
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
// Quick check for existing instance without full singleton lock
// 到一级缓存获取
Object singletonObject = this.singletonObjects.get(beanName);
// 条件一:一级缓存不存在
// 1)单实例未创建
// 2)单实例循环依赖(三级缓存解决setter循环依赖)
//1.假设Spring先实例化A,首先拿到A的构造方法,进行反射创建出来A的早期实例对象,这个时候,这个早期对象被包装成了ObjectFactory对象,放到了3级缓存。
//2.处理A的依赖数据,检查发现,A它依赖了B对象,所以接下来,Spring就会去根据B类型到容器中去getBean(B.class),这里就递归了。
//3.拿到B的构造方法,进行反射创建出来B的早期实例对象,它也会把B包装成ObjectFactory对象,放到3级缓存。
//4.处理B的依赖数据,检查发现,B它依赖了A对象,所以接下来,Spring就会去根据A类型到容器中去getBean(A.class),去拿A对象,这个又递归了。
//5.程序还会走到当前这个方法。getSingleton这个方法。
//6.条件一成立,条件二也会成立。
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
// 检查二级缓存
singletonObject = this.earlySingletonObjects.get(beanName);
// 二级缓存没有
if (singletonObject == null && allowEarlyReference) {
synchronized (this.singletonObjects) {
// Consistent creation of early reference within full singleton lock
singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null) {
//Spring为什么需要有3级缓存存在,而不是只有2级缓存呢?
//AOP,靠什么实现的呢?动态代理
//静态代理:需要手动写代码,实现一个新的java文件,这个java类 和 需要代理的对象 实现同一个接口,内部维护一个被代理对象(原生)
//代理类,在调用原生对象前后,可以加一些逻辑. 代理对象 和 被代理对象 是两个不同的对象,内存地址一定是不一样的。
//动态代理:不需要人为写代码了,而是依靠字节码框架动态生成class字节码文件,然后jvm再加载,然后也一样 也是去new代理对象,这个
//代理对象 没啥特殊的,也是内部保留了 原生对象,然后在调用原生对象前后 实现的 字节码增强。
//3级缓存在这里有什么目的呢?
//3级缓存里面保存的是对象工厂,这个对象工厂内部保留着最原生的对象引用,ObjectFactory的实现类,getObject()方法,它需要考虑一个问题。
//它到底要返回原生的,还是增强后的。
//getObject会判断当前这个早期实例 是否需要被增强,如果是,那么提前完成动态代理增强,返回代理对象。否则,返回原生对象。
ObjectFactory> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
// 将三级缓存数据提升到二级
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
}
}
return singletonObject;
}
1.3 为啥需要三级缓存?
三级缓存是否为延迟代理的创建,尽量不打破 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;
}
如果有代理的话,那么我们想要直接拿到的是代理对象。
也就是说如果 A 需要被代理,那么 B 依赖的 A 是已经被代理的 A,所以我们不能返回 A 给 B,而是返回代理的 A 给 B。
这个工厂的作用就是判断这个对象是否需要代理,如果否则直接返回,如果是则返回代理对象。
正常代理对象的生成是基于后置处理器,是 在被代理的对象初始化后期调用生成的 , 所以如果你提早代理了其实是违背了 Bean 定义的生命周期 。
所以 Spring 先在一个三级缓存放置一个工厂,如果产生循环依赖,那么就调用这个工厂提早得到代理对象。
如果没产生依赖,这个工厂根本不会被调用,所以 Bean 的生命周期就是对的。
其实破坏循环依赖,其实只有二级缓存就够了,但是碍于生命周期的问题,提前暴露工厂延迟代理对象的生成。
2.单例Bean循环依赖-构造参数产生的循环依赖
2.1 构造参数为啥不能解决循环依赖
如果全是构造器注入,比如 A(B b) ,那表明在 new 的时候,就需要得到 B,此时需要 new B 。
但是 B 也是要在构造的时候注入 A ,即 B(A a) ,这时候 B 需要在一个 map 中找到不完整的 A ,发现找不到。
为什么找不到?因为 A 还没 new 完呢,所以找到不完整的 A, 因此如果全是构造器注入的话,那么 Spring 无法处理循环依赖 。
总结:
- 如果循环依赖都是构造器注入,则失败
- 如果循环依赖不完全是构造器注入,则可能成功,可能失败,具体跟BeanName的字母序有关系。
2.2 源码中的处理
getBean()步骤:
- getSingleton(beanName) 依次从三个缓存中获取
- getSingleton(beanName, ObjectFactory)
- beforeSingletonCreation(beanName) 处理构造器循环依赖
- 实例化,这里会getBean()构造器参数
- addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
- 属性注入
- 初始化
public Object getSingleton(String beanName, ObjectFactory> singletonFactory) {
Assert.notNull(beanName, "Bean name must not be null");
synchronized (this.singletonObjects) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
//容器销毁时,会设置这个属性为true,这个时候就不能再创建bean实例了,直接抛错。
if (this.singletonsCurrentlyInDestruction) {
throw new BeanCreationNotAllowedException(beanName,
"Singleton bean creation not allowed while singletons of this factory are in destruction " +
"(Do not request a bean from a BeanFactory in a destroy method implementation!)");
}
if (logger.isDebugEnabled()) {
logger.debug("Creating shared instance of singleton bean '" + beanName + "'");
}
//将当前beanName放入到“正在创建中单实例集合”,放入成功,说明没有产生循环依赖,失败,则产生循环依赖,里面会抛异常。
//举个例子:构造方法参数依赖
//A->B B->A
//1.加载A,根据A的构造方法,想要去实例化A对象,但是发现A的构造方法有一个参数是B(在这之前,已经向这个集合中添加了 {A})
//2.因为A的构造方法依赖B,所以触发了加载B的逻辑..
//3.加载B,根据B的构造方法,想要去实例化B对象,但是发现B的构造方法有一个参数是A(在这之前,已经向这个集合中添加了 {A,B})
//4.因为B的构造方法依赖A,所以再次触发了加载A的逻辑..
//5.再次来到这个getSingleton方法里,调用beforeSingletonCreation(A),因为创建中集合 已经有A了,所以添加失败,抛出异常
//完事。
beforeSingletonCreation(beanName);
protected void beforeSingletonCreation(String beanName) {
if (!this.inCreationCheckExclusions.contains(beanName) && !this.singletonsCurrentlyInCreation.add(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
}
3.原型模式的循环依赖
3.1 原型模式为啥不能解决循环依赖
如果两个 Bean 都是原型模式的话。
那么创建 A1 需要创建一个 B1。
创建 B1 的时候要创建一个 A2。
创建 A2 又要创建一个 B2。
创建 B2 又要创建一个 A3。
创建 A3 又要创建一个 B3.....
因为原型模式都需要创建新的对象,不能用以前的对象。
3.2 源码中的处理
getBean()步骤:
- getSingleton(beanName) 依次从三个缓存中获取
- 原型循环依赖问题判定
- beforePrototypeCreation(beanName); 加入到prototypesCurrentlyInCreation
- 实例化
- 属性注入
- 初始化
- afterPrototypeCreation(beanName);
//1、原型循环依赖问题判定
//举个例子:
//prototypeA -> B, B -> prototypeA
//1.会向正在创建中的原型集合内添加一个字符串 “A” 下面beforePrototypeCreation(beanName);
//2.创建prototypeA对象,只是一个早期对象。
//3.处理prototypeA的依赖,发现A依赖了B类型的对象
//4.触发了Spring.getBean(“B”)的操作。
//5.根据B的构造方法反射创建出来了B的早期实例
//6.Spring处理B对象的依赖,发现依赖了A。
//7.Spring转头回来再次去获取A去了。getBean(“A”).
//8.条件会返回true,最终抛出异常,算是结束了循环依赖注入。
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}