简介
说明
本文打断点来分析Spring（SpringBoot）是如何解决循环依赖的。
相关网址
调用到此处代码的流程见：SpringBoot原理–启动流程_IT利刃出鞘的博客
Bean初始化流程：Spring–Bean的创建过程/获取流程–SpringBoot_IT利刃出鞘的博客
定位代码位置
由上边两篇博客，可以定位到实例化的代码位置：
AbstractAutowireCapableBeanFactory#doCreateBean(beanName, mbdToUse, args)
文章系列
Spring–循环依赖的原理(一)–什么是循环依赖_IT利刃出鞘的博客Spring–循环依赖的原理(二)–打断点分析_IT利刃出鞘的博客Spring–循环依赖的原理(三)–原理概述_IT利刃出鞘的博客Spring–循环依赖的原理(四)–为什么用三级缓存，而不是二级_IT利刃出鞘的博客1.总入口：populateBean总结
经过下边的定位，可确定，核心代码在：AbstractAutowireCapableBeanFactory#populateBean(beanName, mbd, instanceWrapper);
doGetBean中有两个getSingleton方法会先后执行。第一个是尝试从缓存中获取，若缓存中没有 A，则执行第二个，通过工厂获得。
public Object getSingleton(String beanName) 。 public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory)。
第一次通过getSingleton(String beanName)获取bean的时候，缓存中是没有的，于是走到getSingleton(String beanName, ObjectFactory<?> singletonFactory)
流程概述getBean(beanName) //AbstractBeanFactory抽象类（实现的BeanFactory接口） doGetBean(name, null, null, false) //AbstractBeanFactory抽象类。自己的方法。 // 先从单例的缓存中取，取不到则走下一个getSingleton getSingleton(beanName); getSingleton(beanName, () -> { try { return createBean(beanName, mbd, args); }} ) createBean(beanName, mbd, args) //AbstractAutowireCapableBeanFactory抽象类（实现的AbstractBeanFactory） doCreateBean(beanName, mbdToUse, args)//AbstractAutowireCapableBeanFactory抽象类。以下为此类方法 createBeanInstance(beanName, mbd, args); //创建实例 applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName) //post-processors修改bean的定义 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); //解决循环依赖 populateBean(beanName, mbd, instanceWrapper); //填充属性断点调试
打条件断点（DefaultListableBeanFactory#doCreateBean(beanName, mbdToUse, args)
定位代码
实例化A时去实例化B并填充到A对象
在populateBean前后打断点。
结果：
populateBean前（A的）：A已经实例化，其字段b还是null。（图1）populateBean后（A的）：没走到下一行，而是去实例化B去了，再次到了populateBean前。（图2）此时，B已经实例化，其字段a为nullpopulateBean后（B的）：的对象里已经给字段a赋值了，但a的字段b仍然为null。（图3）populateBean后（A的）：在第3步执行完之后，堆栈执行到A的populateBean后边。（图4）此时，A对象里有B对象，B对象里边有A对象，一直循环
图1：
图2：
图3：
图4：
2.后置处理器注入属性
简介
经过上边的定位，可以确定，核心代码在：AbstractAutowireCapableBeanFactory#populateBean(beanName, mbd, instanceWrapper);
打条件断点：
总结（代码流程）
getBeanPostProcessors() // 其中有：AutowiredAnnotationBeanPostProcessor （图1） ibp.postProcessProperties(pvs, bw.getWrappedInstance(), beanName); // AutowiredAnnotationBeanPostProcessor postProcessProperties(PropertyValues pvs, Object bean, String beanName) （图2） InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs); metadata.inject(bean, beanName, pvs); inject(bean, beanName, pvs) //InjectionMetadata element.inject(target, beanName, pvs); //InjectionMetadata （图3） // AutowiredAnnotationBeanPostProcessor // 第一次进来时，this.cached为false。去解决依赖（B对象）（图4） value = beanFactory.resolveDependency(desc, beanName, autowiredBeanNames, typeConverter) // 上边获得之后，使用反射，设置字段的值 field.set(bean, value);
图1：
图2：
图3：
图4：
3.解决依赖
总结
实例化B时，由于之前实例化过A，这次 getSingleton(String beanName) 中发生了不一样的事：能够获得 A 的缓存。
简介
从上一步可以看到，最终调用DefaultListableBeanFactory#resolveDependency，来解决 A => B 的依赖，需要去获取 B，仍然通过 getBean 获取，和之前说 getBean 获取 A 的过程类似，只是这次换成了 B。
调用栈如下：getBean=> doGetBean=> getSingleton，又是熟悉的步骤，但这次 getSingleton(String beanName) 中发生了不一样的事：能够获得 A 的缓存。
4.三级缓存
总结
可以在第3级缓存中获得到bean。
简介
在AbstractBeanFactory#doGetBean()上打两个条件断点：beanName.equals(“a”) || beanName.equals(“b”)
// 为什么不在getSingleton里边打断点？因为getSingleton除了获取bean之外，其他也有地方调用了，会影响我们本处的分析。
断点1：
断点2：
第1次到达断点1：Controller对象获取A对象，三级缓存中都没有
第1次到达断点2：缓存中都没有对象A，所以去创建
第2次到达断点1： 因为A类依赖了B类，所以获取B对象。但也是：三级缓存中都没有B对象
第2次到达断点2： 缓存中都没有对象B，所以去创建
第3次到达断点1： 因为B类依赖了A类，所以获取A对象。此时：第1级缓存中已经有A对象了
第4次到达断点1：A用@Component修饰，要扫描进来。此时缓存中已经有了
第5次到达断点1：B用@Component修饰，要扫描进来。此时缓存中已经有了
带着感恩的心启程，学会爱，爱父母，爱自己，爱朋友，爱他人。
