https://developer.aliyun.com/article/766880
https://cloud.tencent.com/developer/beta/article/1497692
https://segmentfault.com/a/1190000023647227
https://bbs.huaweicloud.com/blogs/362385

核心：
1.spring在对象实例化完成但还未进行属性赋值和初始化的时候，就可以将对象的引用提前暴露出去了。
2.如果没有AOP，其实两层缓存就能解决问题了，第一层缓存存储的是初始化完成后的对象，第二层缓存存储的是实例化完成但还未属性赋值和初始化的对象。
3.第三层缓存不是为了解决循环依赖，本质上是为了延时代理对象的创建，如果循环依赖中有被AOP代理的对象，spring一般都会返回这个代理对象，而不是对象本身，如果是两层缓存，那第二层只能存储代理对象，并且实例化之后马上就要生成代理对象。但是spring的思想是对象初始化之后才应该生成代理对象，所以有了第三层缓存，存储一个工厂，这个工厂负责生成代理对象，每次生成好代理对象之后，存储在二级缓存当中，这样避免了每次请求工厂都会创建出一个新的代理对象（因为是单例bean）

什么是循环依赖

image.png

服务启动之后，这两个bean会无限循环的创建下去，直到栈溢出。

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

满足两个前置条件可以被处理：
1.出现循环依赖的bean必须是单例，这样能保证每次使用的是同一个bean，不至于每次都新建。
2.依赖注入的方式不能全是构造器注入的方式。具体如下：

image.png

spring为了解决循环依赖做了哪些事情

1.构造器注入方式的循环依赖是无法解决的，因为spring解决循环依赖靠的是Bean在处于实例化完成但还未初始化的中间态，而构造器是已经初始化完成阶段才有的，所以这种注入方式是无解的，项目启动就会失败，抛出异常，尽量不要使用。
2.field属性注入（setter方法注入）循环依赖，这种是依靠spring的三级缓存来解决的。
3.prototype field属性注入循环依赖，也无法解决。

spring解决循环依赖的理论依据是基于Java的引用传递，当获得对象的引用时，对象的属性是可以延后设置的。（但构造器必须是在获取引用之前，所以构造器无解）

image.png image.png

其中，除了一级缓存是已经初始化完成的对象之外，二三级缓存都是为了解决循环依赖的。
从缓存获取bean的时候，按照1,2,3依次去获取。
三级缓存的添加时刻是，使用构造器去实例化Bean，实例化完成之后就加入到三级缓存中，三级缓存是用来生成半成品的bean并放入到二级缓存中。
二级缓存添加时刻是，查询三级缓存存在，二级缓存不存在的时候，将bean的引用copy到二级缓存中。
一级缓存添加的时刻是，bean完成初始化之后。

最后的最后，由于我太暖心了_，再来个纯文字版的总结。
依旧以上面A、B类使用属性field注入循环依赖的例子为例，对整个流程做文字步骤总结如下：

使用context.getBean(A.class)，旨在获取容器内的单例A(若A不存在，就会走A这个Bean的创建流程)，显然初次获取A是不存在的，因此走A的创建之路~
实例化A（注意此处仅仅是实例化），并将它放进缓存（此时A已经实例化完成，已经可以被引用了）
初始化A：@Autowired依赖注入B（此时需要去容器内获取B）
为了完成依赖注入B，会通过getBean(B)去容器内找B。但此时B在容器内不存在，就走向B的创建之路~
实例化B，并将其放入缓存。（此时B也能够被引用了）
初始化B，@Autowired依赖注入A（此时需要去容器内获取A）
此处重要：初始化B时会调用getBean(A)去容器内找到A，上面我们已经说过了此时候因为A已经实例化完成了并且放进了缓存里，所以这个时候去看缓存里是已经存在A的引用了的，所以getBean(A)能够正常返回
B初始化成功（此时已经注入A成功了，已成功持有A的引用了），return（注意此处return相当于是返回最上面的getBean(B)这句代码，回到了初始化A的流程中~）。
因为B实例已经成功返回了，因此最终A也初始化成功
到此，B持有的已经是初始化完成的A，A持有的也是初始化完成的B，完美~
站的角度高一点，宏观上看Spring处理循环依赖的整个流程就是如此。希望这个宏观层面的总结能更加有助于小伙伴们对Spring解决循环依赖的原理的了解，同时也顺便能解释为何构造器循环依赖就不好使的原因。

其实如果没有AOP，三级缓存和二级缓存存储的对象是一样的，都是实例化成功，还未赋值的bean，可以被引用。三级缓存主要是为了解决AOP情况下的bean的循环依赖的。
以SpringAOP自动代理为例，如果没有自动代理不生成代理对象，只使用二级缓存完全可以解决循环依赖的问题（指的是singletonObjects和singletonFactories这两个缓存，无需earlySingletonObjects这个缓存）
但是这样就会在实例化之后马上进行代理对象的创建，但spring的思想是初始化完成之后再进行代理对象的创建，所以三级缓存最大的作用是延时代理对象的创建。

image.png image.png image.png

三级缓存放的是一个包装后的ObjectFactory，
如果创建的Bean有对应的代理，那其他对象注入时，注入的应该是对应的代理对象；但是Spring无法提前知道这个对象是不是有循环依赖的情况，而正常情况下（没有循环依赖情况），Spring都是在创建好完成品Bean之后才创建对应的代理。这时候Spring有两个选择：

不管有没有循环依赖，都提前创建好代理对象，并将代理对象放入缓存，出现循环依赖时，其他对象直接就可以取到代理对象并注入。
不提前创建好代理对象，在出现循环依赖被其他对象注入时，才实时生成代理对象。这样在没有循环依赖的情况下，Bean就可以按着Spring设计原则的步骤来创建。
Spring选择了第二种方式，那怎么做到提前曝光对象而又不生成代理呢？
Spring就是在对象外面包一层ObjectFactory，提前曝光的是ObjectFactory对象，在被注入时才在ObjectFactory.getObject方式内实时生成代理对象，并将生成好的代理对象放入到第二级缓存Map<String, Object> earlySingletonObjects。