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)
什么是循环依赖
服务启动之后,这两个bean会无限循环的创建下去,直到栈溢出。
什么情况下循环依赖可以被处理
满足两个前置条件可以被处理:
1.出现循环依赖的bean必须是单例,这样能保证每次使用的是同一个bean,不至于每次都新建。
2.依赖注入的方式不能全是构造器注入的方式。具体如下:
spring为了解决循环依赖做了哪些事情
1.构造器注入方式的循环依赖是无法解决的,因为spring解决循环依赖靠的是Bean在处于实例化完成但还未初始化的中间态,而构造器是已经初始化完成阶段才有的,所以这种注入方式是无解的,项目启动就会失败,抛出异常,尽量不要使用。
2.field属性注入(setter方法注入)循环依赖,这种是依靠spring的三级缓存来解决的。
3.prototype field属性注入循环依赖,也无法解决。
spring解决循环依赖的理论依据是基于Java的引用传递,当获得对象的引用时,对象的属性是可以延后设置的。(但构造器必须是在获取引用之前,所以构造器无解)
其中,除了一级缓存是已经初始化完成的对象之外,二三级缓存都是为了解决循环依赖的。
从缓存获取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的思想是初始化完成之后再进行代理对象的创建,所以三级缓存最大的作用是延时代理对象的创建。
三级缓存放的是一个包装后的ObjectFactory,
如果创建的Bean有对应的代理,那其他对象注入时,注入的应该是对应的代理对象;但是Spring无法提前知道这个对象是不是有循环依赖的情况,而正常情况下(没有循环依赖情况),Spring都是在创建好完成品Bean之后才创建对应的代理。这时候Spring有两个选择:
不管有没有循环依赖,都提前创建好代理对象,并将代理对象放入缓存,出现循环依赖时,其他对象直接就可以取到代理对象并注入。
不提前创建好代理对象,在出现循环依赖被其他对象注入时,才实时生成代理对象。这样在没有循环依赖的情况下,Bean就可以按着Spring设计原则的步骤来创建。
Spring选择了第二种方式,那怎么做到提前曝光对象而又不生成代理呢?
Spring就是在对象外面包一层ObjectFactory,提前曝光的是ObjectFactory对象,在被注入时才在ObjectFactory.getObject方式内实时生成代理对象,并将生成好的代理对象放入到第二级缓存Map<String, Object> earlySingletonObjects。