> 孤帆远影碧空尽，唯见长江天际流。 ## 前言当我从[《从Spring为什么要用IoC的支点，我撬动了整个Spring的源码脉络！》](https://juejin.cn/post/7124482061364609038#comment)走过来，再来看Spring中源码的各种细节是如此的舒畅。所以让我们接着剑指Spring源码。 ### 为什么会有循环依赖问题？当一个`Chicken`类引用`Egg`类作为属性依赖，同样`Egg`类中也引用依赖`Chicken`，那么最终就会成为一个**闭环**。如下图所示： ![3b48f1ace1916a5d9506cd58c1e3a03.jpg](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3944ab0fcd024348979360273bc20b8a~tplv-k3u1fbpfcp-watermark.image?) 这就好比鸡生蛋，蛋又生鸡，那么就会发生互相依赖又循环往复的关系就称为**循环依赖**。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1628d5f24a1f456f92b72f71ca672604~tplv-k3u1fbpfcp-watermark.image?) 循环依赖其实只是一个现象（场景），还不是一个问题。当你问`Chicken`和`Egg`两个对象循环依赖后能否相互创建成功？这才是一个问题。例如下面代码所示，如果`Chicken`和`Egg`使用构造器相互依赖注入，那么会陷入循环依赖注入的死循环。 ```java new Chicken( new Egg( new Chicken(new Egg(...)))) ``` 我们再来看循环依赖问题在Spring中主要有的三种情况： - **构造器方式依赖注入** - **Set方式多例（原型）模式下依赖注入** - **Set方式单例依赖注入** 第一种构造方法注入的情况，在上面我们构造器方式的依赖注入会造成无限循环下去。第二种多例的情况，多例跟Spring默认创建单例相反，多例是每创建一次类，实例就会多一份。而单例是确保类的实例只允许一份；所以多例每创建一个Bean时，都会产生一个新的Bean，所以导致无限循环的产生Bean，那么必然导致OOM出现。在Spring中默认就是单例，所以Spring通过第三种set方式，可以实现循环依赖。代码如下所示： ```java @Component public class Chicken { // Chicken中注入了Egg @Autowired private Egg egg; } ``` ```java @Component public class Egg { // Egg中也注入了Chicken @Autowired private Chicken chicken; } ``` ### 解决循环依赖靠定义：三级缓存 Spring为了解决单例的循环依赖问题，首先会定义三级缓存做准备（你会发现很多缓存都是用key-value的方式，Spring也如此，同样用了三个Map）。 ![66fac3b05501090ae970edd155d2a01.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d826a4b2f90e4092932b2c046220948e~tplv-k3u1fbpfcp-watermark.image?) 三个Map就定义在DefaultSingletonBeanRegistry类中。（现在可能对为什么要定义三级缓存感到陌生，但是别急，后面相信你会无比熟悉） ``` java public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry { /** Cache of singleton objects: bean name to bean instance. */ private final Map singletonObjects = new ConcurrentHashMap<>(256); /** Cache of singleton factories: bean name to ObjectFactory. */ private final Map> singletonFactories = new HashMap<>(16); /** Cache of early singleton objects: bean name to bean instance. */ private final Map earlySingletonObjects = new HashMap<>(16); //省略其他 } ``` ### 深入源码看Spring解决循环依赖的脉络先来回顾一个Bena创建的主要流程：实例化Bean -> 填充Bean属性 -> 调用Bean初始化方法。如下图所示，（可以说是Bean生命周期制定的地图，在（[《从Spring为什么要用IoC的支点，我撬动了整个Spring的源码脉络！》](https://juejin.cn/post/7124482061364609038#comment)有畅谈过，所以不再赘述） ![54172228c552534e65a644d30592115.jpg](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2af3bff4c6194f229a19a618f3668507~tplv-k3u1fbpfcp-watermark.image?) Spring源码中在创建Bean的关键代码是使用`getBean()`方法。这也是创建Bean的开始。 ``` public Object getBean(String name) throws BeansException { return doGetBean(name, null, null, false); } ``` 接着我们进到`getBean()`中可以看到`doGetBean()`，在Spring源码中带`do`前缀的方法才是真正干活的。如下代码所示： ``` protected T doGetBean(final String name, @Nullable final Class requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException { final String beanName = transformedBeanName(name); Object bean; // 检查容器中是否已经有当前bean实例 // Eagerly check singleton cache for manually registered singletons. Object sharedInstance = getSingleton(beanName); if (sharedInstance != null && args == null) { //省略日志记录 bean = getObjectForBeanInstance(sharedInstance, name, beanName, null); } //省略其他处理 //创建Bean的实例对象 // Create bean instance. if (mbd.isSingleton()) { sharedInstance = getSingleton(beanName, () -> { try { return createBean(beanName, mbd, args); } catch (BeansException ex) { // Explicitly remove instance from singleton cache: It might have been put there // eagerly by the creation process, to allow for circular reference resolution. // Also remove any beans that received a temporary reference to the bean. destroySingleton(beanName); throw ex; } }); bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd); } else if (mbd.isPrototype()) { // It's a prototype -> create a new instance. Object prototypeInstance = null; try { beforePrototypeCreation(beanName); prototypeInstance = createBean(beanName, mbd, args); } finally { afterPrototypeCreation(beanName); } bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd); } else { String scopeName = mbd.getScope(); final Scope scope = this.scopes.get(scopeName); if (scope == null) { throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'"); } try { Object scopedInstance = scope.get(beanName, () -> { beforePrototypeCreation(beanName); try { return createBean(beanName, mbd, args); } finally { afterPrototypeCreation(beanName); } }); bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd); } //省略其他处理 return (T) bean; } ``` 上述代码尽管很多，但是实际上`doGetBean()`方法主要两件事，如果从缓存中获取不到Bean，那么创建一个新的Bean。而一开始在缓存中是获取不到Bean的，所以会进行Bean的创建，在doGetBean中可以看到很醒目的`createBean()`方法。 ``` protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) throws BeanCreationException { // 省略其他代码 try { Object beanInstance = doCreateBean(beanName, mbdToUse, args); if (logger.isTraceEnabled()) { logger.trace("Finished creating instance of bean '" + beanName + "'"); } return beanInstance; } // 省略其他catch异常处理 } ``` createBean实际做事的还是，前缀带do的`doCreateBean()`来实际创建Bean的方法，主要来看两个核心动作。第一个动作是`createBeanInstance()`来创建Bean的实例（给Bean开辟新的内存空间）。 ``` createBeanInstance(beanName, mbd, args); ``` 第二个动作是执行`addSingletonFactory()`方法，将Bean添加缓存。 ``` addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); ``` 我们来看具体`addSingletonFactory()`方法，可以看到开始添加到第三级缓存。 ``` protected void addSingletonFactory(String beanName, ObjectFactory singletonFactory) { Assert.notNull(singletonFactory, "Singleton factory must not be null"); synchronized (this.singletonObjects) { if (!this.singletonObjects.containsKey(beanName)) { this.singletonFactories.put(beanName, singletonFactory); this.earlySingletonObjects.remove(beanName); this.registeredSingletons.add(beanName); } } } ``` 但会发现`addSingletonFactory()`中添加到三级缓存中是一个`getEarlyBeanReference()`方法，而执行到这个方法时还不是一个完整Bean，那么实际上三级缓存保存是提前暴露出的对象。在getEarlyBeanReference方法的上方是这样描述。（Spring开发者怕你看不懂源码，还写注释跟你说明白） > Obtain a reference for early access to the specified bean > 获取对指定bean的早期访问的引用。也是说`getEarlyBeanReference()`实际上只是直接将实例化创建的Bean返回了。（所以你可能会跟一颗剽悍的种子一样对三级缓存充满疑惑，图什么？别急，跟着一颗剽悍的种子去问个究竟）接着实例化完Bean，继续按照Bean的生命周期流程就走到了Bean的填充属性，所以会看到#doCreateBean->`populateBean()`方法。 ``` populateBean(beanName, mbd, instanceWrapper); ``` 对Bean的填充属性是循环依赖源头的开始，因为此时意味着`Chicken`属性对`Egg`属性注入，而当`Chicken`依赖`Egg`，那么这个时候Spring又会去`getBean(Egg)`。因为`Egg`需要注入`Chicken`，所以在创建`Egg`的时候，又会去调用`getBean(Chicken)`，这个时候就又回到之前的流程了，但是不同的是，之前的`getBean`是为了创建Bean，而此时再调用因为上面`Chicken`在实例化后已经放到三级缓存，所以`Egg`可以从缓存中直接获取到`Chicken`。所以此时`Egg`将从三级缓存中获取到的`Chicken`放入到二级缓存中，同时移除三级缓存中的工厂。接着`Egg`完成对`Chicken`的注入后，`Egg`可以初始化；当Egg初始化完成，那么就回到了`Chicken`完成对`getBean(Egg)`的注入，最后`Chicken`初始化。所以二级earlySingletonObjects所缓存的是完成实例化，但是还未进行属性注入及初始化的对象。在完成初始化后，就可以在#getSingleton->`addSingleton()`方法，将初始化的Bean放入到一级缓存，同时删除二级，三级缓存。 ``` java protected void addSingleton(String beanName, Object singletonObject) { synchronized (this.singletonObjects) { // 添加到一级缓存 this.singletonObjects.put(beanName, singletonObject); // 移除二级缓存 this.singletonFactories.remove(beanName); // 移除三级缓存 this.earlySingletonObjects.remove(beanName); // 将完成的BeanName添加到已经注册的单例集合 this.registeredSingletons.add(beanName); } } ``` 到此循环依赖完全打开。所以一级缓存中已经是完全创建好的单例Bean。 ### 为什么要用三级缓存：一、二级缓存能解决循环依赖吗？当再次回过头来，你会发现只用一、二级缓存似乎也可以解决缓存依赖，但是还存在如果循环依赖还使用Spring中的AOP代理时，此时没有三级缓存，就意味着二级缓存中刚实例化的Bean要完成`AOP`代理。如下图所示，回顾 [《从Spring为什么要用IoC的支点，我撬动了整个Spring的源码脉络！》](https://juejin.cn/post/7124482061364609038#comment)中有畅谈到，BeanPostProcessor后置处理器是AOP实现的关键。所以Bean在制定生命周期时，代理是放在最后一步来完成的，而不是在实例化后就立刻代理。 ![22ae71329ea54dbebec3cdb2b7f2edc.jpg](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8ac5fc83000e43d7bbb7ba58353f94ea~tplv-k3u1fbpfcp-watermark.image?) 所以没有三级缓存，只使用二级缓存，那么就破坏了Spring对Bean生命周期的制定。而通过三级缓存就可以很好的解决循环依赖后还有AOP代理问题。因为AOP代理有可能会把之前的原来的Bean换成代理Bean，所以导致Bean的版本不对，最终也会造成异常。所以最后，再来看一级、二级、三级缓存中分别存放的是什么状态的Bean时，是不是亲切多了呢？先是三级缓存为早期曝光对象工厂`singletonFactories`，是lambada表达式。然后是二级缓存为早期曝光对象`earlySingletonObjects`，是完成实例化，但是还未进行属性注入及初始化的对象。最后是一级缓存为单例池`singletonObjects`，是完全创建好的单例Bean。 ### 最后其实现在在写的这篇，要比前些天刚发布的[《从Spring为什么要用IoC的支点，我撬动了整个Spring的源码脉络！》](https://juejin.cn/post/7124482061364609038#comment)文章还要早的，但是迟迟没发，也因此先暂停发布，原因是我被困住了，我发现尽管我看了再多的源码，对Spring的理解是一块一块的碎片，既不系统，也不结构化，也不融会贯通；可以说是在不断的捡芝麻，而丢了西瓜。所以当我在梳理了Spring脉络后，再来看这些Spring中的各种细节时，就正如众里寻她千百度，蓦然回首，那细节却在灯火阑珊处。好了，夜深了，这些天熬的夜，也到这里了。我是一颗剽悍的种子，**怕什么真理无穷，进一寸，有进一寸的欢喜**。感谢各位朋友的：**关注**、**点赞**、**收藏**和**评论** ，我们下回见！创作不易，勿白嫖。一颗剽悍的种子 | 文【原创】我正在参与掘金技术社区创作者签约计划招募活动，[点击链接报名投稿](https://juejin.cn/post/7112770927082864653 "https://juejin.cn/post/7112770927082864653")。