spring之我见- spring循环依赖为啥是三级缓存？

已于 2024-06-12 16:58:28 修改
阅读量2.4k 收藏 13
点赞数 5
分类专栏： Spring之我见 文章标签： 循环依赖 spring ioc
于 2020-03-06 15:35:34 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lovejj1994/article/details/104664333
版权

单例在spring里的获取方式

今天讲一下spring中针对单例bean的循环依赖问题，本着追本溯源的学习理念，我们要先知道单例在spring中怎么管理的。spring获取实例都通过beanFactory的getBean方法获取实例，顺着代码而下，在doGetBean方法(AbstractBeanFactory)中，单例总是通过getSingleton()方法获取实例。

protected <T> T doGetBean(
			final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
			throws BeansException {

......
						// Create bean instance.
				if (mbd.isSingleton()) {
					sharedInstance = getSingleton(beanName, () -> {
						try {
							return createBean(beanName, mbd, args);
						}
						catch (BeansException ex) {
							destroySingleton(beanName);
							throw ex;
						}
					});
					beanInstance = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
				}
......
}

getSingleton和createBean方法大致流程(单例)：

  • 先从缓存拿（从第一层到第三层缓存中依次获取）
  • 创建对象准备工作（beforeSingletonCreation）：把beanName标记为正在创建中（singletonsCurrentlyInCreation.add）
  • 对象实例化（createBeanInstance）：，通过其定义里的class找到构造器方法反射创建实例
  • 提前暴露对象解决循环引用问题（Eagerly cache singletons to be able to resolve circular references）：如果此beanName为正在创建中，则把其对象工厂放入第三层缓存（addSingletonFactory）
    • 有一个bean拓展点，getEarlyBeanReference 是一个延迟动作，等其它类依赖获取这个对象的时候会触发（SmartInstantiationAwareBeanPostProcessor，本质也是BeanPostProcessor）。
  • 对象初始化：
    • populateBean 装配对象变量：获取此bean中有@Autowired等注解的成员变量，从所有bean定义中找出此类型的beanName，又通过BeanFactory#getBean方法获取实例，然后反射设值成员变量.
    • initializeBean：我们熟知的 applyBeanPostProcessorsBeforeInitialization （BeanPostProcessor） 和 InitializingBean 和 applyBeanPostProcessorsAfterInitialization （BeanPostProcessor）等拓展点.
  • 循环依赖检查
  • 创建对象结束工作（afterSingletonCreation）：移除正在创建中的标记（singletonsCurrentlyInCreation.remove），把实例放入第一层缓存，移除第二、三层中的缓存（addSingleton），最后返回实例

不熟悉源码的同学可能看着云里雾里，其实这里得分成两块来看：标黑的是创建bean的主流程，其他的是发生循环依赖（bean相互引用）时的处理。

三级缓存

Spring给了三个map，也就是三级缓存：

  • 一级缓存 ： singletonObjects 初始化完后的单例都会存在这个map中，一般ioc容器初始完后，你再用getBean取实例都可以从这里获取到。
  • 二级缓存 ：earlySingletonObjects 提前曝光的实例，这时候bean还处于创建中（bean的创建分为 实例化 和 初始化），没有完全创建好。
  • 三级缓存 ：singletonFactories 跟二级缓存要放在一起看，这里存的只是一个工厂类，需要通过getObject获取实例，实例获取到以后会放到二级缓存，只会执行一遍。

	/** Cache of singleton objects: bean name to bean instance. */
	private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

	/** Cache of singleton factories: bean name to ObjectFactory. */
	private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

	/** Cache of early singleton objects: bean name to bean instance. */
	private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);

再来看看Spring对三级缓存的获取逻辑，这段代码的含义就是 先从一级缓存中获取实例，取不到，再去取二级缓存，再没有，那就三级中取。 注意: 当从三级中取到实例时，会删除三级缓存中的值，然后放入二级缓存，二/三级缓存是一体的，三级缓存的工厂类是为了延迟执行（怎么延迟执行后面说），然后二级缓存是为了存放三级缓存getObject的结果，所以每个对象的三级缓存只会执行一遍，所以其实我们就把三级缓存当成两级缓存（一级缓存和二/三级缓存），这样对整体机制的理解有帮助，减少理解的成本。

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
		Object singletonObject = this.singletonObjects.get(beanName);
		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
			synchronized (this.singletonObjects) {
				singletonObject = this.earlySingletonObjects.get(beanName);
				if (singletonObject == null && allowEarlyReference) {
					ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
					if (singletonFactory != null) {
						singletonObject = singletonFactory.getObject();
						this.earlySingletonObjects.put(beanName, singletonObject);
						this.singletonFactories.remove(beanName);
					}
				}
			}
		}
		return (singletonObject != NULL_OBJECT ? singletonObject : null);
	}

我们还要知道Spring对一个bean的拓展点有哪些，这对我们理解Spring循环依赖处理有帮助。

从上文我们知道一个bean在创建过程中因为拓展点的存在，可能会产生两个对象（狸猫换太子）：

  • 一个是循环依赖时需要设值依赖的对象（getEarlyBeanReference）
  • 一个是初始化后的对象（initializeBean）

如果现在要对bean做增强，比如实现切面，则需要生成代理类，所以spring在上述两个方法中通过BeanPostProcessor类提供了拓展点。

当我们铺垫完上面的基础源码流程，我们开始引出本文的核心：什么是循环依赖和Spring循环依赖解决方案。

循环依赖的问题和Spring的解决方案

上一章我们讲了单例如何从三个缓存中去取，可是为什么要设计这个缓存我们听的云里雾里，这里我们就抛出开发中存在的问题：循环依赖。

我们知道，当A 有一个 属性 B , B 有一个属性A时，就形成了循环依赖，按照单例bean的创建逻辑，A没创建完，就去拿B，B还没创建完，又去拿A，请问A在哪？A还没创建完呢 ! 所以解决问题的关键在哪？spring给设计了一个多级缓存，当A完成实例化(createBeanInstance)时，这个实例已经有了自己的内存地址，只是对象不够完善，spring先把这种对象放进一个缓存。然后装配属性的时候需要B时 ，B开始自己的创建之旅，途中B需要A了，它就可以从缓存中顺利拿到实例A，即使这时候的A并不完善。 然后B把自己创建完成后，又轮到A继续完善自己，直到 A和B 都创建完毕，这样就没有了循环依赖的问题。

下面用图反映spring bean的大致创建流程 与 多级缓存之间的配合：

  • 当实例化完一个初始bean时，会先放入三级缓存，记住，这里的A还只是一个 初生的婴儿，没有属性装配，没有经历初始化,是个ObjectFactory。
  • 然后经历装配bean属性的过程。期间属性涉及到 循环依赖的时候，就可以通过第三缓存拿到对象。拿到后删除三级缓存，放入二级缓存。
  • 实例创建完毕后会删除二，三级缓存，放入一级缓存。一级缓存就是 spring单例对象的完全体，后面程序可以通过beanFactory 随时取用。

在这里插入图片描述

在经历拓展点情况下的循环依赖检查

在了解了解决循环依赖的基本原理后，我们要知道这种情况只能解决最理想的循环依赖情况（没有经历拓展点的Bean），但是Spring预留了两处拓展点，拓展点意味着Bean的返回值有可能跟原始Bean不再一样，比如原始Bean是A，那么A跟其它对象的依赖的A必须要内存地址一致才行，这时候看看Spring怎么检查循环依赖的。

我们重点关注一下下面的代码，从doCreateBean方法中看到如下示例代码，这段代码在装配完bean（populateBean）后开始执行，会看到其中调用了getSingleton(beanName, false)，这里其实是 这个bean是否存在被其它bean依赖的一次检查：

这里有三个对象我们需要留意，一个是earlySingletonReference ，一个是exposedObject，一个是 bean。

bean是最原始的对象，不会被任何流程修改。

earlySingletonReference，代表这个bean是否存在被其它bean依赖的情况。因为第二个参数为false，看里面的实现可以知道，false的话是不会执行工厂类的方法的，换句话说，一定是哪里依赖了这个对象，才会执行了工厂类的getObject方法，earlySingletonReference的值才不为空。

当发现这个bean是存在被其它bean依赖的情况（earlySingletonReference！=null），Spring就要开始提高警惕了，Spring会再判断exposedObject == bean，exposedObject 是可能被initializeBean这个拓展点修改的，如果相等，那么一切都好说，Spring通过把exposedObject 的引用指向了二级缓存中的对象，从而保证不管是A本身也好，还是其它对象依赖的A也好，都能保证一致。

如果不相等，那就麻烦了！这代表着其它对象依赖的A与exposedObject 是不一样的对象， 代码会开始找哪些对象会依赖B（根据beanName查找），最终发现还真不少(actualDependentBeans不为空)，然后就会开始报错，项目启动失败。

		if (earlySingletonExposure) {
			Object earlySingletonReference = getSingleton(beanName, false);
			if (earlySingletonReference != null) {
				if (exposedObject == bean) {
					exposedObject = earlySingletonReference;
				}
				else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
					String[] dependentBeans = getDependentBeans(beanName);
					Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
					for (String dependentBean : dependentBeans) {
						if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
							actualDependentBeans.add(dependentBean);
						}
					}
					if (!actualDependentBeans.isEmpty()) {
						throw new BeanCurrentlyInCreationException(beanName,
								"Bean with name '" + beanName + "' has been injected into other beans [" +
								StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
								"] 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 " +
								"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
					}
				}
			}
		}

所以，为什么是三层缓存

在前面说了那么多的情况下，可能大家还是没理解为什么要用三层缓存，甚至觉得Spring是过度设计。

不知道大家有没有理解getEarlyBeanReference，按照注释，它是为了解决循环依赖的，那么对于Spring IOC的主体流程中，getEarlyBeanReference被设计成需要的时候才执行,什么时候是需要的？那当然是存在相互依赖的时候！所以Spring设计了一个可以延迟执行的ObjectFactory，所以Spring的三层缓存才被设计出来

		// Eagerly cache singletons to be able to resolve circular references
		// even when triggered by lifecycle interfaces like BeanFactoryAware.
		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
				isSingletonCurrentlyInCreation(beanName));
		if (earlySingletonExposure) {
			if (logger.isTraceEnabled()) {
				logger.trace("Eagerly caching bean '" + beanName +
						"' to allow for resolving potential circular references");
			}
			addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
		}

最后谈谈AOP跟拓展点

aop具体的原理可以看我aop的文章 spring之我见 - Spring AOP实现原理(上), spring之我见 - Spring AOP实现原理(下)
. 我这里直接说一下结论，有两个地方： 一个是BeanPostProcessors 的 postProcessAfterInitialization逻辑里，还有一个就在 getEarlyBeanReference 方法中, 这两个方法同属于 AbstractAutoProxyCreator 抽象类(继承BeanPostProcessor)，在创建bean的过程中会先执行 getEarlyBeanReference ，再执行postProcessAfterInitialization，两个方法都是创建代理对象的方法，但是会通过一个cache map避免重复执行，具体执行哪一个要视具体情况来定。

	@Override
	public Object getEarlyBeanReference(Object bean, String beanName) {
		Object cacheKey = getCacheKey(bean.getClass(), beanName);
		this.earlyBeanReferences.put(cacheKey, bean);
		return wrapIfNecessary(bean, beanName, cacheKey);
	}
.......
	@Override
	public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
		if (bean != null) {
			Object cacheKey = getCacheKey(bean.getClass(), beanName);
			if (this.earlyBeanReferences.remove(cacheKey) != bean) {
				return wrapIfNecessary(bean, beanName, cacheKey);
			}
		}
		return bean;
	}

总结

总结三层缓存的话

第一层缓存：存放的是成品bean，项目启动完成后获取bean实例时，就会从这里取。
第二级缓存：创建bean过程中用于处理循环依赖的临时缓存，搭配第三层缓存，保证第三层缓存的ObjectFactory只执行一次
第三层缓存：创建bean过程中用于处理循环依赖的临时缓存，只有在存在循环依赖的情况下才会触发ObjectFactory的getObject方法（延迟触发），且获取对象会作为当前bean的最终对象

修订

2024.06.12 依据 【超级干货】为什么spring一定要弄个三级缓存？重新修订了本文章，并引用重新组织了部分内容，感谢原作者！！

葵续浅笑
关注
  • 5
    点赞
  • 踩
  • 13
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Spring三级缓存解决循环依赖.pdf
06-22
Spring三级缓存解决循环依赖.pdf
太可惜了，Spring中的循环依赖问题，只有10%的人才算“真的懂”
文章中资料均可获取，有需要请添加yunduoa2019即可
10-09 1920
前言 Spring中的循环依赖一直是Spring中一个很重要的话题，一方面是因为源码中为了解决循环依赖做了很多处理，另外一方面是因为面试的时候，如果问到Spring中比较高阶的问题，那么循环依赖必定逃不掉。如果你回答得好，那么这就是你的必杀技，反正，那就是面试官的必杀技，这也是取这个标题的原因，当然，本文的目的是为了让你在之后的所有面试中能多一个必杀技，专门用来绝杀面试官！ 本文的核心思想就是， 当面试官问： “请讲一讲Spring中的循环依赖。”的时候， 我们到底该怎么回答？ 主要分下面几点
Spring循环依赖为何使用三级缓存？
Java技术攻略的博客
04-24 283
这实际上涉及到 AOP，如果创建的 Bean是有代理的，那么注入的就应该是代理 Bean，而不是原始的 Bean。但是 Spring一开始并不知道 Bean是否会有循环依赖，通常情况下（没有循环依赖的情况下），Spring 都会在完成填充属性，并且执行完初始化方法之后再为其创建代理。但是，如果出现了循环依赖的话，Spring 就不得不为其提前创建代理对象，否则注入的就是一个原始对象，而不是代理对象。因此，这里就涉及到应该在哪里提前创建代理对象。
什么是spring三级缓存
最新发布
2301_76166241的博客
06-20 971
我们可以在:即单例缓存Map，其内部存储的都是以bean的名称为key，已经完全创建的bean作为value的Map。:该缓存都bean的工厂方法，可能有些读者不太理解，我们就以上文的AService为例，在Spring进行每一个bean初始化时，都会为这个bean封装一个工厂方法用于bean的创建，这一点笔者也会在后续的代码中提及，这里我们只需要知道这个缓存是以bean的名称作为key，创建该bean的工厂方法为value的Map即可。：其内部缓存的都是未完全完成创建的bean，就比如某个Service。
Spring 为什么要用三级缓存来解决循环依赖（AOP），二级缓存不行吗
qq_48051666的博客
12-15 2921
Spring 为什么要用三级缓存用来解决循环依赖（AOP），二级缓存不行吗
Spring的Bean加载和三级缓存解决循环依赖
花未央D8023的博客
10-31 1392
转载来源:https://www.cnblogs.com/semi-sub/p/13548479.html 前言 在使用spring框架的日常开发中，bean之间的循环依赖太频繁了，spring已经帮我们去解决循环依赖问题，对我们开发者来说是无感知的，下面具体分析一下spring是如何解决bean之间循环依赖，为什么要使用到三级缓存，而不是二级缓存 bean生命周期 首先大家需要了解一下bean在spring中的生命周期，bean在spring的加载流程，才能够更加清晰知道sp...
Spring——三级缓存解决循环依赖详解
共勉
11-29 1万+
结合Spring源码分析三级缓存分别是什么？在哪里产生？一张图搞清楚到底是怎么解决循环依赖的？一张图搞清楚二级缓存行不行？
3. 循环依赖问题（三级缓存）.xmind
08-29
《spring源码之循环依赖和三级缓存》整理，本人水平有限，从网上找的资料整合之后做的，请辩证的看待其中内容。
详解Spring-bean的循环依赖以及解决方式
08-27
Spring Bean 循环依赖详解及解决方案 在 Spring 框架中，Bean 的循环依赖是...Spring Bean 的循环依赖是一个复杂的问题，但通过三级缓存机制，Spring 能够很好地解决这个问题，使得单例对象可以被正确地创建和初始化。
浅谈Spring解决循环依赖的三种方式
08-28
Spring框架提供了三种方式来解决循环依赖问题：构造器参数循环依赖、setter方法循环依赖和使用三级缓存解决循环依赖。 第一种：构造器参数循环依赖 构造器参数循环依赖是指通过构造器注入构成的循环依赖。这种依赖...
探秘Spring框架解决循环依赖的高效策略
12-13
Spring框架在处理循环依赖...总之，Spring通过三级缓存和AOP代理机制，实现了对循环依赖的高效处理，保证了应用的稳定性和性能。这个解决方案不仅体现了Spring的灵活性，也为Java开发者提供了宝贵的设计和架构经验。
spring为什么要使用三级缓存来解决循环依赖?
多看多听多总结
07-04 1434
spring为什么要使用三级缓存来解决循环依赖?
Spring三级缓存解决循环依赖问题
trong_ 的烂笔头
10-26 4123
解析理解在互相依赖的 Bean 是单例的、依赖注入的方式不都是构造注入的前提下如何使用三级缓存解决Spring中的循环依赖的问题。
Spring 动态代理时是如何解决循环依赖的？为什么要使用三级缓存？
架构师专栏
12-10 354
最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。这是大佬写的，7701页的BAT大佬写的刷题笔记，让我offer拿到手软。
Spring 为什么使用三级缓存解决循环依赖
devops
08-23 1018
类A需要类B，我们就叫做类A依赖类B。简单说就是⾃⼰依赖⾃⼰，或者和别的类相互依赖。
为什么要用三级缓存来解决循环依赖问题？二级缓存行不行？一级缓存行不行？
meser88的博客
05-23 1265
如果在 initializeBean 的时候记录缓存，那么碰到循环依赖的情况，需要在 populateBean(第二阶段) 的时候再去注入循环依赖的 bean，此时，缓存中是没有循环依赖的 bean 的，就会导致 bean 重新创建实例。假设 bean 是需要 AOP 增强的，那么最终放到缓存中的应该是一个代理 bean。再利用上面的反例来分析一遍，放入一级缓存的 bean 与暴露到容器中的 bean (不管是否有代理)始终是同一个 bean，看似好像是没有问题的，好像是可以解决循环依赖的问题。
Spring中的“三级缓存”
热门推荐
weixin_44181671的博客
09-16 2万+
Spring的“三级缓存”基础认识常见问题循环依赖代码示例Spring 中三大循环依赖场景 演示Spring 循环依赖小结“三级缓存”意义Spring 解决循环依赖原理分析Spring 容器的“三级缓存”源码解析 常见问题 循环依赖 循环依赖：就是 N 个类循环（嵌套）使用。 简单来说，就是多个 Bean 之间互相依赖或引用到对方，最终形成了 闭环。循环依赖的关系可以表示成下图 上图中的 A，B，C 代表三个不同的对象，上图表示了三者的引用关系。 循环依赖不仅发生在多个类中，还可能发生在本类中，即 N =
【Java面试题】Spring 为何需要三级缓存解决循环依赖，而不是二级缓存
扛麻袋的少年的博客
06-01 1540
1.Spring bean生命周期 2.Spring 如何解决 bean 之间循环依赖
Spring 解决循环依赖为什么需要三级缓存，而不是两级缓存?
有来技术
12-19 3373
本文探讨了Spring框架处理循环依赖的机制，特别是为什么采用三级而非两级缓存。分析了三级缓存如何优雅解决依赖注入和代理问题，确保Bean生命周期的一致性和应用的稳定性。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值