什么是循环依赖？

从字面上来理解就是 A 依赖 B 的同时 B 也依赖了 A，就像上面这样，或者 C 依赖与自己本身。体现到代码层次就是这个样子

@Componentpublic class A { // A中注入了B @Autowired private B b;}---@Componentpublic class B { // B中注入了A @Autowired private A a;}---// 自己依赖自己@Componentpublic class C { // C中注入了C @Autowired private C c;}

虽然体现形式不一样，但是实际上都是循环依赖的问题。

什么情况下循环依赖可以被处理？

Spring 解决循环依赖是有前置条件的

• 出现循环依赖的 Bean 必须要是单例(singleton)，如果依赖 prototype 则完全不会有此需求。

• 依赖注入的方式不能全是构造器注入的方式（只能解决 setter 方法的循环依赖，这是错误的）

1. AB 均采用 setter 方法注入 结果 OK

2. AB 均采用属性 Autowired 注入 结果 ok

3. AB 均采用构造器方法注入 出现循环依赖

4. A 中注入 B 的方式为 setter 方法，B 中注入 A 的方式为构造器

5. A 中注入 B 的方式为构造器，B 中注入 A 的方式为 setter 方法。

结论

依赖情况依赖注入方式是否解决 AB 相互依赖（循环依赖）均采用 setter 方法注入是 AB 相互依赖（循环依赖）均采用属性自动注入是 AB 相互依赖（循环依赖）均采用构造器注入否 AB 相互依赖（循环依赖）A 中注入 B 的方式为 setter 方法，B 中注入 A 的方式为构造器是 AB 相互依赖（循环依赖）B 中注入 A 的方式为 setter 方法，A 中注入 B 的方式为构造器,Spring 在创建 Bean 时默认会根据自然排序进行创建，A 会先于 B 进行创建否

从上面的测试结果我们可以看到，不是只有在 setter 方法注入的情况下循环依赖才能被解决，即使存在构造器注入的场景下，循环依赖依然被可以被正常处理掉。

Spring 循环依赖的通俗说

Spring bean 的创建，其本质上还是一个对象的创建，既然是对象，一定要明白一点就是，一个完整的对象包含两部分：当前对象实例化和对象属性的实例化。在 Spring 中，对象的实例化是通过反射实现的，而对象的属性则是在对象实例化之后通过一定的方式设置的。这个过程可以按照如下方式进行理解：

大致绘制依赖流程图如下：

图中 getBean()表示调用 Spring 的 ApplicationContext.getBean()方法，而该方法中的参数，则表示我们要尝试获取的目标对象。图中的黑色箭头表示一开始的方法调用走向，走到最后，返回了 Spring 中缓存的 A 对象之后，表示递归调用返回了，此时使用绿色箭头表示。从图中我们可以很清楚的看到，B 对象的 a 属性是在第三步中注入的半成品 A 对象，而 A 对象的 b 属性是在第二步中注入的成品 B 对象，此时半成品的 A 对象也就变成了成品的 A 对象，因为其属性已经设置完成了。

到这里，Spring 整个解决循环依赖问题的实现思路已经比较清楚了。对于整体过程只要理解两点：

• Spring 是通过递归的方式获取目标 bean 及其所依赖的 bean 的；

• Spring 实例化一个 bean 的时候，是分两步进行的，首先实例化目标 bean，然后为其注入属性。

结合这两点，也就是说，Spring 在实例化一个 bean 的时候，是首先递归的实例化其所依赖的所有 bean，直到某个 bean 没有依赖其他 bean，此时就会将该实例返回，然后反递归的将获取到的 bean 设置为各个上层 bean 的属性的。

Spring 循环依赖进阶

一个对象一般创建过程有 3 部分组成：

1. 实例化：简单理解就是 new 了一个对象

2. 属性注入：为实例化中 new 出来的对象填充属性

3. 初始化：执行 aware 接口中的方法，初始化方法，完成 AOP 代理

Spring 是通过「三级缓存」来解决上述问题的：

• singletonObjects：一级缓存 存储的是所有创建好了的单例 Bean

• earlySingletonObjects：完成实例化，但是还未进行属性注入及初始化的对象

• singletonFactories：提前暴露的一个单例工厂，二级缓存中存储的就是从这个工厂中获取到的对象

然后接下来说下普通循环依赖跟带 AOP 的循环依赖。

普通循环依赖图

结论：没有进行 AOP 的 Bean 间的循环依赖 从上图分析可以看出，这种情况下「三级缓存根本没用」！所以不会存在什么提高了效率的说法

带 AOP 循环依赖

带 AOP 的跟不带 AOP 的其实几乎一样，只是在三级缓存中存放的是函数式接口，在需要调用时直接返回代理对象。三级缓存存在的意义：

❝

只有真正发生循环依赖的时候，才去提前生成代理对象，否则只会创建一个工厂并将其放入到三级缓存中，但是不会去通过这个工厂去真正创建对象

❞

是否可以用二级缓存而不用三级缓存？

❝

答案：不可以，违背 Spring 在结合 AOP 跟 Bean 的生命周期的设计！Spring 结合 AOP 跟 Bean 的生命周期(看下图)本身就是通过 AnnotationAwareAspectJAutoProxyCreator 这个后置处理器来完成的，在这个后置处理的 postProcessAfterInitialization 方法中对初始化后的 Bean 完成 AOP 代理。如果出现了循环依赖，那没有办法，只有给 Bean 先创建代理，但是没有出现循环依赖的情况下，设计之初就是让 Bean 在生命周期的「最后一步完成代理而不是在实例化后就立马完成代理」。

❞

使用了三级缓存的情况下，A、B 的创建流程

不使用三级缓存，直接在二级缓存中

结论：上面两个流程的唯一区别在于为 A 对象创建代理的时机不同，使用三级缓存的情况下为 A 创建代理的时机是在 B 中需要注入 A 的时候，而不使用三级缓存的话在 A 实例化后就需要马上为 A 创建代理然后放入到二级缓存中去。三级缓存是无法提速的！

回答模板

Spring 如何解决循环依赖的

答：Spring 通过三级缓存解决了循环依赖，其中一级缓存为单例池（singletonObjects），二级缓存为早期曝光对象 earlySingletonObjects，三级缓存为早期曝光对象工厂（singletonFactories）。

当 A、B 两个类发生循环引用时，在 A 完成实例化后，就使用实例化后的对象去创建一个对象工厂，添加到三级缓存中，如果 A 被 AOP 代理，那么通过这个工厂获取到的就是 A 代理后的对象，如果 A 没有被 AOP 代理，那么这个工厂获取到的就是 A 实例化的对象。

当 A 进行属性注入时，会去创建 B，同时 B 又依赖了 A，所以创建 B 的同时又会去调用 getBean(a)来获取需要的依赖，此时的 getBean(a)会从缓存中获取：

❝

第一步：先获取到三级缓存中的工厂；

第二步：调用对象工工厂的 getObject 方法来获取到对应的对象，得到这个对象后将其注入到 B 中。紧接着 B 会走完它的生命周期流程，包括初始化、后置处理器等。

第三步：当 B 创建完后，会将 B 再注入到 A 中，此时 A 再完成它的整个生命周期。至此，循环依赖结束！

❞

面试官：为什么要使用三级缓存呢？二级缓存能解决循环依赖吗？

❝

答：如果要使用二级缓存解决循环依赖，意味着所有 Bean 在实例化后就要完成 AOP 代理，这样违背了 Spring 设计的原则，Spring 在设计之初就是通过 AnnotationAwareAspectJAutoProxyCreator 这个后置处理器来在 Bean 生命周期的最后一步来完成 AOP 代理，而不是在实例化后就立马进行 AOP 代理。

❞

跟踪核心大致流程