自己总结

要从bean工厂的仓库(单例池)获取bean，如果有则返回，如果没有就需要创建
image.png

创建bean的三个步骤

  1. 实例化(createBeanInstance)，调用对象的构造方法实例化对象，目前对象没有属性
  2. 填充属性(populateBean)，循环依赖主要发生在这里
  3. 初始化(initializeBean)

image.png

image.png

解决循环依赖

spring中引入了半成品池，当创建对象的第一步实例化后，就将对象放入半成品池，如下图
image.png

半成品池中有了对象a(不完整)之后，当b对象填充属性需要引用a对象时，会先从单例池中获取，获取不到就去半成品池中获取，然后b对象就创建完成了，接着a对象填充属性、初始化，也创建完成了放入单例池，然后会删除半成品池中的不完整对象a。这里的关键在于实例化完对象后，就将对象放入半成品池
image.png

解决aop循环依赖

我们一般都会把bean交接spring管理，在bean中使用其他对象时都会通过注入的方式，而在整个项目运行之后，项目中运行的不是它们(所有交给spring管理的类)真正的对象，运行的是经过aop代理的对象，如proxy$a，proxy$b

而对象实例化后，在半成品池生成的对象是a对象(不完整)，不是proxy$a，所以当前模式并不能解决spring的循环依赖问题。

我们先看下aop代理对象是什么时候生成的，在第三步初始化的时候，aop处理器会创建aop代理对象，所以按道理来讲，b在填充属性a的时候是获取不到proxy$a的，怎么办呢

这时候三级缓存—工厂池就闪亮登场了，讲工厂池之前先了解一下aop代理对象的创建机制

在对象初始化的时候，会执行一些BeanPostProcessor(bean处理器，是个接口)，其中有个实现类AspectJAwareAdvisorAutoProxyCreator，它有两种方式可以创建代理对象，第一种就是在初始化的时候使用的postProcessAfterInitialization(后置处理)，第二种是getEarlyBeanReference(提前处理)

image.png

了解了aop代理对象的创建机制之后，我们再来看看加入了三级缓存后，创建对象的过程是怎么样的。首先是实例化a(createBeanInstance)，在实例化时会创建一个ObjectFactory放入singletonFactories(三级缓存)，实例化完成之后，填充属性，发现b对象没有创建，然后创建b对象，先实例化，也会创建一个ObjectFactory放入singletonFactories，接着填充属性a，此时会去获取a对象，先在一级缓存中找，没有找到就去二级缓存中找，还是没有找到就去三级缓存中找，如果找到的话就放入二级缓存，并且将三级缓存中的移除掉，然后将找到的proxy$a填充到proxy$b对象，接着proxy$b对象初始化完成，放入一级缓存，并且将二级缓存中的proxy$b移除，然后将初始化完成的proxy$b填充到proxy$a对象，接着proxy$a对象初始化完成，proxy$a对象创建流程结束。

image.png

先看视频再看下方博客

优秀视频(已经下载到移动硬盘中spring循环依赖)：https://www.bilibili.com/video/BV1ET4y1N7Sp?from=search&seid=5174614121551608520&spm_id_from=333.337.0.0

转载自博客：https://blog.csdn.net/f641385712/article/details/92801300

为防止博客消失，复制一下
版权声明：本文为CSDN博主「方向盘(YourBatman)」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/f641385712/article/details/92801300

Spring解决循环依赖的原理分析

在这之前需要明白java中所谓的引用传递和值传递的区别。

说明：看到这句话可能有小伙伴就想喷我了。java中明明都是传递啊，这是我初学java时背了100遍的面试题，怎么可能有错？？？
这就是我做这个申明的必要性：伙计，你的说法是正确的，java中只有值传递。但是本文借用引用传递来辅助讲解，希望小伙伴明白我想表达的意思~

Spring的循环依赖的理论依据基于Java的引用传递，当获得对象的引用时，对象的属性是可以延后设置的。（但是构造器必须是在获取引用之前，毕竟你的引用是靠构造器给你生成的，儿子能先于爹出生？哈哈）

Spring创建Bean的流程

首先需要了解是Spring它创建Bean的流程，我把它的大致调用栈绘图如下：
image.png[

](https://blog.csdn.net/f641385712/article/details/92801300)

对Bean的创建最为核心三个方法解释如下：

  • createBeanInstance：实例化，其实也就是调用对象的构造方法实例化对象
  • populateBean：填充属性，这一步主要是对bean的依赖属性进行注入(@Autowired)
  • initializeBean：回到一些形如initMethod、InitializingBean等方法

从对单例Bean的初始化可以看出，循环依赖主要发生在第二步（populateBean），也就是field属性注入的处理。

Spring容器的’三级缓存’

在Spring容器的整个声明周期中，单例Bean有且仅有一个对象。这很容易让人想到可以用缓存来加速访问。
从源码中也可以看出Spring大量运用了Cache的手段，在循环依赖问题的解决过程中甚至不惜使用了“三级缓存”，这也便是它设计的精妙之处~

三级缓存其实它更像是Spring容器工厂的内的术语，采用三级缓存模式来解决循环依赖问题，这三级缓存分别指：

  1. public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
  2.     ...
  3.     // 从上至下 分表代表这“三级缓存”
  4.     private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); //一级缓存
  5.     private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); // 二级缓存
  6.     private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); // 三级缓存
  7.     ...
  9.     /** Names of beans that are currently in creation. */
  10.     // 这个缓存也十分重要：它表示bean创建过程中都会在里面呆着~
  11.     // 它在Bean开始创建时放值，创建完成时会将其移出~
  12.     private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<>(16));
  14.     /** Names of beans that have already been created at least once. */
  15.     // 当这个Bean被创建完成后，会标记为这个 注意：这里是set集合 不会重复
  16.     // 至少被创建了一次的  都会放进这里~~~~
  17.     private final Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256));
  18. }

注：AbstractBeanFactory继承自DefaultSingletonBeanRegistry~

  1. singletonObjects：用于存放完全初始化好的 bean，从该缓存中取出的 bean 可以直接使用
  2. earlySingletonObjects：提前曝光的单例对象的cache，存放原始的 bean 对象（尚未填充属性），用于解决循环依赖
  3. singletonFactories：单例对象工厂的cache，存放 bean 工厂对象，用于解决循环依赖

获取单例Bean的源码如下：

  1. public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
  2.     ...
  3.     @Override
  4.     @Nullable
  5.     public Object getSingleton(String beanName) {
  6.         return getSingleton(beanName, true);
  7.     }
  8.     @Nullable
  9.     protected Object getSingleton(String beanName, boolean allowEarlyReference) {
  10.         Object singletonObject = this.singletonObjects.get(beanName);
  11.         if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
  12.             synchronized (this.singletonObjects) {
  13.                 singletonObject = this.earlySingletonObjects.get(beanName);
  14.                 if (singletonObject == null && allowEarlyReference) {
  15.                     ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
  16.                     if (singletonFactory != null) {
  17.                         singletonObject = singletonFactory.getObject();
  18.                         this.earlySingletonObjects.put(beanName, singletonObject);
  19.                         this.singletonFactories.remove(beanName);
  20.                     }
  21.                 }
  22.             }
  23.         }
  24.         return singletonObject;
  25.     }
  26.     ...
  27.     public boolean isSingletonCurrentlyInCreation(String beanName) {
  28.         return this.singletonsCurrentlyInCreation.contains(beanName);
  29.     }
  30.     protected boolean isActuallyInCreation(String beanName) {
  31.         return isSingletonCurrentlyInCreation(beanName);
  32.     }
  33.     ...
  34. }
  1. 先从一级缓存singletonObjects中去获取。（如果获取到就直接return）
  2. 如果获取不到或者对象正在创建中（isSingletonCurrentlyInCreation()），那就再从二级缓存earlySingletonObjects中获取。（如果获取到就直接return）
  3. 如果还是获取不到，且允许singletonFactories（allowEarlyReference=true）通过getObject()获取。就从三级缓存singletonFactory.getObject()获取。（如果获取到了就从singletonFactories中移除，并且放进earlySingletonObjects。其实也就是从三级缓存移动（是剪切、不是复制哦~）到了二级缓存）

加入singletonFactories三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决

getSingleton()从缓存里获取单例对象步骤分析可知，Spring解决循环依赖的诀窍：就在于singletonFactories这个三级缓存。这个Cache里面都是ObjectFactory，它是解决问题的关键。

  1. // 它可以将创建对象的步骤封装到ObjectFactory中 交给自定义的Scope来选择是否需要创建对象来灵活的实现scope。  具体参见Scope接口
  2. @FunctionalInterface
  3. public interface ObjectFactory<T> {
  4.     T getObject() throws BeansException;
  5. }

经过ObjectFactory.getObject()后，此时放进了二级缓存earlySingletonObjects内。这个时候对象已经实例化了，虽然还不完美，但是对象的引用已经可以被其它引用了。

此处说一下二级缓存earlySingletonObjects它里面的数据什么时候添加什么移除？？?
添加：向里面添加数据只有一个地方，就是上面说的getSingleton()里从三级缓存里挪过来
移除：addSingleton、addSingletonFactory、removeSingleton从语义中可以看出添加单例、添加单例工厂ObjectFactory的时候都会删除二级缓存里面对应的缓存值，是互斥的

源码解析

Spring容器会将每一个正在创建的Bean 标识符放在一个“当前创建Bean池”中，Bean标识符在创建过程中将一直保持在这个池中，而对于创建完毕的Bean将从当前创建Bean池中清除掉。
这个“当前创建Bean池”指的是上面提到的singletonsCurrentlyInCreation那个集合。

  1. public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
  2.     ...
  3.     protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
  4.         ...
  5.         // Eagerly check singleton cache for manually registered singletons.
  6.         // 先去获取一次，如果不为null，此处就会走缓存了~~
  7.         Object sharedInstance = getSingleton(beanName);
  8.         ...
  9.         // 如果不是只检查类型，那就标记这个Bean被创建了~~添加到缓存里 也就是所谓的  当前创建Bean池
  10.         if (!typeCheckOnly) {
  11.             markBeanAsCreated(beanName);
  12.         }
  13.         ...
  14.         // Create bean instance.
  15.         if (mbd.isSingleton()) {
  17.             // 这个getSingleton方法不是SingletonBeanRegistry的接口方法  属于实现类DefaultSingletonBeanRegistry的一个public重载方法~~~
  18.             // 它的特点是在执行singletonFactory.getObject();前后会执行beforeSingletonCreation(beanName);和afterSingletonCreation(beanName);  
  19.             // 也就是保证这个Bean在创建过程中，放入正在创建的缓存池里  可以看到它实际创建bean调用的是我们的createBean方法~~~~
  20.             sharedInstance = getSingleton(beanName, () -> {
  21.                 try {
  22.                     return createBean(beanName, mbd, args);
  23.                 } catch (BeansException ex) {
  24.                     destroySingleton(beanName);
  25.                     throw ex;
  26.                 }
  27.             });
  28.             bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
  29.         }
  30.     }
  31.     ...
  32. }
  34. // 抽象方法createBean所在地  这个接口方法是属于抽象父类AbstractBeanFactory的   实现在这个抽象类里
  35. public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory implements AutowireCapableBeanFactory {
  36.     ...
  37.     protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException {
  38.         ...
  39.         // 创建Bean对象，并且将对象包裹在BeanWrapper 中
  40.         instanceWrapper = createBeanInstance(beanName, mbd, args);
  41.         // 再从Wrapper中把Bean原始对象（非代理~~~）  这个时候这个Bean就有地址值了，就能被引用了~~~
  42.         // 注意：此处是原始对象，这点非常的重要
  43.         final Object bean = instanceWrapper.getWrappedInstance();
  44.         ...
  45.         // earlySingletonExposure 用于表示是否”提前暴露“原始对象的引用，用于解决循环依赖。
  46.         // 对于单例Bean，该变量一般为 true   但你也可以通过属性allowCircularReferences = false来关闭循环引用
  47.         // isSingletonCurrentlyInCreation(beanName) 表示当前bean必须在创建中才行
  48.         boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
  49.         if (earlySingletonExposure) {
  50.             if (logger.isTraceEnabled()) {
  51.                 logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");
  52.             }
  53.             // 上面讲过调用此方法放进一个ObjectFactory，二级缓存会对应删除的
  54.             // getEarlyBeanReference的作用：调用SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference()这个方法  否则啥都不做
  55.             // 也就是给调用者个机会，自己去实现暴露这个bean的应用的逻辑~~~
  56.             // 比如在getEarlyBeanReference()里可以实现AOP的逻辑~~~  参考自动代理创建器AbstractAutoProxyCreator  实现了这个方法来创建代理对象
  57.             // 若不需要执行AOP的逻辑，直接返回Bean
  58.             addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
  59.         }
  60.         Object exposedObject = bean; //exposedObject 是最终返回的对象
  61.         ...
  62.         // 填充属性，解决@Autowired依赖~
  63.         populateBean(beanName, mbd, instanceWrapper);
  64.         // 执行初始化回调方法们~~~
  65.         exposedObject = initializeBean(beanName, exposedObject, mbd);
  67.         // earlySingletonExposure：如果你的bean允许被早期暴露出去 也就是说可以被循环引用  那这里就会进行检查
  68.         // 此段代码非常重要~~~~~但大多数人都忽略了它
  69.         if (earlySingletonExposure) {
  70.             // 此时一级缓存肯定还没数据，但是呢此时候二级缓存earlySingletonObjects也没数据
  71.             //注意，注意：第二参数为false  表示不会再去三级缓存里查了~~~
  73.             // 此处非常巧妙的一点：：：因为上面各式各样的实例化、初始化的后置处理器都执行了，如果你在上面执行了这一句
  74.             //  ((ConfigurableListableBeanFactory)this.beanFactory).registerSingleton(beanName, bean);
  75.             // 那么此处得到的earlySingletonReference 的引用最终会是你手动放进去的Bean最终返回，完美的实现了"偷天换日" 特别适合中间件的设计
  76.             // 我们知道，执行完此doCreateBean后执行addSingleton()  其实就是把自己再添加一次  **再一次强调，完美实现偷天换日**
  77.             Object earlySingletonReference = getSingleton(beanName, false);
  78.             if (earlySingletonReference != null) {
  80.                 // 这个意思是如果经过了initializeBean()后，exposedObject还是木有变，那就可以大胆放心的返回了
  81.                 // initializeBean会调用后置处理器，这个时候可以生成一个代理对象，那这个时候它哥俩就不会相等了 走else去判断吧
  82.                 if (exposedObject == bean) {
  83.                     exposedObject = earlySingletonReference;
  84.                 } 
  86.                 // allowRawInjectionDespiteWrapping这个值默认是false
  87.                 // hasDependentBean：若它有依赖的bean 那就需要继续校验了~~~(若没有依赖的 就放过它~)
  88.                 else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
  89.                     // 拿到它所依赖的Bean们~~~~ 下面会遍历一个一个的去看~~
  90.                     String[] dependentBeans = getDependentBeans(beanName);
  91.                     Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
  93.                     // 一个个检查它所以Bean
  94.                     // removeSingletonIfCreatedForTypeCheckOnly这个放见下面  在AbstractBeanFactory里面
  95.                     // 简单的说，它如果判断到该dependentBean并没有在创建中的了的情况下,那就把它从所有缓存中移除~~~  并且返回true
  96.                     // 否则（比如确实在创建中） 那就返回false 进入我们的if里面~  表示所谓的真正依赖
  97.                     //（解释：就是真的需要依赖它先实例化，才能实例化自己的依赖）
  98.                     for (String dependentBean : dependentBeans) {
  99.                         if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
  100.                             actualDependentBeans.add(dependentBean);
  101.                         }
  102.                     }
  104.                     // 若存在真正依赖，那就报错（不要等到内存移除你才报错，那是非常不友好的） 
  105.                     // 这个异常是BeanCurrentlyInCreationException，报错日志也稍微留意一下，方便定位错误~~~~
  106.                     if (!actualDependentBeans.isEmpty()) {
  107.                         throw new BeanCurrentlyInCreationException(beanName,
  108.                                 "Bean with name '" + beanName + "' has been injected into other beans [" +
  109.                                 StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
  110.                                 "] in its raw version as part of a circular reference, but has eventually been " +
  111.                                 "wrapped. This means that said other beans do not use the final version of the " +
  112.                                 "bean. This is often the result of over-eager type matching - consider using " +
  113.                                 "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
  114.                     }
  115.                 }
  116.             }
  117.         }
  119.         return exposedObject;
  120.     }
  122.     // 虽然是remove方法 但是它的返回值也非常重要
  123.     // 该方法唯一调用的地方就是循环依赖的最后检查处~~~~~
  124.     protected boolean removeSingletonIfCreatedForTypeCheckOnly(String beanName) {
  125.         // 如果这个bean不在创建中  比如是ForTypeCheckOnly的  那就移除掉
  126.         if (!this.alreadyCreated.contains(beanName)) {
  127.             removeSingleton(beanName);
  128.             return true;
  129.         }
  130.         else {
  131.             return false;
  132.         }
  133.     }
  135. }

这里举例：例如是field属性依赖注入，在populateBean时它就会先去完成它所依赖注入的那个bean的实例化、初始化过程，最终返回到本流程继续处理，因此Spring这样处理是不存在任何问题的。
这里有个小细节：

  1. if (exposedObject == bean) {
  2.     exposedObject = earlySingletonReference;
  3. }

这一句如果exposedObject == bean表示最终返回的对象就是原始对象，说明在populateBean和initializeBean没对他代理过，那就啥话都不说了exposedObject = earlySingletonReference，最终把二级缓存里的引用返回即可~

流程总结（非常重要）

此处以如上的A、B类的互相依赖注入为例，在这里表达出关键代码的走势：
1、入口处即是实例化、初始化A这个单例Bean。AbstractBeanFactory.doGetBean(“a”)

  1. protected <T> T doGetBean(...){
  2.     ... 
  3.     // 标记beanName a是已经创建过至少一次的~~~ 它会一直存留在缓存里不会被移除（除非抛出了异常）
  4.     // 参见缓存Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256))
  5.     if (!typeCheckOnly) {
  6.         markBeanAsCreated(beanName);
  7.     }
  9.     // 此时a不存在任何一级缓存中，且不是在创建中  所以此处返回null
  10.     // 此处若不为null，然后从缓存里拿就可以了(主要处理FactoryBean和BeanFactory情况吧)
  11.     Object beanInstance = getSingleton(beanName, false);
  12.     ...
  13.     // 这个getSingleton方法非常关键。
  14.     //1、标注a正在创建中~
  15.     //2、调用singletonObject = singletonFactory.getObject();（实际上调用的是createBean()方法）  因此这一步最为关键
  16.     //3、此时实例已经创建完成  会把a移除整整创建的缓存中
  17.     //4、执行addSingleton()添加进去。（备注：注册bean的接口方法为registerSingleton，它依赖于addSingleton方法）
  18.     sharedInstance = getSingleton(beanName, () -> { ... return createBean(beanName, mbd, args); });
  19. }

2、下面进入到最为复杂的AbstractAutowireCapableBeanFactory.createBean/doCreateBean()环节，创建A的实例

  1. protected Object doCreateBean(){
  2.     ...
  3.     // 使用构造器/工厂方法   instanceWrapper是一个BeanWrapper
  4.     instanceWrapper = createBeanInstance(beanName, mbd, args);
  5.     // 此处bean为"原始Bean"   也就是这里的A实例对象：A@1234
  6.     final Object bean = instanceWrapper.getWrappedInstance();
  7.     ...
  8.     // 是否要提前暴露（允许循环依赖）  现在此处A是被允许的
  9.     boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
  11.     // 允许暴露，就把A绑定在ObjectFactory上，注册到三级缓存`singletonFactories`里面去保存着
  12.     // Tips:这里后置处理器的getEarlyBeanReference方法会被促发，自动代理创建器在此处创建代理对象（注意执行时机 为执行三级缓存的时候）
  13.     if (earlySingletonExposure) {
  14.         addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
  15.     }
  16.     ...
  17.     // exposedObject 为最终返回的对象，此处为原始对象bean也就是A@1234,下面会有用处
  18.     Object exposedObject = bean; 
  19.     // 给A@1234属性完成赋值，@Autowired在此处起作用~
  20.     // 因此此处会调用getBean("b")，so 会重复上面步骤创建B类的实例
  21.     // 此处我们假设B已经创建好了 为B@5678
  23.     // 需要注意的是在populateBean("b")的时候依赖有beanA，所以此时候调用getBean("a")最终会调用getSingleton("a")，
  24.     //此时候上面说到的getEarlyBeanReference方法就会被执行。这也解释为何我们@Autowired是个代理对象，而不是普通对象的根本原因
  26.     populateBean(beanName, mbd, instanceWrapper);
  27.     // 实例化。这里会执行后置处理器BeanPostProcessor的两个方法
  28.     // 此处注意：postProcessAfterInitialization()是有可能返回一个代理对象的，这样exposedObject 就不再是原始对象了  特备注意哦~~~
  29.     // 比如处理@Aysnc的AsyncAnnotationBeanPostProcessor它就是在这个时间里生成代理对象的（有坑，请小心使用@Aysnc）
  30.     exposedObject = initializeBean(beanName, exposedObject, mbd);
  32.     ... // 至此，相当于A@1234已经实例化完成、初始化完成（属性也全部赋值了~）
  33.     // 这一步我把它理解为校验：校验：校验是否有循环引用问题~~~~~
  35.     if (earlySingletonExposure) {
  36.         // 注意此处第二个参数传的false，表示不去三级缓存里singletonFactories再去调用一次getObject()方法了~~~
  37.         // 上面建讲到了由于B在初始化的时候，会触发A的ObjectFactory.getObject()  所以a此处已经在二级缓存earlySingletonObjects里了
  38.         // 因此此处返回A的实例：A@1234
  39.         Object earlySingletonReference = getSingleton(beanName, false);
  40.         if (earlySingletonReference != null) {
  42.             // 这个等式表示，exposedObject若没有再被代理过，这里就是相等的
  43.             // 显然此处我们的a对象的exposedObject它是没有被代理过的  所以if会进去~
  44.             // 这种情况至此，就全部结束了~~~
  45.             if (exposedObject == bean) {
  46.                 exposedObject = earlySingletonReference;
  47.             }
  49.             // 继续以A为例，比如方法标注了@Aysnc注解，exposedObject此时候就是一个代理对象，因此就会进到这里来
  50.             //hasDependentBean(beanName)是肯定为true，因为getDependentBeans(beanName)得到的是["b"]这个依赖
  51.             else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
  52.                 String[] dependentBeans = getDependentBeans(beanName);
  53.                 Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
  55.                 // A@1234依赖的是["b"]，所以此处去检查b
  56.                 // 如果最终存在实际依赖的bean：actualDependentBeans不为空 那就抛出异常  证明循环引用了~
  57.                 for (String dependentBean : dependentBeans) {
  58.                     // 这个判断原则是：如果此时候b并还没有创建好，this.alreadyCreated.contains(beanName)=true表示此bean已经被创建过，就返回false
  59.                     // 若该bean没有在alreadyCreated缓存里，就是说没被创建过(其实只有CreatedForTypeCheckOnly才会是此仓库)
  60.                     if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
  61.                         actualDependentBeans.add(dependentBean);
  62.                     }
  63.                 }
  64.                 if (!actualDependentBeans.isEmpty()) {
  65.                     throw new BeanCurrentlyInCreationException(beanName,
  66.                             "Bean with name '" + beanName + "' has been injected into other beans [" +
  67.                             StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
  68.                             "] in its raw version as part of a circular reference, but has eventually been " +
  69.                             "wrapped. This means that said other beans do not use the final version of the " +
  70.                             "bean. This is often the result of over-eager type matching - consider using " +
  71.                             "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
  72.                 }
  73.             }
  74.         }
  75.     }
  76. }

由于关键代码部分的步骤不太好拆分，为了更具象表达，那么使用下面一副图示帮助小伙伴们理解：
image.png

最后的最后，由于我太暖心了_，再来个纯文字版的总结。
依旧以上面A、B类使用属性field注入循环依赖的例子为例，对整个流程做文字步骤总结如下：

  1. 使用context.getBean(A.class)，旨在获取容器内的单例A(若A不存在，就会走A这个Bean的创建流程)，显然初次获取A是不存在的，因此走A的创建之路~
  2. 实例化A（注意此处仅仅是实例化），并将它放进缓存（此时A已经实例化完成，已经可以被引用了）
  3. 初始化A：@Autowired依赖注入B（此时需要去容器内获取B）
  4. 为了完成依赖注入B，会通过getBean(B)去容器内找B。但此时B在容器内不存在，就走向B的创建之路~
  5. 实例化B，并将其放入缓存。（此时B也能够被引用了）
  6. 初始化B，@Autowired依赖注入A（此时需要去容器内获取A）
  7. 此处重要：初始化B时会调用getBean(A)去容器内找到A，上面我们已经说过了此时候因为A已经实例化完成了并且放进了缓存里，所以这个时候去看缓存里是已经存在A的引用了的，所以getBean(A)能够正常返回
  8. B初始化成功（此时已经注入A成功了，已成功持有A的引用了），return（注意此处return相当于是返回最上面的getBean(B)这句代码，回到了初始化A的流程中~）。
  9. 因为B实例已经成功返回了，因此最终A也初始化成功
  10. 到此，B持有的已经是初始化完成的A，A持有的也是初始化完成的B，完美~

站的角度高一点，宏观上看Spring处理循环依赖的整个流程就是如此。希望这个宏观层面的总结能更加有助于小伙伴们对Spring解决循环依赖的原理的了解，同时也顺便能解释为何构造器循环依赖就不好使的原因。