1.单例Bean循环依赖-setter产生的循环依赖

1.1 原理

为单例搞的三个 map：

• 一级缓存，singletonObjects，存储所有已创建完毕的单例 Bean （完整的 Bean）
• 二级缓存，earlySingletonObjects，存储所有仅完成实例化，但还未进行属性注入和初始化的 Bean
• 三级缓存，singletonFactories，存储能建立这个 Bean 的一个工厂，通过工厂能获取这个 Bean，延迟化 Bean 的生成，工厂生成的 Bean 会塞入二级缓存

getBean()步骤：

• getSingleton(beanName) 依次从三个缓存中获取
• 实例化
• addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
• 属性注入
• 初始化

一个大致过程： getBean(A)，AB循环依赖

• A执行属性注入，这个时候 A 发现需要注入 B，所以去 getBean(B)，此时又会走一遍上面描述的逻辑。
• 到了 B 的属性注入这一步，此时 B 调用 getBean(A)，这时候一级缓存里面找不到，但是发现 A 正在创建中的，于是去二级缓存找，发现没找到，于是去三级缓存找，然后找到了。
  并且通过上面提前在三级缓存里暴露的工厂得到 A，然后将这个工厂从三级缓存里删除，并将 A 加入到二级缓存中。
  然后结果就是 B 属性注入成功。
  紧接着 B 调用 initializeBean 初始化，最终返回，此时 B 已经被加到了一级缓存里 。
• 这时候就回到了 A 的属性注入，此时注入了 B，接着执行初始化，最后 A 也会被加到一级缓存里，且从二级缓存中删除 A。

1.2 getSingleton()

getSingleton()并发安全问题？以及5.3后变了，为啥变了？

    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        // Quick check for existing instance without full singleton lock
        // 到一级缓存获取
        Object singletonObject = this.singletonObjects.get(beanName);
        // 条件一：一级缓存不存在
        //   1）单实例未创建
        //   2）单实例循环依赖（三级缓存解决setter循环依赖）

        //1.假设Spring先实例化A，首先拿到A的构造方法，进行反射创建出来A的早期实例对象，这个时候，这个早期对象被包装成了ObjectFactory对象，放到了3级缓存。
        //2.处理A的依赖数据，检查发现，A它依赖了B对象，所以接下来，Spring就会去根据B类型到容器中去getBean(B.class)，这里就递归了。
        //3.拿到B的构造方法，进行反射创建出来B的早期实例对象，它也会把B包装成ObjectFactory对象，放到3级缓存。
        //4.处理B的依赖数据，检查发现，B它依赖了A对象，所以接下来，Spring就会去根据A类型到容器中去getBean(A.class)，去拿A对象，这个又递归了。
        //5.程序还会走到当前这个方法。getSingleton这个方法。
        //6.条件一成立，条件二也会成立。
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            // 检查二级缓存
            singletonObject = this.earlySingletonObjects.get(beanName);
            // 二级缓存没有
            if (singletonObject == null && allowEarlyReference) {
                synchronized (this.singletonObjects) {
                    // Consistent creation of early reference within full singleton lock
                    singletonObject = this.singletonObjects.get(beanName);
                    if (singletonObject == null) {
                        singletonObject = this.earlySingletonObjects.get(beanName);
                        if (singletonObject == null) {
                            //Spring为什么需要有3级缓存存在，而不是只有2级缓存呢？
                            //AOP，靠什么实现的呢？动态代理
                            //静态代理：需要手动写代码，实现一个新的java文件，这个java类 和 需要代理的对象 实现同一个接口，内部维护一个被代理对象（原生）
                            //代理类，在调用原生对象前后，可以加一些逻辑. 代理对象 和 被代理对象 是两个不同的对象，内存地址一定是不一样的。
                            //动态代理：不需要人为写代码了，而是依靠字节码框架动态生成class字节码文件，然后jvm再加载，然后也一样 也是去new代理对象，这个
                            //代理对象 没啥特殊的，也是内部保留了 原生对象，然后在调用原生对象前后 实现的 字节码增强。
                            //3级缓存在这里有什么目的呢？
                            //3级缓存里面保存的是对象工厂，这个对象工厂内部保留着最原生的对象引用，ObjectFactory的实现类，getObject()方法，它需要考虑一个问题。
                            //它到底要返回原生的，还是增强后的。
                            //getObject会判断当前这个早期实例 是否需要被增强，如果是，那么提前完成动态代理增强，返回代理对象。否则，返回原生对象。
                            ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                            if (singletonFactory != null) {
                                // 将三级缓存数据提升到二级
                                singletonObject = singletonFactory.getObject();
                                this.earlySingletonObjects.put(beanName, singletonObject);
                                this.singletonFactories.remove(beanName);
                            }
                        }
                    }
                }
            }
        }
        return singletonObject;
    }

1.3 为啥需要三级缓存？

三级缓存是否为延迟代理的创建，尽量不打破 Bean 的生命周期

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
            exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
        }
    }
    return exposedObject;
}

如果有代理的话，那么我们想要直接拿到的是代理对象。
也就是说如果 A 需要被代理，那么 B 依赖的 A 是已经被代理的 A，所以我们不能返回 A 给 B，而是返回代理的 A 给 B。
这个工厂的作用就是判断这个对象是否需要代理，如果否则直接返回，如果是则返回代理对象。

正常代理对象的生成是基于后置处理器，是 在被代理的对象初始化后期调用生成的 ， 所以如果你提早代理了其实是违背了 Bean 定义的生命周期 。
所以 Spring 先在一个三级缓存放置一个工厂，如果产生循环依赖，那么就调用这个工厂提早得到代理对象。
如果没产生依赖，这个工厂根本不会被调用，所以 Bean 的生命周期就是对的。

其实破坏循环依赖，其实只有二级缓存就够了，但是碍于生命周期的问题，提前暴露工厂延迟代理对象的生成。

2.单例Bean循环依赖-构造参数产生的循环依赖

2.1 构造参数为啥不能解决循环依赖

如果全是构造器注入，比如 A(B b) ，那表明在 new 的时候，就需要得到 B，此时需要 new B 。
但是 B 也是要在构造的时候注入 A ，即 B(A a) ，这时候 B 需要在一个 map 中找到不完整的 A ，发现找不到。
为什么找不到？因为 A 还没 new 完呢，所以找到不完整的 A， 因此如果全是构造器注入的话，那么 Spring 无法处理循环依赖 。

总结：

• 如果循环依赖都是构造器注入，则失败
• 如果循环依赖不完全是构造器注入，则可能成功，可能失败，具体跟BeanName的字母序有关系。

2.2 源码中的处理

getBean()步骤：

• getSingleton(beanName) 依次从三个缓存中获取
• getSingleton(beanName, ObjectFactory)
• beforeSingletonCreation(beanName) 处理构造器循环依赖
• 实例化，这里会getBean()构造器参数
• addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
• 属性注入
• 初始化

    public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
        Assert.notNull(beanName, "Bean name must not be null");
        synchronized (this.singletonObjects) {
            Object singletonObject = this.singletonObjects.get(beanName);
            if (singletonObject == null) {
                //容器销毁时，会设置这个属性为true，这个时候就不能再创建bean实例了，直接抛错。
                if (this.singletonsCurrentlyInDestruction) {
                    throw new BeanCreationNotAllowedException(beanName,
                            "Singleton bean creation not allowed while singletons of this factory are in destruction " +
                            "(Do not request a bean from a BeanFactory in a destroy method implementation!)");
                }
                if (logger.isDebugEnabled()) {
                    logger.debug("Creating shared instance of singleton bean '" + beanName + "'");
                }
                //将当前beanName放入到“正在创建中单实例集合”，放入成功，说明没有产生循环依赖，失败，则产生循环依赖，里面会抛异常。
                //举个例子：构造方法参数依赖
                //A->B    B->A
                //1.加载A，根据A的构造方法，想要去实例化A对象，但是发现A的构造方法有一个参数是B（在这之前，已经向这个集合中添加了 {A}）
                //2.因为A的构造方法依赖B，所以触发了加载B的逻辑..
                //3.加载B，根据B的构造方法，想要去实例化B对象，但是发现B的构造方法有一个参数是A（在这之前，已经向这个集合中添加了 {A，B}）
                //4.因为B的构造方法依赖A，所以再次触发了加载A的逻辑..
                //5.再次来到这个getSingleton方法里，调用beforeSingletonCreation(A),因为创建中集合 已经有A了，所以添加失败，抛出异常
                //完事。
                beforeSingletonCreation(beanName);

    protected void beforeSingletonCreation(String beanName) {
        if (!this.inCreationCheckExclusions.contains(beanName) && !this.singletonsCurrentlyInCreation.add(beanName)) {
            throw new BeanCurrentlyInCreationException(beanName);
        }
    }

3.原型模式的循环依赖

3.1 原型模式为啥不能解决循环依赖

如果两个 Bean 都是原型模式的话。

那么创建 A1 需要创建一个 B1。
创建 B1 的时候要创建一个 A2。
创建 A2 又要创建一个 B2。
创建 B2 又要创建一个 A3。
创建 A3 又要创建一个 B3.....
因为原型模式都需要创建新的对象，不能用以前的对象。

3.2 源码中的处理

getBean()步骤：

• getSingleton(beanName) 依次从三个缓存中获取
• 原型循环依赖问题判定
• beforePrototypeCreation(beanName); 加入到prototypesCurrentlyInCreation
• 实例化
• 属性注入
• 初始化
• afterPrototypeCreation(beanName);

            //1、原型循环依赖问题判定
            //举个例子：
            //prototypeA -> B， B -> prototypeA
            //1.会向正在创建中的原型集合内添加一个字符串 “A”   下面beforePrototypeCreation(beanName);
            //2.创建prototypeA对象，只是一个早期对象。
            //3.处理prototypeA的依赖，发现A依赖了B类型的对象
            //4.触发了Spring.getBean(“B”)的操作。
            //5.根据B的构造方法反射创建出来了B的早期实例
            //6.Spring处理B对象的依赖，发现依赖了A。
            //7.Spring转头回来再次去获取A去了。getBean(“A”).
            //8.条件会返回true，最终抛出异常，算是结束了循环依赖注入。
            if (isPrototypeCurrentlyInCreation(beanName)) {
                throw new BeanCurrentlyInCreationException(beanName);
            }