Spring如何通过三级缓存解决循环依赖

矫情吗；* 2023-03-01 10:55 42阅读 0赞

# 什么是循环依赖 #

什么是循环依赖？比如如下一个例子

public class A{ 
    	private B b;
    }

public class B{ 
    	private A a;
    }

这个例子存在的问题：理论上spring创建A的时候依赖了B，然后spring就会去加载B，但是这个时候B又依赖了A，spring又去加载A，就会陷入一个死循环，但我们在实际使用spring的时候并没有出现这样的循环，这是因为spring设计之初就考虑了这个问题，那么spring是如何解决的呢？我们先要明确的是spring对循环依赖的处理有三种情况，分别为

1.  构造器的循环依赖：这种依赖spring是处理不了的，直 接抛出BeanCurrentlylnCreationException异常。
2.  单例模式下的setter循环依赖：通过“三级缓存”处理循环依赖。
3.  非单例循环依赖：无法处理。

# Spring如何通过三级缓存解决循环依赖 #

Spring中有三级缓存，分别如下

1.  singletonObjects：完成初始化的单例对象的cache（一级缓存）
2.  earlySingletonObjects ：完成实例化但是尚未初始化的，提前暴光的单例对象的Cache （二级缓存）
3.  singletonFactories ： 进入实例化阶段的单例对象工厂的cache （三级缓存）

Spring获取一个Bean的流程就说从一级到三级依次去寻找这个Bean

protected Object getSingleton(String beanName, boolean allowEarlyReference) { 
    	// Quick check for existing instance without full singleton lock
    	// 从一级缓存中获取
    	Object singletonObject = this.singletonObjects.get(beanName);
    	// 如果没有，且依赖的A正在初始化，那我们去尝试看看earlySingletonObjects（二级缓存）是否有对象
    	// earlySingletonObjects（二级缓存）存放的是还未实例化好对象
    	if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { 
    		// 从二级缓存中获取
    		singletonObject = this.earlySingletonObjects.get(beanName);
    		// 如果获取不到 但是支持获取EarlyReference
    		if (singletonObject == null && allowEarlyReference) { 
    			// 这里应该是Spring 5.x的优化，只有一二级缓存中都获取不到的时候才进行加锁，相对于5.x以前的一开始就加锁后移了，提高了性能
    			synchronized (this.singletonObjects) { 
    				// Consistent creation of early reference within full singleton lock
    				// 这里与5.x以前的一致
    				singletonObject = this.singletonObjects.get(beanName);
    				if (singletonObject == null) { 
    					singletonObject = this.earlySingletonObjects.get(beanName);
    					if (singletonObject == null) { 
    						// 从三级缓存中获取,需要注意的是这里获取的不是singletonObject了，而是一个ObjectFactory
    						// 这个ObjectFactory就是 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); 中的() -> getEarlyBeanReference(beanName, mbd, bean)
    						ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
    						if (singletonFactory != null) { 
    							// 通过从三级缓存中拿到的是一个工厂对象，这个工厂对象可以用于生产singletonObject并放入二级缓存中
    							singletonObject = singletonFactory.getObject();
    							// 把工厂生产出来的singletonObject放入二级缓存中
    							this.earlySingletonObjects.put(beanName, singletonObject);
    							this.singletonFactories.remove(beanName);
    
    
    							// 也就是说，这里的逻辑是 从三级缓存中拿到的是一个工厂对象，这个工厂对象可以用于生产singletonObject并放入二级缓存中
    							// 为什么不把原对象直接放入二级缓存中呢？因为可能有AOP，所以需要生成代理对象
    							// 那为什么不直接把生成好的代理对象放入二级缓存中呢？因为为了性能考虑，如果没有循环引用，是不需要生成对象的。如果我们早早的就在doCreateBean方法中生成好了对象并放入二级缓存中，那是不是影响性能呢？
    						}
    					}
    				}
    			}
    		}
    	}
    	return singletonObject;
    }

如果一二三级均没有这个Bean，就会走新建方法，Spring创建一个Bean的时候也会有3个步骤，如下

1.  createBeanInstance：实例化，其实也就是调用对象的构造方法实例化对象
2.  populateBean：填充属性，这一步主要是多bean的依赖属性进行填充
3.  initializeBean：调用spring xml中的init 方法。

我们再来说上面的循环依赖的例子Spring的解决方案：

1.  A首先完成了初始化的第一步，并且将自己提前曝光到singletonFactories中，此时进行第二步填充属性
2.  发现自己依赖对象B，此时就尝试去get(B)，发现B还没有被create，所以走create流程，B在初始化第一步的时候发现自己依赖了对象A，于是尝试get(A)
3.  尝试从一级缓存singletonObjects中获取(肯定没有，因为A还没初始化完全)
4.  尝试从二级缓存earlySingletonObjects中获取（也没有）
5.  尝试三级缓存，由于A通过ObjectFactory将自己提前曝光了，所以B能够通过从三级缓存中拿到A的工厂对象，通过这个工厂对象构建出了A的Bean对象，B拿到A对象后顺利完成了初始化阶段1、2、3。B对象完全初始化之后将自己放入到一级缓存singletonObjects中
6.  此时返回A中，A此时能拿到B的对象顺利完成自己的初始化阶段2、3，最终A也完成了初始化，进去了一级缓存singletonObjects中。

为了更好的理解，我们来看看往三级缓存中放入A工厂对象的关键代码

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");
    	}
    	// 重点：Spring解决循环依赖的关键
    	// 把当前bean对象的工厂对象加入到三级缓存中
    	addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
    }

`() -> getEarlyBeanReference(beanName, mbd, bean)`即为构建了一个`ObjectFactory`对象，后续可以通过这个工厂对象构建出Bean对象

# 为什么构造器循环依赖和多例循环依赖Spring无法解决 #

**构造器循环依赖**  
循环依赖的解决是实例化后通过三级缓存来解决的，但构造器是在实例化时调用的，此时bean还没有实例化完成。如果此时出现了循环依赖，一二三级缓存并没有Bean实例的任何相关信息，因此当getBean的时候缓存并没有命中，这样就抛出了循环依赖的异常了。总结：spring的三级缓存解决的是实例化之后属性赋值的循环依赖，构造器被调用是在实例化之前，所以无法解决构造器的循环依赖！

**多例循环依赖**  
对于`prototype`作用域bean, Spring 容器无法完成依赖注入，因为Spring 容器不进行缓存`prototype`作用域的bean ，因此无法提前暴露一个创建中的bean。

# 为什么不能只用一二级缓存来解决循环依赖？ #

这里面涉及到的问题很复杂，可以看[这篇文章][Link 1]。  
总结起来就是几点：一级缓存是放完全初始化好的对象的，如果只需要IOC功能其实一级缓存就能解决。但涉及到循环依赖，我们就需要暴露出一个没有初始化好的对象，所以这个时候就需要引入二级缓存，把初始化好的放到一级缓存里面去，没初始化完全的放到二级缓存里面去。看起来可以完美解决问题了，但如果有代理对象的话，实际流程就会变成下面这样。我们假设上诉例子中A为代理对象

1.  A初始化的时候把能够生成A代理对象的一个A工厂对象放到三级缓存中
2.  A发现自己依赖B对象就去生成B对象，B对象发现自己需要A对象，就会去三级缓存中把这个A工厂对象取出来并且生成了A对象的代理对象，然后把代理对象放入到二级缓存，同时赋值B对象中的A，到此B对象构建完毕并放入一级缓存中。
3.  A对象使用构建好的B对象构建自己，A对象构建完毕。

[Link 1]: https://www.cnblogs.com/grey-wolf/p/13034371.html