看穿面试题--Spring循环依赖--背后的秘密

能救你，也许只有你自己吧。

一、面试为啥好问循环依赖问题

Spring是一个集大成者，我想能对其细节摸的透透的人，必定是大神级别了。

其实我一直好奇为啥网上一直流传Spring 循环依赖问题的面试题。我也断断续续看了很多人再解释循环依赖原理问题。但对于我来说，似乎还是对其有种似懂非懂的感觉。

面试问这个问题的意义在哪？

直到，我从源码世界转了几圈后，再回头看这个问题，我有种豁然开朗的感觉。

是因为这个循环依赖问题背后所需要的知识。

• 你需要对Bean的生命周期(即Spring 创建Bean的过程)有了解
• 你需要对AOP原理有了解

是的，简简单单一个循环依赖问题，其实蕴含的是Spring 最核心的两个点： Bean的生命周期与AOP原理。

这个问题很大程序上就能拷问出你对Spring框架的理解程度，这才是这道题深层的含义吧

基于此种思考，我也来讲讲我对循环依赖的理解。

二、基础知识准备

1. Java 引用传递还是值传递?

JAVA 里是值传递，值传递，值传递!!!

public class Test2 {
    public static void main(String[] args) {
        A a =  new A();
        System.out.println("（1）调用change前"+a);
        change(a);
        System.out.println("（3）调用change后"+a);
    }
    public static void change(A a){
        a= new A();
        System.out.println("（2）change方法内"+a);
    }
}
class A{
}

（1）调用change前com.wsjia.ms.controller.A@61064425
（2）change方法内com.wsjia.ms.controller.A@7b1d7fff
（3）调用change后com.wsjia.ms.controller.A@61064425

我承认JAVA中都是值传递。

但此处想要表达的是：引用类型参数，与原引用值共同指向一块内存地址，对对象的修改是相互影响的。

本文姑且叫他引用的传递【我知道你应该懂得什么意思】

2. Bean创建的几个关键点

此处只是列出Bean的几个重要的阶段，为了讲清楚循环依赖，具体的在以后专门讲讲Bean的创建。

Spring 创建Bean的过程，大致和对象的初始化有点类似吧。有几个关键的步骤

• createBeanInstance ：实例化，此处要强调的是，Bean的早期引用在此出现了。
• populateBean ： 填充属性，此处我们熟悉的@Autowired属性注入就发生在此处
• initializeBean : 调用一些初始化方法，例如init ,afterPropertiesSet

此外：BeanPostProcessor作为一个扩展接口，会穿插在Bean的创建流程中，留下很多钩子，让我们可以去影响Bean的创建过程。其中最主要的就属AOP代理的创建了。

3. AOP的原理

AOP是以一个InstantiationAwareBeanPostProcessor类型的BeanPostProcessor,参与到Bean的创建逻辑中，并根据是否需要代理当前Bean，决定是否创建代理对象。

主要逻辑在(BeanPostProcessor)AbstractAutoProxyCreator类中中,有三个重要方法。

//早期bean创建代理用
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
		Object cacheKey = getCacheKey(bean.getClass(), beanName);
		this.earlyProxyReferences.put(cacheKey, bean);
		return wrapIfNecessary(bean, beanName, cacheKey);
}
//bean创建代理用
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		if (bean != null) {
			Object cacheKey = getCacheKey(bean.getClass(), beanName);
			if (this.earlyProxyReferences.remove(cacheKey) != bean) {
				return wrapIfNecessary(bean, beanName, cacheKey);
			}
		}
		return bean;
}
protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
	//创建代理的逻辑
}

当一个Bean创建代理后，我们通过beanname从BeanFactory中获取的就是就是代理的对象的了

4. getBean()返回的是什么？

当我们尝试按name从BeanFactory.getBean(beanname)一个Bean时，返回的一定是A类对应的实例吗？

答案是否， 当A需要需要创建代理对象时，我们getBean 得到是 代理对象的引用。

5. 三个缓存

本文暂时只考虑单例的情况

把创建好的Bean缓存起来，这是非常平常的逻辑。

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

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

	

• singletonObjects：第一级缓存，里面存放的都是创建好的成品Bean。
• earlySingletonObjects : 第二级缓存，里面存放的都是半成品的Bean。
• singletonFactories ：第三级缓存， 不同于前两个存的是 Bean对象引用，此缓存存的bean 工厂对象，也就存的是 专门创建Bean的一个工厂对象。此缓存用于解决循环依赖

这里有个点：我个人认为这么叫这三个缓存更加合适

• singletonObjects：成品缓存
• earlySingletonObjects： 半成品缓存
• singletonFactories ：单例工厂缓存

至于为什么，稍微给我个人理解。

三、解析循环依赖

接下来开始讲讲循环依赖

本文只讨论，属性注入的情况。

假设有这么两个类产生了循环依赖。如果解决这个问题？

public class A {
    B b;

    public A() {
    }
}

class B{
    @Autowired
    A a;

    public B() {
    }
}

1.一个缓存能解决不？

首先我们先来讨论下这个循环依赖问题

• 从A获取开始，从缓存里查看，没有开始创建A实例，执行构造方法，填充属性时发现需要依赖B，
• 尝试从缓存中获取B。
• 开始创建B实例，执行构造方法，填充属性时，发现需要依赖A，取缓存找A .
• A正在创建没有完成。
• 死结

2.两个缓存能解决不？？

不等创建完成，有了引用后，提前放入半成品缓存

• A引用创建后，提前暴露到半成品缓存中
• 依赖B，创建B ，B填充属性时发现依赖A， 先从成品缓存查找，没有,再从半成品缓存查找 取到A的早期引用。
• B顺利走完创建过程, 将B的早期引用从半成品缓存移动到成品缓存
• B创建完成，A获取到B的引用，继续创建。
• A创建完成，将A的早期引用从半成品缓存移动到成品缓存
• 完美解决循环依赖

嗯？ 两个缓存就能解决？？？为啥需要三个缓存？？

3.为啥需要三个缓存

Spring 为啥用三个缓存去解决循环依赖问题？

上面两个缓存的地方，我们只是没有考虑代理的情况。

代理的存在

Bean在创建的最后阶段，会检查是否需要创建代理，如果创建了代理，那么最终返回的就是代理实例的引用。我们通过beanname获取到最终是代理实例的引用

也就是说：上文中，假设A最终会创建代理，提前暴露A的引用， B填充属性时填充的是A的原始对象引用。A最终放入成品库里是代理的引用。那么B中依然是A的早期引用。这种结果最终会与我们的期望的大相径庭了。

怎么办？？？

Spring 是这么做的

=======AbstractAutowireCapableBeanFactory.doCreateBean

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
			throws BeanCreationException {

		【1】Instantiate the bean.
		BeanWrapper instanceWrapper = null;
		if (mbd.isSingleton()) {
			instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
		}
		if (instanceWrapper == null) {
			instanceWrapper = createBeanInstance(beanName, mbd, args);
		}
		【早期引用】
		final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
		
		【2】在需要暴露早期引用的条件下
		
		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
				isSingletonCurrentlyInCreation(beanName));
		if (earlySingletonExposure) {
		
			【2.1】绑定当前Bean引用到ObjectFactory，注册到三级singletonFactories 
			
			addSingletonFactory(beanName, new ObjectFactory<Object>() {
				【重写getObject】
				@Override
				public Object getObject() throws BeansException {
					return getEarlyBeanReference(beanName, mbd, bean);
				}
			});
		}

}

===AbstractAutowireCapableBeanFactory.doCreateBean--->DefaultSingletonBeanRegistry.getSingleton

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
		
		synchronized (this.singletonObjects) {
			if (!this.singletonObjects.containsKey(beanName)) {
				【3】放入到singletonFactories 缓存中，清除其他缓存
				this.singletonFactories.put(beanName, singletonFactory);
				this.earlySingletonObjects.remove(beanName);
				this.registeredSingletons.add(beanName);
			}
}
	
===========AbstractBeanFactory.doGetBean--->DefaultSingletonBeanRegistry.getSingleton

【4】按Beanname取Bean
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
		【4.1】先尝试从成品缓存获取
		Object singletonObject = this.singletonObjects.get(beanName);
		【4.2】成品缓存没有，且正在创建，尝试从半成品缓存获取
		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
			synchronized (this.singletonObjects) {
				singletonObject = this.earlySingletonObjects.get(beanName);
				
				if (singletonObject == null && allowEarlyReference) {
					
					【4.3】半成品缓存没有，且允许早期引用，尝试从工厂缓存中查找有么此Bean的工厂类存在
					
					ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
					if (singletonFactory != null) {

						【4.4】存在，执行getObject获取早期引用，放入到半成品缓存，并将工厂类从工厂缓存中移除
						singletonObject = singletonFactory.getObject();
						this.earlySingletonObjects.put(beanName, singletonObject);
						this.singletonFactories.remove(beanName);
					}
				}
			}
		}
		return (singletonObject != NULL_OBJECT ? singletonObject : null);
	}

注册 ObjectFactory工厂类到工厂缓存：
singletonFactory.getObject();会调用重写getObject()调用getEarlyBeanReference的后续操作。

• 如果后续操作没有创建代理，返回的依然是原始引用
• 如果需要代理，在此处返回就是代理的引用

早期的扩展处理
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
		Object exposedObject = bean;
		if (bean != null && !mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
			for (BeanPostProcessor bp : getBeanPostProcessors()) {
				if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
					SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
					exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
					if (exposedObject == null) {
						return null;
					}
				}
			}
		}
		return exposedObject;
	}

可以看出此处是执行扩展的操作。

AbstractAutoProxyCreator

【1】针对提前创建代理，返回代理引用
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
		Object cacheKey = getCacheKey(bean.getClass(), beanName);
		this.earlyProxyReferences.put(cacheKey, bean);
		return wrapIfNecessary(bean, beanName, cacheKey);
}
【2】针对不是提前创建代理的情况
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		if (bean != null) {
			Object cacheKey = getCacheKey(bean.getClass(), beanName);
			if (this.earlyProxyReferences.remove(cacheKey) != bean) {
				return wrapIfNecessary(bean, beanName, cacheKey);
			}
		}
		return bean;
}

可以看出singletonFactory 工厂缓存，解决了代理问题的关键

大体流程如图

关键点：

• A绑定到ObjectFactory 注册到工厂缓存singletonFactory中，
• B在填充A时，先查成品缓存有没有，再查半成品缓存有没有，最后看工厂缓存有没有单例工厂类，有A的ObjectFactory。调用getObject ，执行扩展逻辑，可能返回的代理引用，也可能返回原始引用。
• 成功获取到A的早期引用，将A放入到半成品缓存中，B填充A引用完毕。
• 代理问题， 循环依赖问题都解决了。

四、额外思考的自问自答

在这之外，我还有一些思考，并提出自己的观点。

1：为啥不提前调用ObjectFactory.getObject ()直接执行扩展逻辑处理A的早期引用，得到半成品实例引用放入到earlySingletonObjects中，非要先放一个工厂类到工厂缓存中？使用三级缓存呢？

答：假设A只是依赖B 。如果提前执行A扩展操作，在A创建的后期，还会遍历一遍扩展点，岂不是浪费？

2.二级缓存存在意义是啥？

答：其实吧，我觉得 二级缓存earlySingletonObjects 与 三级缓存singletonFactories 。都是为分工明确而生。

• 一级缓存singletonObjects： 就是存的最终的成品
• 二级缓存earlySingletonObjects 就是为存半成品Bean
• 三级缓存singletonFactories： 就是为存bean工厂

因为是早期暴露，从工厂里创建完成后，是半成品，放入半成品缓存，全部流程执行完时是成品放入到成品缓存。分工明确

这也为什么，我认为叫成品缓存，半成品缓存，单例工厂缓存 更加合适的原因

3.是不是走极端，让我设计此块，我非得设计成单个缓存。提前执行后续操作，把他放到singletonObjects。

好像也没有问题，就是非常乱

五、总结

以上就是我对Spring循环依赖的一些理解与思考

循环依赖的关键点：提前暴露绑定A原始引用的工厂类到工厂缓存。等需要时触发后续操作处理A的早期引用，将处理结果放入二级缓存

---

如果本文任何错误，请批评指教，不胜感激 ！
如果觉得文章不错，点个赞吧
如果觉得文章不错，点个赞吧
如果觉得文章不错，点个赞吧

微信公众号：源码行动
享学源码，行动起来，来源码行动