什么是循环依赖
A依赖了B，B依赖了A。
示例：
// A依赖了B
class A{
public B b;
}
// B依赖了A
class B{
public A a;
}
其实，循环依赖并不是问题，因为对象之间相互依赖是很正常的事情。
示例：
A a = new A();
B b = new B();
a.b = b;
b.a = a;
如上，A和B就相互依赖了，代码运行也是没问题的。
Spring存在循环依赖：
在Spring中，一个对象并不是简单new出来的，而是会经过一系列Bean的生命周期，就是因为Bean的生命周期所以才会出现循环依赖问题。在Spring中，出现循环依赖的场景很多，有的场景Spring自动帮我们解决了，而有的场景则需要程序员来解决。
要明白Spring中的循环依赖，得先明白Spring中Bean的生命周期。
Bean的生命周期
Bean的生命周期指的是，在Spring中Bean是如何生成的，大概流程如下：
- Spring扫描class得到BeanDefinition
- 根据得到的BeanDefinition去生成bean
- 首先根据class推断构造方法
- 根据推断出来的构造方法，反射（new对象），得到一个对象（暂时叫做原始对象）
- 填充原始对象中的属性（依赖注入）
- 如果原始对象中的某个方法被AOP了，那么则需要根据原始对象生成一个代理对象
- 把最终生成的代理对象放入单例池（singletonObjects）中，下次getBean时就直接从单例池拿即可
在第4步得到一个原始对象后，第5步Spring需要给对象中的属性进行依赖注入，比如：
A类中存在一个B类的b属性，所以，当A类生成了一个原始对象之后，就会去给b属性去赋值，此时就会根据b属性的类型和属性名去BeanFactory中去获取B类所对应的单例bean。
如果此时BeanFactory中存在B对应的Bean，那么直接拿来赋值给b属性。
如果此时BeanFactory中不存在B对应的Bean，则需要生成一个B对应的Bean，然后赋值给b属性，就会经过B的Bean的生命周期。
那么在创建B类的Bean的过程中，如果B类中存在一个A类的a属性，那么在创建B的Bean的过程中就需要A类对应的Bean，但是，触发B类Bean的创建的条件是A类Bean在创建过程中的依赖注入，所以这里就出现了循环依赖：ABean创建-->依赖了B属性-->触发BBean创建--->B依赖了A属性--->需要ABean（但ABean还在创建过程中）
此时ABean和BBean都创建不出来。
Spring的三级缓存机制解决的Bean的循环依赖。
三级缓存
三级缓存说明：
- singletonObjects（一级缓存）
缓存的是已经经历了完整生命周期的bean对象。
- earlySingletonObjects（二级缓存）
缓存的是早期的bean对象。
早期表示Bean的生命周期还没走完就把这个Bean放入了earlySingletonObjects。
这个bean如果要经过AOP，那么就会把代理对象放入earlySingletonObjects中，否则就是把原始对象放入earlySingletonObjects，但是不管怎么样，就算是代理对象，代理对象所代理的原始对象也是没有经过完整生命周期的**。**
- singletonFactories（三级缓存）
缓存的是一个ObjectFactory，也就是一个Lambda表达式。
在每个Bean的生成过程中，经过实例化得到一个原始对象后，都会提前基于原始对象暴露一个Lambda表达式，并保存到三级缓存中，这个Lambda表达式可能用到，也可能用不到，如果当前Bean没有出现循环依赖，那么这个Lambda表达式没用，当前bean按照自己的生命周期正常执行，执行完后直接把当前bean放入singletonObjects中，如果当前bean在依赖注入时发现出现了循环依赖（当前正在创建的bean被其他bean依赖了），则从三级缓存中拿到Lambda表达式，并执行Lambda表达式得到一个对象，并把得到的对象放入二级缓存（如果当前Bean需要AOP，那么执行lambda表达式，得到就是对应的代理对象，如果无需AOP，则直接得到一个原始对象)。
图示：
A的Bean在创建过程中，在进行依赖注入之前，先把A的原始Bean放入缓存（提早暴露，只要放到缓存了，其他Bean需要时就可以从缓存中拿了），放入缓存后，再进行依赖注入，此时A的Bean依赖了B的Bean，如果B的Bean不存在，则需要创建B的Bean，而创建B的Bean的过程和A一样，也是先创建一个B的原始对象，然后把B的原始对象提早暴露出来放入缓存中，然后在对B的原始对象进行依赖注入A，此时能从缓存中拿到A的原始对象（虽然是A的原始对象，还不是最终的Bean），B的原始对象依赖注入完了之后，B的生命周期结束，那么A的生命周期也能结束。
通过缓存earlySingletoneObjects已经解决了循环依赖的问题，为什么还需要第三级缓存singletoneFactories呢？
如果A的原始对象注入给B的属性之后，A的原始对象进行了AOP产生了一个代理对象，此时就会出现，对于A而言，它的Bean对象其实应该是AOP之后的代理对象，而B的a属性对应的并不是AOP之后的代理对象，这就产生了冲突。即B依赖的A（非代理对象）和最终的A（代理对象）不是同一个对象。
AOP就是通过一个BeanPostProcessor来实现的，在Spring中AOP利用的要么是JDK动态代理，要么CGLib的动态代理，所以如果给一个类中的某个方法设置了切面，那么这个类最终就需要生成一个代理对象。
一般过程：A类—>生成一个普通对象–>属性注入–>基于切面生成一个代理对象–>把代理对象放入singletonObjects单例池中。此时A生成了两个Bean。
为了在Spring实现IOC的同时实现AOP，需要引入三级缓存singletoneFactories。
singletonFactories中存的是某个beanName对应的ObjectFactory，在bean的生命周期中，生成完原始对象之后，就会构造一个ObjectFactory存入singletonFactories中。这个ObjectFactory是一个函数式接口，所以支持Lambda表达式：() -> getEarlyBeanReference(beanName, mbd, bean)。
getEarlyBeanReference方法作用：
- 首先得到一个cachekey，cachekey就是beanName。
- 然后把beanName和bean（这是原始对象）存入earlyProxyReferences中。
- 调用wrapIfNecessary进行AOP，得到一个代理对象。
将ObjectFactory存入singletonFactories时并不会执行lambda表达式，即不会执行getEarlyBeanReference方法。
在创建B依赖A时：
从singletonFactories根据beanName得到一个ObjectFactory，然后执行ObjectFactory，也就是执行getEarlyBeanReference方法，此时会得到一个A原始对象经过AOP之后的代理对象，然后把该代理对象放入earlySingletonObjects中，注意此时并没有把代理对象放入singletonObjects中，因为此时A原始对象还没有进行属性填充。
当B创建完了之后，A继续进行生命周期，而A在完成属性注入后，会按照它本身的逻辑去进行AOP，而此时A原始对象已经经历过了AOP，所以对于A本身而言，不会再去进行AOP了，那么怎么判断一个对象是否经历过了AOP呢？会利用earlyProxyReferences，在AbstractAutoProxyCreator的postProcessAfterInitialization方法中，会去判断当前beanName是否在earlyProxyReferences，如果在则表示已经提前进行过AOP了，无需再次进行AOP。进行了AOP的判断后，以及BeanPostProcessor的执行之后，就需要把A对应的代理对象从earlySingletonObjects中找到并放入singletonObjects中了。
