spring之循环依赖怎么解决的

今天药忘吃喽~ 2022-10-08 13:29 216阅读 0赞

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

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.一个缓存能解决不？ ###

首先我们先来讨论下这个循环依赖问题  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3NDY5MDU1_size_16_color_FFFFFF_t_70]

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

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

不等创建完成，有了引用后，提前放入半成品缓存  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3NDY5MDU1_size_16_color_FFFFFF_t_70 1]

*  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);
        }

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

早期的扩展处理
    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 工厂缓存，解决了代理问题的关键**

大体流程如图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3NDY5MDU1_size_16_color_FFFFFF_t_70 2]

#### 关键点： ####

*  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的早期引用，将处理结果放入二级缓存。

[参考地址][Link 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3NDY5MDU1_size_16_color_FFFFFF_t_70]: /images/20221005/bd013f7ff939489ca538ff1f644d905a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3NDY5MDU1_size_16_color_FFFFFF_t_70 1]: /images/20221005/83269e5248c04b8291ddc73285a3924b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3NDY5MDU1_size_16_color_FFFFFF_t_70 2]: /images/20221005/1dfce74fbb6a40d9aefd956be6397c5a.png
[Link 1]: https://blog.csdn.net/weixin_47067712/article/details/118048089