关于java:展开说说Spring-Bean-IOCAOP-循环依赖

作者：小傅哥
博客：https://bugstack.cn

积淀、分享、成长，让本人和别人都能有所播种！😄

提早满足能给你带来什么？

大学有四年工夫，但简直所有人都是邻近毕业才发现找一份好工作吃力，尤其是我能十分相熟的软件开发行业，即便是毕业了还须要额定花钱到培训机构，在学一遍编程技术能力进来找工作。如同在校这几年压根就没学到什么！

就我集体而言可能是因为上学期间喜爱编程，也从师哥、师姐那里听到一些对于毕业后找工作的不容易，也理解了一些社会上对程序员开发技能的要求级别。也就是失去了这些音讯，又加上本人乐于折腾，我给本人定了一个每天都能实现的小指标：

红尘世界几个王，我自不服迎头上。日敲代码两百行，冲进世界五百强。

哈哈哈 ，就这么每天两百行代码，一个月就是 6 千行，一年就是 6 万行，三年后开始实习就有 18 万行，一个应届实习生有将近 20 万行代码的敲击量，简直曾经能够十分纯熟的实现各类简略的工作，在加上实习中对整个我的项目流程真正的断链后，找一个 正经 的开发工作，还是很容易的。

而这时候找工作的容易，就来自于你始终以来的学习和积淀，但如果你没通过这些致力，可能等毕业后就会变得十分慌乱，最初没方法只能去一些机构再学习一遍。

谢飞机，小记！，以前感觉 Spring 没啥，看过一篇 getBean，我的天！

谢飞机：面试官，最近我看了 Spring 的 getBean 发现这里好多货色，还有一个是要解决循环依赖的，这玩意面试有啥要问的吗？

面试官：有哇，Spring 是如何解决循环依赖的？

谢飞机：嗯，通过三级缓存提前裸露对象解决的。

面试官：能够哈，那这三个缓存里都寄存了什么样的对象信息呢？

谢飞机：一级缓存寄存的是残缺对象，也叫成品对象。二级缓存寄存的是半成品对象，就是那些属性还没赋值的对象。三级缓存寄存的是 ObjectFactory<?> 类型的 lambda 表达式，就是这用于解决 AOP 循环依赖的。

面试官：能够呀，谢飞机有所准备嘛！那如果没有三级缓存，只有二级或者一级，能解决循环依赖吗？

谢飞机：其实我看过材料了，能够解决，只不过 Spring 要保障几个事件，只有一级缓存解决流程没法拆分，复杂度也会减少，同时半成品对象可能会有空指针异样。而将半成品与成品对象离开，解决起来也更加优雅、简略、易扩大。另外 Spring 的两大个性中不仅有 IOC 还有 AOP，也就是基于字节码加强后的办法，该寄存到哪，而三级缓存最次要，要解决的循环依赖就是对 AOP 的解决，但如果把 AOP 代理对象的创立提前，那么二级缓存也一样能够解决。然而，这就违反了 Spring 创建对象的准则，Spring 更喜爱把所有的一般 Bean 都初始化实现，在解决代理对象的初始化。

面试官：飞机，不错嘛，这次理解了不少。那问个简略的，你撸过循环依赖的解决方案？

谢飞机：哦哦，这没有，没实际过！！！的确应该搞一下，试试。

理解问题的实质再剖析问题，往往更利于对问题有更深刻的理解和钻研。所以咱们在剖析 Spring 对于循环依赖的源码之前，先要理解下什么是循环依赖。

循环依赖分为三种，本身依赖于本身、相互循环依赖、多组循环依赖。
但无论循环依赖的数量有多少，循环依赖的实质是一样的。就是你的残缺创立依赖于我，而我的残缺创立也依赖于你，但咱们相互没法解耦，最终导致依赖创立失败。
所以 Spring 提供了除了构造函数注入和原型注入外的，setter 循环依赖注入解决方案。那么咱们也能够先来尝试下这样的依赖，如果是咱们本人解决的话该怎么解决。

public class ABTest {public static void main(String[] args) {new ClazzA();
    }

}

class ClazzA {private ClazzB b = new ClazzB();

}

class ClazzB {private ClazzA a = new ClazzA();

}

这段代码就是循环依赖最后的模样，你中有我，我中有你，运行就报错 java.lang.StackOverflowError
这样的循环依赖代码是没法解决的，当你看到 Spring 中提供了 get/set 或者注解，这样之所以能解决，首先是进行了肯定的解耦。让类的创立和属性的填充拆散，先创立出半成品 Bean，再解决属性的填充，实现成品 Bean 的提供。

在这部分的代码中就一个外围目标，咱们来本人解决一下循环依赖，计划如下：

public class CircleTest {private final static Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

    public static void main(String[] args) throws Exception {System.out.println(getBean(B.class).getA());
        System.out.println(getBean(A.class).getB());
    }

    private static <T> T getBean(Class<T> beanClass) throws Exception {String beanName = beanClass.getSimpleName().toLowerCase();
        if (singletonObjects.containsKey(beanName)) {return (T) singletonObjects.get(beanName);
        }
        // 实例化对象入缓存
        Object obj = beanClass.newInstance();
        singletonObjects.put(beanName, obj);
        // 属性填充补全对象
        Field[] fields = obj.getClass().getDeclaredFields();
        for (Field field : fields) {field.setAccessible(true);
            Class<?> fieldClass = field.getType();
            String fieldBeanName = fieldClass.getSimpleName().toLowerCase();
            field.set(obj, singletonObjects.containsKey(fieldBeanName) ? singletonObjects.get(fieldBeanName) : getBean(fieldClass));
            field.setAccessible(false);
        }
        return (T) obj;
    }

}

class A {

    private B b;

    // ...get/set
}

class B {
    private A a;

        // ...get/set
}

这段代码提供了 A、B 两个类，相互有依赖。但在两个类中的依赖关系应用的是 setter 的形式进行填充。也就是只有这样能力防止两个类在创立之初不非得强依赖于另外一个对象。
getBean，是整个解决循环依赖的核心内容，A 创立后填充属性时依赖 B，那么就去创立 B，在创立 B 开始填充时发现依赖于 A，但此时 A 这个半成品对象曾经寄存在缓存到singletonObjects 中了，所以 B 能够失常创立，在通过递归把 A 也创立残缺了。

通过下面的例子咱们大略理解到，A 和 B 相互依赖时，A 创立完后填充属性 B，持续创立 B，再填充属性 A 时就能够从缓存中获取了，如下：

那这个解决事循环依赖的事放到 Spring 中是什么样呢？开展细节！

尽管，解决循环依赖的外围原理一样，但要放到撑持起整个 Spring 中 IOC、AOP 个性时，就会变得复杂一些，整个解决 Spring 循环依赖的过程如下；

以上就是对于 Spring 中对于一个有循环依赖的对象获取过程，也就是你想要的 说说细节
乍一看是挺多流程，然而这些也根本是你在调试代码时候必须通过的代码片段，拿到这份执行流程，再调试就十分不便了。

对于本章节波及到的案例源码剖析，已更新到 github：https://github.com/fuzhengwei/interview – interview-31

以下是单元测试中对 AB 依赖的获取 Bean 操作，重点在于进入 getBean 的源码跟进；

@Test
public void test_alias() {BeanFactory beanFactory = new ClassPathXmlApplicationContext("spring-config.xml");
    Bean_A bean_a = beanFactory.getBean("bean_a", Bean_A.class);
    logger.info("获取 Bean 通过别名：{}", bean_a.getBean_b());
}

org.springframework.beans.factory.support.AbstractBeanFactory.java

@Override
public <T> T getBean(String name, Class<T> requiredType) throws BeansException {return doGetBean(name, requiredType, null, false);
}

从 getBean 进入后，获取 bean 的操作会进入到 doGetBean。
之所以这样包装一层，是因为 doGetBean 有很多不同入参的重载办法，不便内部操作。

doGetBean 办法

protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
        throws BeansException {
    
  // 从缓存中获取 bean 实例
    Object sharedInstance = getSingleton(beanName);
    
            // mbd.isSingleton() 用于判断 bean 是否是单例模式
            if (mbd.isSingleton()) {
              // 获取 bean 实例
                sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
                    @Override
                    public Object getObject() throws BeansException {
                        try {
                          // 创立 bean 实例，createBean 返回的 bean 实例化好的
                            return createBean(beanName, mbd, args);
                        }
                        catch (BeansException ex) {destroySingleton(beanName);
                            throw ex;
                        }
                    }
                });
                // 后续的解决操作
                bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
            }
            
    // ...

  // 返回 bean 实例
    return (T) bean;
}

依照在源码剖析的流程图中能够看到，这一部分是从 getSingleton 先判断是否有实例对象，对于第一次进入是必定没有对象的，要持续往下走。
在判断 mbd.isSingleton() 单例当前，开始应用基于 ObjectFactory 包装的形式创立 createBean，进入后外围逻辑是开始执行 doCreateBean 操作。

doCreateBean 办法

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
        throws BeanCreationException {
    
      // 创立 bean 实例，并将 bean 实例包装到 BeanWrapper 对象中返回
        instanceWrapper = createBeanInstance(beanName, mbd, args);
    
        // 增加 bean 工厂对象到 singletonFactories 缓存中
        addSingletonFactory(beanName, new ObjectFactory<Object>() {
            @Override
            public Object getObject() throws BeansException {
              // 获取原始对象的晚期援用，在 getEarlyBeanReference 办法中，会执行 AOP 相干逻辑。若 bean 未被 AOP 拦挡，getEarlyBeanReference 原样返回 bean。return getEarlyBeanReference(beanName, mbd, bean);
            }
        });
        
    try {
      // 填充属性，解析依赖关系
        populateBean(beanName, mbd, instanceWrapper);
        if (exposedObject != null) {exposedObject = initializeBean(beanName, exposedObject, mbd);
        }
    }
    
    // 返回 bean 实例
    return exposedObject;
}

在 doCreateBean 办法中包含的内容较多，但外围次要是创立实例、退出缓存以及最终进行属性填充，属性填充就是把一个 bean 的各个属性字段波及到的类填充进去。
createBeanInstance，创立 bean 实例，并将 bean 实例包装到 BeanWrapper 对象中返回
addSingletonFactory，增加 bean 工厂对象到 singletonFactories 缓存中
getEarlyBeanReference，获取原始对象的晚期援用，在 getEarlyBeanReference 办法中，会执行 AOP 相干逻辑。若 bean 未被 AOP 拦挡，getEarlyBeanReference 原样返回 bean。
populateBean，填充属性，解析依赖关系。也就是从这开始去找寻 A 实例中属性 B，紧接着去创立 B 实例，最初在返回回来。

getSingleton 三级缓存

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
  // 从 singletonObjects 获取实例，singletonObjects 是成品 bean
    Object singletonObject = this.singletonObjects.get(beanName);
    // 判断 beanName，isSingletonCurrentlyInCreation 对应的 bean 是否正在创立中
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {synchronized (this.singletonObjects) {
          // 从 earlySingletonObjects 中获取提前曝光未成品的 bean
            singletonObject = this.earlySingletonObjects.get(beanName);
            if (singletonObject == null && allowEarlyReference) {
              // 获取相应的 bean 工厂
                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
                  // 提前曝光 bean 实例，次要用于解决 AOP 循环依赖
                    singletonObject = singletonFactory.getObject();
                    
                    // 将 singletonObject 放入缓存中，并将 singletonFactory 从缓存中移除
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return (singletonObject != NULL_OBJECT ? singletonObject : null);
}

singletonObjects.get(beanName)，从 singletonObjects 获取实例，singletonObjects 是成品 bean
isSingletonCurrentlyInCreation，判断 beanName，isSingletonCurrentlyInCreation 对应的 bean 是否正在创立中
allowEarlyReference，从 earlySingletonObjects 中获取提前曝光未成品的 bean
singletonFactory.getObject()，提前曝光 bean 实例，次要用于解决 AOP 循环依赖

综上，是一个解决循环依赖的代码流程，这部分提取进去的内容次要为核心内容，并没与简明扼要的全副拆取出来，大家在调试的时候会波及的比拟多，尽可能要本人依据流程图操作调试几遍。

综上从咱们本人去尝试解决循环依赖，学习了循环依赖的外围解决原理。又剖析了 Spring 解决的循环依赖的处理过程以及外围源码的剖析。那么接下来咱们在总结下三级缓存别离不同的处理过程，算是一个总结，也不便大家了解。

其实只有一级缓存并不是不能解决循环依赖，就像咱们本人做的例子一样。
然而在 Spring 中如果像咱们例子里那么解决，就会变得十分麻烦，而且也可能会呈现 NPE 问题。
所以如图依照 Spring 中代码解决的流程，咱们去剖析一级缓存这样寄存成品 Bean 的流程中，是不能解决循环依赖的问题的。因为 A 的成品创立依赖于 B，B 的成品创立又依赖于 A，当须要补全 B 的属性时 A 还是没有创立完，所以会呈现死循环。

有了二级缓存其实这个事解决起来就容易了，一个缓存用于寄存成品对象，另外一个缓存用于寄存半成品对象。
A 在创立半成品对象后寄存到缓存中，接下来补充 A 对象中依赖 B 的属性。
B 持续创立，创立的半成品同样放到缓存中，在补充对象的 A 属性时，能够从半成品缓存中获取，当初 B 就是一个残缺对象了，而接下来像是递归操作一样 A 也是一个残缺对象了。

有了二级缓存都能解决 Spring 依赖了，怎么要有三级缓存呢。其实咱们在后面剖析源码时也提到过，三级缓存次要是解决 Spring AOP 的个性。AOP 自身就是对办法的加强，是 ObjectFactory<?> 类型的 lambda 表达式，而 Spring 的准则又不心愿将此类类型的 Bean 前置创立，所以要寄存到三级缓存中解决。
其实整体处理过程相似，唯独是 B 在填充属性 A 时，先查问成品缓存、再查半成品缓存，最初在看看有没有单例工程类在三级缓存中。最终获取到当前调用 getObject 办法返回代理援用或者原始援用。
至此也就解决了 Spring AOP 所带来的三级缓存问题。本章节波及到的 AOP 依赖有源码例子，能够进行调试

回顾本文根本以实际操作的例子开始，疏导大家对循环依赖有一个整体的意识，也对它的解决方案能够上手的例子，这样对后续的对于 Spring 对循环依赖的解决也就不会那么生疏了。
通篇全文下来大家也能够看到，三级缓存并不是非必须不可，只不过在满足 Spring 本身创立的准则下，是必须的。如果你能够下载 Spring 源码对这部分代码进行改变下，提前创立 AOP 对象保留到缓存中，那么二级缓存一样能够解决循环依赖问题。
对于循环依赖可能并不是一个好的编码方式，如果在本人的程序中还是要尽可能应用更正当的设计模式躲避循环依赖，可能这些形式会减少代码量，但在保护上会更加不便。当然这不是强制，能够依据你的须要而来。

你说，怎么把 Bean 塞到 Spring 容器？
Spring IOC 个性有哪些，不会读不懂源码！
对于 Spring 中 getBean 的全流程源码解析
久等了，小傅哥的《重学 Java 设计模式》终于出版了，彩印 & 纸质！
一个 Bug，让我发现了 Java 界的.AJ(锥)！.html)

关于java:展开说说Spring-Bean-IOCAOP-循环依赖

一、前言

二、面试题

三、什么是循环依赖？

1. 问题形容

2. 问题体现

3. 问题解决

四、源码剖析

1. 说说细节

2. 处理过程

3. 依赖解析

1. 一级缓存能解决吗？

2. 二级缓存能解决吗？

3. 三级缓存解决什么？

五、总结

六、系列举荐