spring解决循环依赖

什么是循环依赖，为什么会出现循环依赖，其实这些都跟spring的bean的加载流程有关；解决循环依赖最好的方法就是"打破循环"

1. 既然spring的循环依赖的出现跟bean的加载流程有关，那这里我们先简单了解一下spring的bean的加载流程(忽略直接从单例池中获取到bean)

        spring的bean的加载流程，可大致分为：1.实例化bean,2. 属性注入 3. 其它操作 4. 将经历了整个流程的bean加入单例池；这就是spring的bean的大致的加载流程。

2. 为什么会出现循环依赖

        假设我们现在有两个类：分别是A类，B类；然后现在A中注入了属性B，B中又注入了属性A，然后spring在创建A的时候(属性注入的时候)，发现依赖了B类，因为此时B还没有创建，所以此时spring就会去创建B,然后在创建B的时候，又发现B又依赖了A，因为此时A还没有创建完成，还在创建中(还在依赖B中)，就相当于spring此时也没有A，所以此时又会去创建A，这样就产生了一个无限循环；这就是spring的循环依赖

3. spring解决循环依赖

        spring既然出现了循环依赖问题，那肯定就得想办法解决，而且这种相互依赖的情况在我们的开发中也会是出现的情况(我这里就不说过多的原理，感兴趣的读者可以自行下来了解，我就直接进入spring的底层:注，只讲循环依赖，不包括完整的bean的加载流程) ；注：解决循环依赖的最好方法，就是"打破循环" ，spring的三级缓存主要就是用来打破这个循环的

同样，我们先搭建一个spring项目，此时我们在getBean(beanName),在获取对象

获取对象，之后第一步就会走到这里，spring试图先从缓存中获取bean，因为我们此时都还没创建bean，所以此时缓存中没有获取到bean,没有获取到bean之后，spring就会继续往下，然后去创建bean

这里调用了getSingleton的重载方法，我们先进入 getSingleton方法

3.1 getSingleton方法

为什么要先看getSingleton方法，其实这里我就想让大家知道，在正在创建完成完整bean前，spring会先通过一个Set<String> 集合，记录当前bean为正在创建的bean,也就是这里的beforeSingletonCreation方法，希望大家记住，记录当前bean的正在创建的状态，和获取完整bean的先后步奏;在这里spring记录了bean的正在创建的状态后，然后就会去调用传进来的lamda表达式去创建bean,也就是调用上一副图的createBean方法

3.2 doCreateBean方法

        记录好当前bean为正在创建的bean时，此时spring就去真正的创建bean,调用createBean方法，进入到createBean方法后，我们直接进入doCreateBean方法，这个才是真正干实事的方法

进来之后，spring第一步就会去实例化bean(这里可以将此时的bean理解成一个空壳bean,就是调用无参构造创建好的bean：大部分也确实如此),

 实例化完bean（空壳bean）之后，spring为了避免循环依赖，则会在属性注入前，将当前的bean加入到缓存中(lamda表达式，这个lamda表达式其实是在提前准备当前bean的AOP)；(先暂时这样理解，这样在依赖B的时候，B就可以直接去缓存中找到有A了，这样就打破了这个循环)

addSingletonFactory方法

 将当前bean对应的ObjectFactory加入到缓存中(这里我有点不想扩展了，因为扩展下来有点多)；为什么spring会提前将bean对应的ObjectFactory(这个ObjectFactory其实就是在提早的进行AOP)提前放入到缓存中呢；不晓得大家有没有留意过哈，我们注入到其它类中的bean其实是经过完整周期的bean，其中该bean也包括经过了AOP流程，但是spring的AOP是在初始化后(也就是在bean的加载流程第4步中)才执行的，但是我们的依赖注入，是在第四步前，那么此时我们所注入的bean其实是没有经过AOP的，所以spring为了解决这个问题，则就在属性注入前，提前将改中情况加入到缓存中(三级缓存：lamda表达式)，然后在真正后面被依赖到时候，就从三级缓存中直接拿出来，并执行，这样就解决了AOP的问题

3.3 populateBean方法

        在了解了，三级缓存的作用后，我们接着继续往下走，看属性输入

 进入到属性注入方法后，我们看到了，我们非常熟悉的，spring在进行DI依赖注入时，是通过按照名称/按照类型匹配的，这里就出现了，我们直接看按照名称匹配

autowireByName方法

进入到按照名称匹配的方法后，我们可以很清晰的看到一个方法getBean(beanName)方法；这里不直接惊叹一声吗？卧槽，这不就是我们通过beanName获取bean对应bean的方法吗!!!,然后就又会继续走创建B的流程(这里我就直接跳过)，然后在创建B的时候，在对B进行属性填充的时候，发现B注入了A，然后就会继续回到这里，然后就会重新调用getBean(A)方法，（注：此时，我们已经提前将A的ObjectFactory中了），然后我们在继续往下走

3.4 在B注入A时，接下来我们又回到了getSingleton方法

        注意，此时是B在注入A了，中间重复步奏我跳过了

此时B在调用getBean(A)注入A，因为我们之前，提前将A的对应的ObjectFactory放入了三级缓存中；然后在此时，就调用执行三级缓存中的lamda表达式，执行完之后，就是经过了AOP的bean了，就是我们想要的bean了，那么就将改bean返回，且放入二级缓存中（earlySingletonObjects），并移除三级缓存的bean；

3.5 为什么要二级缓存呢

因为在这里，我们不仅仅可能是A依赖了B，B依赖了A，还有可能是A依赖了C，然后C依赖了A，以为A是单例的，那么spring为了保证单例，也为了提高效率，所以将执行了lamda表达试的bean在加入到二级缓存中，这里也能理解这里的二级缓存为什么叫earlySingletonObjects(就是提早的bean:提前执行AOP的bean);

其实在A依赖B这里正在的步奏是，记录A的正在创建的状态，然后将A对应的ObjectFactory提前加入到三级缓存中，然后在注入B的时候，B又注入A的时候，发现A处于正在创建的状态(说明出现了循环依赖)，那么spring会尝试先从二级缓存中获取bean，如果二级缓存中没有，则会从三级缓存中执行lamda表达式获取bean(在这个过程中，会判断A是否需要执行AOP，如果要，则提前执行AOP，如果不需要，则直接返回对应的bean),从三级缓存中获取到bean之后，然后将获取到的bean加入到二级缓存中，并移除三级缓存; 这样B就获取到了A，B就可以注入A属性了，B就可以经过完整的创建流程了，当B能经过完整的创建流程了，那么A中也有B属性了，然后在通过引用传递，实现对整体A的创建，然后在经历过整体流程的A和B加入到一级缓存中(也就是单例池)，这样就解决了循环依赖问题

4. 最后我们在看一下那个lamda表达式吧

进入到lamda表达式方法

getEarlyBeanReference

 然后在继续往下走，进入getEarlyBeanReference方法，进入之后在进入wrapIfNecessary方法

 在wrapIfNecessary方法中，我们就可以看到spring首先对当前bean进行验证判断是否需要执行AOP,如果需要则提前执行AOP,并返回代理的bean,如果不需要，则返回普通bean

总结

一级缓存：存放经过完整流程的bean

二级缓存：存放提早的bean

三级缓存：存放当前bean对应的ObjectFactry