[TOC] ### 一、面试为啥好问循环依赖问题 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 */ //一级缓存：singletonObjects，存放完全实例化属性赋值完成的Bean，直接可以使用 private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256); /** * Cache of early singleton objects: bean name --> bean instance */ //二级缓存：earlySingletonObjects，存放早期Bean的引用，尚未属性装配的Bean private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16); /** * Cache of singleton factories: bean name --> ObjectFactory */ //三级缓存：singletonFactories，三级缓存，存放实例化完成的Bean工厂。 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取Beanprotected 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的早期引用，将处理结果放入二级缓存** 作者：享学源码 链接：https://juejin.cn/post/6844904166351978504 来源：掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。