多个bean之间相互依赖,形成了一个闭环。
Spring设计了三级缓存来解决循环依赖的问题,分别是singletonObjects;二级缓存:earlySingletonObjects;三级缓存:singletonFactories;
第一级缓存:(IOC 说到的单例池就是这里的一级缓存)singletonObjects,存放已经经历了完整生命周期的Bean对象。
第二级缓存:earlySingletonObjects,存放早期暴露出来的Bean对象,Bean的生命周期未结束(属性还未填充完整)。
第三级缓存:Map
getSingleton:希望从容器里面获得单例的bean。
doCreateBean: 没有就创建。
beanpopulateBean: 创建完了以后,要填充属性。
addSingleton: 填充完了以后,再添加到容器进行使用。
例:A 依赖 B,B 依赖 A。C 依赖 E,D 依赖 E,E 不依赖任何其他类。
普通情况下:当创建C的时候,发现依赖E,就会到单例池中去找E,发现找不到,就创建E的Bean,创建完之后 去填充属性,不存在依赖关系的话,就直接创建成功了,加入到单例池中。后续创建D的时候,发现依赖了E,直接在单例池内找到了D就直接填充了属性。
循环依赖的:当创建A的时候,发现依赖了B,将A放入三级缓存,去尝试实例化B,当实例化B的时候,发现又依赖了A,B尝试查单例池(一级缓存),查不到找二级缓存,还是找不到,尝试查三级缓存,找到A之后,将A放到二级缓存,删除三级缓存里面的A,即标识了A是一个早期暴露并且还未填充完整属性的Bean。这样B的依赖就注入成功了,作为一个完整声明周期的Bean,B被放入了单例池(只是其内部的A还处于创建阶段)。再回过头来创建A,这时可以直接在单例池内找到B,A的依赖完成后,就直接创建成功,也放入了单例池内了。
至此Spring解决循环依赖的方案大体描述清楚了,实际为什么会选择一个三级缓存的方式去设计,主要原因是为了避免在一个缓存内(假设是单例池),无法区分Bean的生命周期处于什么阶段,可能会导致其他类取到了一个未完善的Bean,比如属性未正常赋值导致为空 的问题。