文档章节

Spring是怎么解决循环依赖的?

大王叫下
 大王叫下
发布于 10/14 10:24
字数 2102
阅读 1371
收藏 17

在上篇文章中,我们详细分析了doCreateBean()中的第2步:实例化bean,本文接着分析doCreateBean()的第4步“循环依赖处理”,也就是populateBean()方法。

首先回顾下Bean加载的主流程:

  1. 如果是单例模式,从factoryBeanInstanceCache 缓存中获取BeanWrapper 实例对象并删除缓存
  2. 调用 createBeanInstance() 实例化 bean
  3. 后置处理
  4. 单例模式的循环依赖处理
  5. 属性填充
  6. 初始化 bean 实例对象
  7. 依赖检查
  8. 注册 DisposableBean

本章我们主要分析第4步:

一、循环依赖是什么?

循环依赖,其实就是循环引用,就是两个或者两个以上的 bean 互相引用对方,最终形成一个闭环,如 A 依赖 B,B 依赖 C,C 依赖 A。如下图所示:

Spring中的循环依赖,其实就是一个死循环的过程,在初始化 A 的时候发现依赖了 B,这时就会去初始化 B,然后又发现 B 依赖 C,跑去初始化 C,初始化 C 的时候发现依赖了 A,则又会去初始化 A,依次循环永不退出,除非有终结条件。

一般来说,Spring 循环依赖的情况有两种:

构造器的循环依赖。 field 属性的循环依赖。 对于构造器的循环依赖,Spring 是无法解决的,只能抛出 BeanCurrentlyInCreationException 异常表示循环依赖,所以下面我们分析的都是基于 field 属性的循环依赖。

在前文 Spring Ioc源码分析 之 Bean的加载(三):各个 scope 的 Bean 创建 中提到,Spring 只解决 scope 为 singleton 的循环依赖。对于scope 为 prototype 的 bean ,Spring 无法解决,直接抛出 BeanCurrentlyInCreationException 异常。

为什么 Spring 不处理 prototype bean 呢?其实如果理解 Spring 是如何解决 singleton bean 的循环依赖就明白了。这里先留个疑问,我们先来看下 Spring 是如何解决 singleton bean 的循环依赖的。

二、解决singleton循环依赖

在AbstractBeanFactory 的 doGetBean()方法中,我们根据BeanName去获取Singleton Bean的时候,会先从缓存获取。
代码如下:

//DefaultSingletonBeanRegistry.java

@Nullable
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    // 从一级缓存缓存 singletonObjects 中加载 bean
    Object singletonObject = this.singletonObjects.get(beanName);
    // 缓存中的 bean 为空,且当前 bean 正在创建
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
        // 加锁
        synchronized (this.singletonObjects) {
            // 从 二级缓存 earlySingletonObjects 中获取
            singletonObject = this.earlySingletonObjects.get(beanName);
            // earlySingletonObjects 中没有,且允许提前创建
            if (singletonObject == null && allowEarlyReference) {
                // 从 三级缓存 singletonFactories 中获取对应的 ObjectFactory
                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
                    //从单例工厂中获取bean
                    singletonObject = singletonFactory.getObject();
                    // 添加到二级缓存
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    // 从三级缓存中删除
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return singletonObject;
}

这段代码涉及的3个关键的变量,分别是3个级别的缓存,定义如下:

	/** Cache of singleton objects: bean name --> bean instance */
	//单例bean的缓存 一级缓存
	private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

	/** Cache of singleton factories: bean name --> ObjectFactory */
	//单例对象工厂缓存 三级缓存
	private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

	/** Cache of early singleton objects: bean name --> bean instance */
	//预加载单例bean缓存 二级缓存
	//存放的 bean 不一定是完整的
	private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);

getSingleton()的逻辑比较清晰:

  • 首先,尝试从一级缓存singletonObjects中获取单例Bean。

  • 如果获取不到,则从二级缓存earlySingletonObjects中获取单例Bean。

  • 如果仍然获取不到,则从三级缓存singletonFactories中获取单例BeanFactory。

  • 最后,如果从三级缓存中拿到了BeanFactory,则通过getObject()把Bean存入二级缓存中,并把该Bean的三级缓存删掉。

2.1、三级缓存

看到这里可能会有些疑问,这3个缓存怎么就解决了singleton循环依赖了呢?
先别着急,我们现在分析了获取缓存的代码,再来看下存储缓存的代码。 在 AbstractAutowireCapableBeanFactorydoCreateBean() 方法中,有这么一段代码:

// AbstractAutowireCapableBeanFactory.java

boolean earlySingletonExposure = (mbd.isSingleton() // 单例模式
        && this.allowCircularReferences // 允许循环依赖
        && isSingletonCurrentlyInCreation(beanName)); // 当前单例 bean 是否正在被创建
if (earlySingletonExposure) {
    if (logger.isTraceEnabled()) {
        logger.trace("Eagerly caching bean '" + beanName +
                "' to allow for resolving potential circular references");
    }
    // 为了后期避免循环依赖,提前将创建的 bean 实例加入到三级缓存 singletonFactories 中
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

这段代码就是put三级缓存singletonFactories的地方,其核心逻辑是,当满足以下3个条件时,把bean加入三级缓存中:

  • 单例
  • 允许循环依赖
  • 当前单例Bean正在创建

addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) 方法,代码如下:

// DefaultSingletonBeanRegistry.java

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
	Assert.notNull(singletonFactory, "Singleton factory must not be null");
	synchronized (this.singletonObjects) {
		if (!this.singletonObjects.containsKey(beanName)) {
			this.singletonFactories.put(beanName, singletonFactory);
			this.earlySingletonObjects.remove(beanName);
			this.registeredSingletons.add(beanName);
		}
	}
}

从这段代码我们可以看出,singletonFactories 这个三级缓存才是解决 Spring Bean 循环依赖的关键。同时这段代码发生在 createBeanInstance(...) 方法之后,也就是说这个 bean 其实已经被创建出来了,但是它还没有完善(没有进行属性填充和初始化),但是对于其他依赖它的对象而言已经足够了(已经有内存地址了,可以根据对象引用定位到堆中对象),能够被认出来了。

2.2、一级缓存

到这里我们发现三级缓存 singletonFactories 和 二级缓存 earlySingletonObjects 中的值都有出处了,那一级缓存在哪里设置的呢?在类 DefaultSingletonBeanRegistry 中,可以发现这个 addSingleton(String beanName, Object singletonObject) 方法,代码如下:

// DefaultSingletonBeanRegistry.java

protected void addSingleton(String beanName, Object singletonObject) {
	synchronized (this.singletonObjects) {
	        //添加至一级缓存,同时从二级、三级缓存中删除。
		this.singletonObjects.put(beanName, singletonObject);
		this.singletonFactories.remove(beanName);
		this.earlySingletonObjects.remove(beanName);
		this.registeredSingletons.add(beanName);
	}
}

该方法是在 #doGetBean(...) 方法中,处理不同 scope 时,如果是 singleton调用的,如下图所示:

也就是说,一级缓存里面是完整的Bean。

小结:

  • 一级缓存里面是完整的Bean,是当一个Bean完全创建后才put
  • 三级缓存是不完整的BeanFactory,是当一个Bean在new之后就put(没有属性填充、初始化)
  • 二级缓存是对三级缓存的易用性处理,只不过是通过getObject()方法从三级缓存的BeanFactory中取出Bean
总结

现在我们再来回顾下Spring解决单例循环依赖的方案:

  • Spring 在创建 bean 的时候并不是等它完全完成,而是在创建过程中将创建中的 bean 的 ObjectFactory 提前曝光(即加入到 singletonFactories 三级缓存中)。

  • 这样,一旦下一个 bean 创建的时候需要依赖 bean ,则从三级缓存中获取。

举个栗子
比如我们团队里要报名参加活动,你不用上来就把你的生日、性别、家庭信息什么的全部填完,你只要先报个名字,统计下人数就行,之后再慢慢完善你的个人信息。

核心思想:提前暴露,先用着

最后来描述下就上面那个循环依赖 Spring 解决的过程:

  • 首先 A 完成初始化第一步并将自己提前曝光出来(通过 三级缓存 将自己提前曝光),在初始化的时候,发现自己依赖对象 B,此时就会去尝试 get(B),这个时候发现 B 还没有被创建出来

  • 然后 B 就走创建流程,在 B 初始化的时候,同样发现自己依赖 C,C 也没有被创建出来

  • 这个时候 C 又开始初始化进程,但是在初始化的过程中发现自己依赖 A,于是尝试 get(A),这个时候由于 A 已经添加至缓存中(三级缓存 singletonFactories ),通过 ObjectFactory 提前曝光,所以可以通过 ObjectFactory#getObject() 方法来拿到 A 对象,C 拿到 A 对象后顺利完成初始化,然后将自己添加到一级缓存中

  • 回到 B ,B 也可以拿到 C 对象,完成初始化,A 可以顺利拿到 B 完成初始化。到这里整个链路就已经完成了初始化过程了

最后,为什么多例模式不能解决循环依赖呢?
因为多例模式下每次new() Bean都不是一个,如果按照这样存到缓存中,就变成单例了。

参考
http://cmsblogs.com/?p=todo (小明哥)

© 著作权归作者所有

大王叫下
粉丝 20
博文 65
码字总数 60608
作品 0
杭州
私信 提问
加载中

评论(1)

f
freezingsky
最好的方式 , 就是调整代码结构, 不要产生这种依赖!
Spring的这七大问题,验证你能否进大厂!

  当程序员当的越久,接触的越多,就会越“迷茫”。像我,分布式好像懂一点,源码也好像懂一点。技术栈越来越多,但是好像哪一点也不精通,就会代码写得越多越“迷茫”。我可以很负责任的告...

java进阶架构师
11/13
0
0
Spring是怎么解决循环依赖的

什么是循环依赖? 循环依赖其实就是循环引用,也就是两个或则两个以上的bean互相持有对方,最终形成闭环。比如A依赖于B,B依赖于C,C又依赖于A。如下图: 注意,这里不是函数的循环调用,是对...

Jack1991
2018/04/27
258
0
spring循环依赖的三种方式

1.构造器参数循环依赖 对象间在构造函数中有相互依赖,通过构造函数注入 constructor-arg 启动是会报循环依赖错误 2.setter方式单例,默认方式 spring先通过无参构造方法创建bean,然后通过s...

素雷
2018/08/08
164
0
Spring bean循环依赖问题,与解决方案。

前言 我们知道 Spring 可以是懒加载的,就是当真正使用到 Bean 的时候才实例化 Bean。当然也不全是这样,例如配置 Bean 的 lazy-init 属性,可以控制 Spring 的加载时机。现在机器的性能、内...

边鹏_尛爺鑫
2018/11/27
183
0
最简 Spring IOC 容器源码分析

image 前言 许多文章都是分析的 xml 配置,但是现在 Spring Boot 开发多基于注解。本文从的角度分析 Spring IOC 容器源码。 版本: Spring Boot:2.1.6.RELEASE Spring FrameWork:5.1.8.REL...

被称为L的男人
11/08
0
0

没有更多内容

加载失败,请刷新页面

加载更多

交换两数(函数)

#define _CRT_SECURE_NO_WARNINGS #include <stdio.h> #include <stdlib.h> void Exchange(int* x, int* y){ int tmp = 0; tmp = *x; *x = *y; *y = tmp; } int main(){ int a; int b; scanf......

Lxxxxx256
32分钟前
3
0
给 K8s API “做减法”:阿里巴巴云原生应用管理的挑战和实践

作者 | 孙健波(天元) 阿里巴巴技术专家 本文整理自 11 月 21 日社群分享,每月 2 场高质量分享,点击加入社群。 早在 2011 年,阿里巴巴内部便开始了应用容器化,当时最开始是基于 LXC 技术...

阿里巴巴云原生
今天
6
0
数据平面

3.1数据平面的任务 解析数据包头 转发数据包到某些端口 通过查询由控制平面所生成的转发表 传统网络数据平面 数据包--输入端口---拆封和解析,转发策略匹配,转发调度---输出端口(协议相关,...

Firefly-
昨天
6
0
如何高效的阅读uni-app框架?(建议收藏)

作者 | Jeskson 来源 | 达达前端小酒馆 uni-app的框架,配置:page.json,manifest.json,package.json,vue.config.js。脚本,应用程序,main.js。日志打印,定时器,生命周期,页面,页面通...

达达前端小酒馆
昨天
8
0
实现原理专题--存储器的实现(三)

计算机实现原理专题--存储器的实现(二)中描述了一种电平触发器,但是某些应用需要在保持位从0到1变化的过程中对数据端进行保存。这种触发器叫边沿触发器。 一开始Q为0,时钟信号为0。当数据...

FAT_mt
昨天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部