如果笔者作为面试官，可能会问一些诸如“如果注入的属性为null，你会从哪几个方向去排查”这些场景题。

正文

通常来说，如果问Spring内部如何解决循环依赖，一定是单默认的单例Bean中，属性互相引用的场景。

比如几个Bean之间的互相引用：

先说明前提：原型(Prototype)的场景是不支持循环依赖的，通常会走到AbstractBeanFactory类中下面的判断，抛出异常。

if (isPrototypeCurrentlyInCreation(beanName)) { throw new BeanCurrentlyInCreationException(beanName);}

原因很好理解，创建新的A时，发现要注入原型字段B，又创建新的B发现要注入原型字段A...

那么默认单例的属性注入场景，Spring是如何支持循环依赖的？

Spring解决循环依赖

首先，Spring内部维护了三个Map，也就是我们通常说的三级缓存。笔者翻阅Spring文档倒是没有找到三级缓存的概念，可能也是本土为了方便理解的词汇。

所以笔者前文对“三级缓存”这个词有些迷惑，可能是因为注释都是以Cache of开头吧。

为什么成为后两个Map为垫脚石，假设最终放在singletonObjects的Bean是你想要的一杯“凉白开”。

笔者画了17张图简化表述了Spring的主要步骤，GIF上方即是刚才提到的三级缓存，下方展示是主要的几个方法。

如果你只是想大概了解，或者面试，可以先记住笔者上文提到的“三级缓存”，以及下文即将要说的本质。

循环依赖的本质

举个例子，假设有类A：

public class A { private B b;}

类B：

public class B { private A a;}

说白了让你模仿Spring：假装A和B是被@Component修饰，并且类中的字段假装是@Autowired修饰的，处理完放到Map中。

其实非常简单，笔者写了一份粗糙的代码，可供参考：

这就是“循环依赖”的本质，而不是“Spring如何解决循环依赖”。之所以要举这个例子，是发现一小部分盆友陷入了“阅读源码的泥潭”，而忘记了问题的本质。

为了看源码而看源码，结果一直看不懂，却忘了本质是什么。

what？问题的本质居然是two sum！

不知道two sum是什么梗的，笔者和你介绍一下：

常常被人调侃，有算法面的公司，被面试官钦定了，合的来。那就来一道two sum走走过场。

问题内容是：给定一个数组，给定一个数字。返回数组中可以相加得到指定数字的两个索引。

这道题的优解是，一次遍历+HashMap：

先去缓存里找Bean，没有则实例化当前的Bean放到Map，如果有需要依赖当前Bean的，就能从Map取到。

结尾

可能还有盆友有疑问，为什么一道“two-sum”，Spring处理的如此复杂？

这个想想Spring支持多少功能就知道了，各种实例方式..各种注入方式..各种Bean的加载，校验..各种callback，aop处理等等..

   
   
   

 
    
    
    

  
     
     
     
交流群已成立
 
    
    
    

   
   
   

   
   
   

 
    
    
    

  
     
     
     

   
      
      
      公众号运营至今，离不开小伙伴们的支持。为了给小伙伴们提供一个互相交流的平台，特地开通了官方交流群。扫描下方二维码备注 进群 或者关注公众号 Java后端 后获取进群通道。
  
     
     
     
  
     
     
     

   
      
      
      
  
     
     
     
 
    
    
    

   
   
   

推荐阅读 

   
   
   

 
    
    
    1. 推荐几个好玩的 GitHub 项目

   
   
   

   
   
   

 
    
    
    2. 推荐几个程序员常用的软件

   
   
   
3. MySQL索引底层：B+树详解