烂大街的Spring循环依赖该如何回答？
往期热门文章：
4、一个基于SpringBoot + MyBatis + Vue的代码生成器
5、Redis 分布式锁使用不当，超卖了100瓶飞天茅台！！！
什么是循环依赖？
A依赖B的同时B也依赖了A，就像上面这样，或者C依赖与自己本身。体现到代码层次就是这个样子@Component
public class A {
// A中注入了B
@Autowired
private B b;
}
---
@Component
public class B {
// B中注入了A
@Autowired
private A a;
}
---
// 自己依赖自己
@Component
public class C {
// C中注入了C
@Autowired
private C c;
}
什么情况下循环依赖可以被处理？
前置条件的出现循环依赖的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方法。
结论
不是只有在setter方法注入的情况下循环依赖才能被解决，即使存在构造器注入的场景下，循环依赖依然被可以被正常处理掉。Spring循环依赖的通俗说
当前对象实例化和对象属性的实例化。在Spring中，对象的实例化是通过反射实现的，而对象的属性则是在对象实例化之后通过一定的方式设置的。这个过程可以按照如下方式进行理解：
ApplicationContext.getBean()方法，而该方法中的参数，则表示我们要尝试获取的目标对象。图中的黑色箭头表示一开始的方法调用走向，走到最后，返回了Spring中缓存的A对象之后，表示递归调用返回了，此时使用绿色箭头表示。从图中我们可以很清楚的看到，B对象的a属性是在第三步中注入的半成品A对象，而A对象的b属性是在第二步中注入的成品B对象，此时半成品的A对象也就变成了成品的A对象，因为其属性已经设置完成了。Spring是通过递归的方式获取目标bean及其所依赖的bean的； Spring实例化一个bean的时候，是分两步进行的，首先实例化目标bean，然后为其注入属性。
Spring在实例化一个bean的时候，是首先递归的实例化其所依赖的所有bean，直到某个bean没有依赖其他bean，此时就会将该实例返回，然后反递归的将获取到的bean设置为各个上层bean的属性的。Spring循环依赖进阶
实例化：简单理解就是new了一个对象 属性注入：为实例化中new出来的对象填充属性 初始化：执行aware接口中的方法，初始化方法，完成AOP代理
singletonObjects：一级缓存 存储的是所有创建好了的单例BeanearlySingletonObjects：完成实例化，但是还未进行属性注入及初始化的对象singletonFactories：提前暴露的一个单例工厂，二级缓存中存储的就是从这个工厂中获取到的对象
普通循环依赖图
带AOP循环依赖
是否可以用二级缓存而不用三级缓存？
AnnotationAwareAspectJAutoProxyCreator这个后置处理器来完成的，在这个后置处理的postProcessAfterInitialization方法中对初始化后的Bean完成AOP代理。如果出现了循环依赖，那没有办法，只有给Bean先创建代理，但是没有出现循环依赖的情况下，设计之初就是让Bean在生命周期的「最后一步完成代理而不是在实例化后就立马完成代理」。
回答模板
Spring如何解决循环依赖的
对象工厂，添加到三级缓存中，如果A被AOP代理，那么通过这个工厂获取到的就是A代理后的对象，如果A没有被AOP代理，那么这个工厂获取到的就是A实例化的对象。面试官：为什么要使用三级缓存呢？二级缓存能解决循环依赖吗？
违背了Spring设计的原则，Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理，而不是在实例化后就立马进行AOP代理。跟踪核心大致流程
往期热门文章：
4、GitHub 标星 1.3k+，一款超赞的用于字符串处理的 Java 8 库
评论