1.单例Bean循环依赖-setter产生的循环依赖
1.1 原理
为单例搞的三个 map：
- 一级缓存，singletonObjects，存储所有已创建完毕的单例 Bean （完整的 Bean）
- 二级缓存，earlySingletonObjects，存储所有仅完成实例化，但还未进行属性注入和初始化的 Bean
- 三级缓存，singletonFactories，存储能建立这个 Bean 的一个工厂，通过工厂能获取这个 Bean，延迟化 Bean 的生成，工厂生成的 Bean 会塞入二级缓存
getBean()步骤：
- getSingleton(beanName) 依次从三个缓存中获取
- 实例化
- addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
- 属性注入
- 初始化
一个大致过程： getBean(A)，AB循环依赖
- A执行属性注入，这个时候 A 发现需要注入 B，所以去 getBean(B)，此时又会走一遍上面描述的逻辑。
- 到了 B 的属性注入这一步，此时 B 调用 getBean(A)，这时候一级缓存里面找不到，但是发现 A 正在创建中的，于是去二级缓存找，发现没找到，于是去三级缓存找，然后找到了。
并且通过上面提前在三级缓存里暴露的工厂得到 A，然后将这个工厂从三级缓存里删除，并将 A 加入到二级缓存中。
然后结果就是 B 属性注入成功。
紧接着 B 调用 initializeBean 初始化，最终返回，此时 B 已经被加到了一级缓存里 。 - 这时候就回到了 A 的属性注入，此时注入了 B，接着执行初始化，最后 A 也会被加到一级缓存里，且从二级缓存中删除 A。
1.2 getSingleton()
getSingleton()并发安全问题？以及5.3后变了，为啥变了？
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
// Quick check for existing instance without full singleton lock
// 到一级缓存获取
Object singletonObject = this.singletonObjects.get(beanName);
// 条件一：一级缓存不存在
// 1）单实例未创建
// 2）单实例循环依赖（三级缓存解决setter循环依赖）
//1.假设Spring先实例化A，首先拿到A的构造方法，进行反射创建出来A的早期实例对象，这个时候，这个早期对象被包装成了ObjectFactory对象，放到了3级缓存。
//2.处理A的依赖数据，检查发现，A它依赖了B对象，所以接下来，Spring就会去根据B类型到容器中去getBean(B.class)，这里就递归了。
//3.拿到B的构造方法，进行反射创建出来B的早期实例对象，它也会把B包装成ObjectFactory对象，放到3级缓存。
//4.处理B的依赖数据，检查发现，B它依赖了A对象，所以接下来，Spring就会去根据A类型到容器中去getBean(A.class)，去拿A对象，这个又递归了。
//5.程序还会走到当前这个方法。getSingleton这个方法。
//6.条件一成立，条件二也会成立。
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
// 检查二级缓存
singletonObject = this.earlySingletonObjects.get(beanName);
// 二级缓存没有
if (singletonObject == null && allowEarlyReference) {
synchronized (this.singletonObjects) {
// Consistent creation of early reference within full singleton lock
singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null) {
//Spring为什么需要有3级缓存存在，而不是只有2级缓存呢？
//AOP，靠什么实现的呢？动态代理
//静态代理：需要手动写代码，实现一个新的java文件，这个java类 和 需要代理的对象 实现同一个接口，内部维护一个被代理对象（原生）
//代理类，在调用原生对象前后，可以加一些逻辑. 代理对象 和 被代理对象 是两个不同的对象，内存地址一定是不一样的。
//动态代理：不需要人为写代码了，而是依靠字节码框架动态生成class字节码文件，然后jvm再加载，然后也一样 也是去new代理对象，这个
//代理对象 没啥特殊的，也是内部保留了 原生对象，然后在调用原生对象前后 实现的 字节码增强。
//3级缓存在这里有什么目的呢？
//3级缓存里面保存的是对象工厂，这个对象工厂内部保留着最原生的对象引用，ObjectFactory的实现类，getObject()方法，它需要考虑一个问题。
//它到底要返回原生的，还是增强后的。
//getObject会判断当前这个早期实例 是否需要被增强，如果是，那么提前完成动态代理增强，返回代理对象。否则，返回原生对象。
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
// 将三级缓存数据提升到二级
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
}
}
return singletonObject;
}
1.3 为啥需要三级缓存？
三级缓存是否为延迟代理的创建，尽量不打破 Bean 的生命周期
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
}
}
return exposedObject;
}
如果有代理的话，那么我们想要直接拿到的是代理对象。
也就是说如果 A 需要被代理，那么 B 依赖的 A 是已经被代理的 A，所以我们不能返回 A 给 B，而是返回代理的 A 给 B。
这个工厂的作用就是判断这个对象是否需要代理，如果否则直接返回，如果是则返回代理对象。
正常代理对象的生成是基于后置处理器，是 在被代理的对象初始化后期调用生成的 ， 所以如果你提早代理了其实是违背了 Bean 定义的生命周期 。
所以 Spring 先在一个三级缓存放置一个工厂，如果产生循环依赖，那么就调用这个工厂提早得到代理对象。
如果没产生依赖，这个工厂根本不会被调用，所以 Bean 的生命周期就是对的。
其实破坏循环依赖，其实只有二级缓存就够了，但是碍于生命周期的问题，提前暴露工厂延迟代理对象的生成。
2.单例Bean循环依赖-构造参数产生的循环依赖
2.1 构造参数为啥不能解决循环依赖
如果全是构造器注入，比如 A(B b) ，那表明在 new 的时候，就需要得到 B，此时需要 new B 。
但是 B 也是要在构造的时候注入 A ，即 B(A a) ，这时候 B 需要在一个 map 中找到不完整的 A ，发现找不到。
为什么找不到？因为 A 还没 new 完呢，所以找到不完整的 A， 因此如果全是构造器注入的话，那么 Spring 无法处理循环依赖 。
总结：
- 如果循环依赖都是构造器注入，则失败
- 如果循环依赖不完全是构造器注入，则可能成功，可能失败，具体跟BeanName的字母序有关系。
2.2 源码中的处理
getBean()步骤：
- getSingleton(beanName) 依次从三个缓存中获取
- getSingleton(beanName, ObjectFactory)
- beforeSingletonCreation(beanName) 处理构造器循环依赖
- 实例化，这里会getBean()构造器参数
- addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
- 属性注入
- 初始化
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(beanName, "Bean name must not be null");
synchronized (this.singletonObjects) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
//容器销毁时，会设置这个属性为true，这个时候就不能再创建bean实例了，直接抛错。
if (this.singletonsCurrentlyInDestruction) {
throw new BeanCreationNotAllowedException(beanName,
"Singleton bean creation not allowed while singletons of this factory are in destruction " +
"(Do not request a bean from a BeanFactory in a destroy method implementation!)");
}
if (logger.isDebugEnabled()) {
logger.debug("Creating shared instance of singleton bean '" + beanName + "'");
}
//将当前beanName放入到“正在创建中单实例集合”，放入成功，说明没有产生循环依赖，失败，则产生循环依赖，里面会抛异常。
//举个例子：构造方法参数依赖
//A->B B->A
//1.加载A，根据A的构造方法，想要去实例化A对象，但是发现A的构造方法有一个参数是B（在这之前，已经向这个集合中添加了 {A}）
//2.因为A的构造方法依赖B，所以触发了加载B的逻辑..
//3.加载B，根据B的构造方法，想要去实例化B对象，但是发现B的构造方法有一个参数是A（在这之前，已经向这个集合中添加了 {A，B}）
//4.因为B的构造方法依赖A，所以再次触发了加载A的逻辑..
//5.再次来到这个getSingleton方法里，调用beforeSingletonCreation(A),因为创建中集合 已经有A了，所以添加失败，抛出异常
//完事。
beforeSingletonCreation(beanName);
protected void beforeSingletonCreation(String beanName) {
if (!this.inCreationCheckExclusions.contains(beanName) && !this.singletonsCurrentlyInCreation.add(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
}
3.原型模式的循环依赖
3.1 原型模式为啥不能解决循环依赖
如果两个 Bean 都是原型模式的话。
那么创建 A1 需要创建一个 B1。
创建 B1 的时候要创建一个 A2。
创建 A2 又要创建一个 B2。
创建 B2 又要创建一个 A3。
创建 A3 又要创建一个 B3.....
因为原型模式都需要创建新的对象，不能用以前的对象。
3.2 源码中的处理
getBean()步骤：
- getSingleton(beanName) 依次从三个缓存中获取
- 原型循环依赖问题判定
- beforePrototypeCreation(beanName); 加入到prototypesCurrentlyInCreation
- 实例化
- 属性注入
- 初始化
- afterPrototypeCreation(beanName);
//1、原型循环依赖问题判定
//举个例子：
//prototypeA -> B， B -> prototypeA
//1.会向正在创建中的原型集合内添加一个字符串 “A” 下面beforePrototypeCreation(beanName);
//2.创建prototypeA对象，只是一个早期对象。
//3.处理prototypeA的依赖，发现A依赖了B类型的对象
//4.触发了Spring.getBean(“B”)的操作。
//5.根据B的构造方法反射创建出来了B的早期实例
//6.Spring处理B对象的依赖，发现依赖了A。
//7.Spring转头回来再次去获取A去了。getBean(“A”).
//8.条件会返回true，最终抛出异常，算是结束了循环依赖注入。
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
