通过循环依赖问题彻底理解SpringIOC的精华

前言

你可能会有如下问题：

1、想看Spring源码，但是不知道应当如何入手去看，对整个Bean的流程没有概念，碰到相关问题也没有头绪如何下手

2、看过几遍源码，没办法彻底理解，没什么感觉，没过一阵子又忘了

本文将结合实际问题，由问题引出源码，并在解释时会尽量以图表的形式让你一步一步彻底理解Spring Bean的IOC、DI、生命周期、作用域等。

先看一个循环依赖问题

现象

循环依赖其实就是循环引用，也就是两个或则两个以上的bean互相持有对方，最终形成闭环。比如A依赖于B，B依赖于C，C又依赖于A。如下图：

如何理解“依赖”呢，在Spring中有：

构造器循环依赖

field属性注入循环依赖

直接上代码：

构造器循环依赖

结果：项目启动失败，发现了一个cycle。

 2.field属性注入循环依赖

结果：项目启动成功

 3.field属性注入循环依赖（prototype）

结果：项目启动失败，发现了一个cycle。

现象总结：同样对于循环依赖的场景，构造器注入和prototype类型的属性注入都会初始化Bean失败。因为@Service默认是单例的，所以单例的属性注入是可以成功的。

分析原因

分析原因也就是在发现SpringIOC的过程，如果对源码不感兴趣可以关注每段源码分析之后的总结和循环依赖问题的分析即可。

SpringBean的加载流程（源码分析）

简单一段代码作为入口

ClassPathXmlApplicationContext是一个加载XML配置文件的类，与之相对的还有AnnotationConfigWebApplicationContext，这两个类大差不差的，只是ClassPathXmlApplicationContext的Resource是XML文件而AnnotationConfigWebApplicationContext是Scan注解获得的。

看到第二行就已经可以直接获取bean的实例了，所以第一行构造方法时，就已经完成了对所有bean的加载。

ClassPathXmlApplicationContext举例，他里面储存的东西如下：

构造方法如下：

接下来大概看看refresh方法：

子方法先不看，先看看refresh方法的结构，其实就有几点值得学习：

1、方法为什么加锁？ 是为了避免多线程的场景下同时刷新Spring上下文

2、虽然整个方法是加锁的，但是却用了Synchronized关键字的对象锁startUpShutdownMonitor，这样做有两个好处：

（1）关闭资源的时候会调用close()方法，close()方法也使用了同样的对象锁，而关闭资源的close和refresh的两个冲突的方法，这样可以避免冲突

（2）此处对象锁相对于整个方法加锁的话，同步的范围更小了，锁的粒度更小，效率更高

3、这个方法refresh定义了整个Spring IOC的流程，每一个方法名字都清晰易懂，可维护性、可读性很强

总结：看源码需要找准入口，看的时候多思考，学习Spring的巧妙的设计。ApplicationContext的构造方法中最关键是方法是refresh，其中有一些比价好的设计。

obtainFreshBeanFactory方法

这个方法作用是获取刷新Spring上下文的Bean工厂：

这断代码的核心是DefaultListableBeanFactory，核心类我们再整理一下，以图表格式：

下面有三个加粗的Map，这些个Map是解决问题的关键。。。我们之后详细分析

BeanDefinition在IOC容器中的注册

接下来简要分析一下loadBeanDefinitions。

对于这个BeanDefinition，我是这么理解的: 它是SpringIOC过程中间的一个产物，可以看成是对Bean定义的抽象，里面封装的数据都是与Bean定义相关的，封装了一些基本的bean的Property、initi-method、destroy-method等。

这里的主要方法是loadBeanDefinitions，这里不详细展开说，它主要做了几件事：

1、初始化了BeanDefinitionReader

2、通过BeanDefinitionReader获取Resource，也就是xml配置文件的位置，并且把文件转换成一个叫Document的对象

3、接下来需要将Document对象转化成容器内部的数据结构（也就是BeanDefinition），也即是将Bean定义的List、Map、Set等各种元素进行解析，转换成Managed类（Spring对BeanDefinition数据的封装)放在BeanDefinition中；这个方法是RegisterBeanDefinition()，也就是解析的过程。

4、解析完成后，会把解析的结果放到BeanDefinition对象中并设置到一个Map中

以上这个过程就是BeanDefinition在IOC容器中的注册。

再回到Refresh方法，总结每一步如下图：

总结：这一部分步骤主要是Spring如何加载Xml文件或者注解，并把它解析成BeanDefinition。

Spring创建Bean的过程

先回到之前的refresh方法(也就是在构造ApplicationContext时的方法)，我们跳过不重要的部分：

我们直接看finishBeanFactoryInitialization里面的preInstantiateSingletons方法，顾名思义初始化所有的单例bean，截取部分如下：

现在来看核心的getBean方法，对于所有获取Bean对象是实例，都是用这个getBean方法，这个方法最终调用的是doGetBean方法，这个方法就是所谓的DI（依赖注入）发生的地方。

程序=数据+算法，之前的BeanDefinition就是“数据”，依赖注入也就是在BeanDefinition准备好情况下进行进行的，这个过程不简单，因为Spring提供了很多参数配置，每一个参数都代表了IOC容器的特性，这些特性的实现需要在Bean的生命周期中完成。

代码比较多，就不贴了，大家可以自行查看AbstractBeanFactory里面的doGetBean方法,这里直接上图，这个图就是依赖注入的整个过程：

总结：Spring创建好了BeanDefinition之后呢，会开始实例化Bean，并且对Bean的依赖属性进行填充。实例化时底层使用了CGLIB或Java反射技术。上图中instantiateBean核PupulateBean方法很重要！

循环依赖问题分析

我们先总结一下之前的结论：

1、构造器注入和prototype类型的field注入发生循环依赖时都无法初始化

2、field注入单例的bean时，尽管有循环依赖，但bean仍然可以被成功初始化

针对这几个结论，提出问题

单例的设值注入bean是如何解决循环依赖问题呢？如果A中注入了B，那么他们初始化的顺序是什么样子的？

为什么prototype类型的和构造器类型的Spring无法解决循环依赖呢？

之前在DefaultListableBeanFactory类中，列出了一个表格；现在我把关键的精华属性列出来：

前面三个Map，我们称为单例初始化的三级缓存，理解这个问题，我们目前只需关注“三级”，也就是singletonFactories

分析：

对于问题1，单例的设值注入，如果A中注入了B，B应该是A中的一个属性，那么猜想应该是A已经被instantiate（实例化）之后，在populateBean（填充A中的属性）时，对B进行初始化。

对于问题2，instantiate（实例化）其实就是理解成new一个对象的过程，而new的时候肯定要执行构造方法，所以猜想对于应该是A在instantiate（实例化）时，进行B的初始化。

有了分析和猜想之后呢，围绕关键的属性，根据从上图的doGetBean方法开始到populateBean所有的代码，我整理了如下图：

作者：Java填坑之路
链接：https://www.jianshu.com/p/89d669dc8aad