前言

Spring 如何解决的循环依赖，是近两年流行起来的一道 Java 面试题。

其实笔者本人对这类框架源码题还是持一定的怀疑态度的。

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

那么既然写了这篇文章，闲话少说，发车看看 Spring 是如何解决的循环依赖，以及带大家看清循环依赖的本质是什么。

正文

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

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

甚至自己“循环”依赖自己：

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


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

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

这就套娃了, 你猜是先 StackOverflow 还是 OutOfMemory？

Spring怕你不好猜，就先抛出了 BeanCurrentlyInCreationException。

基于构造器的循环依赖，就更不用说了。官方文档都摊牌了，你想让构造器注入支持循环依赖，是不存在的，不如把代码改了。

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

Spring 解决循环依赖

首先，Spring 内部维护了三个 Map，也就是我们通常说的三级缓存。

笔者翻阅Spring文档倒是没有找到三级缓存的概念，可能也是本土为了方便理解的词汇。

在 Spring 的 DefaultSingletonBeanRegistry 类中，你会赫然发现类上方挂着这三个 Map：

singletonObjects 它是我们最熟悉的朋友，俗称“单例池”“容器”，缓存创建完成单例 Bean 的地方；
singletonFactories 映射创建 Bean 的原始工厂；
earlySingletonObjects 映射 Bean 的早期引用，也就是说在这个 Map 里的 Bean 不是完整的，甚至还不能称之为“Bean”，只是一个 Instance.

后两个 Map 其实是“垫脚石”级别的，只是创建 Bean 的时候，用来借助了一下，创建完成就清掉了。

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

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

那么 Spring 准备了两个杯子，即 singletonFactories 和 earlySingletonObjects 来回“倒腾”几番，把热水晾成“凉白开”放到 singletonObjects 中。

闲话不说，都浓缩在图里。

上面的是一张 GIF，如果你没看到可能还没加载出来。三秒一帧，不是你电脑卡。

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

当然了，这个地方你肯定要结合 Spring 源码来看，要不肯定看不懂。

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

循环依赖的本质

上文了解完 Spring 如何处理循环依赖之后，让我们跳出“阅读源码”的思维，假设让你实现一个有以下特点的功能，你会怎么做？

将指定的一些类实例为单例；
类中的字段也都实例为单例；
支持循环依赖。

举个例子，假设有类 A：

public class A {    private B b;}

类 B：


public class B {    private A a;}

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

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

/** * 放置创建好的bean Map */private static Map<String, Object> cacheMap = new HashMap<>(2);
public static void main(String[] args) {    // 假装扫描出来的对象    Class[] classes = {A.class, B.class};    // 假装项目初始化实例化所有bean    for (Class aClass : classes) {        getBean(aClass);    }    // check    System.out.println(getBean(B.class).getA() == getBean(A.class));    System.out.println(getBean(A.class).getB() == getBean(B.class));}
@SneakyThrowsprivate static <T> T getBean(Class<T> beanClass) {    // 本文用类名小写 简单代替bean的命名规则    String beanName = beanClass.getSimpleName().toLowerCase();    // 如果已经是一个bean，则直接返回    if (cacheMap.containsKey(beanName)) {        return (T) cacheMap.get(beanName);    }    // 将对象本身实例化    Object object = beanClass.getDeclaredConstructor().newInstance();    // 放入缓存    cacheMap.put(beanName, object);    // 把所有字段当成需要注入的bean，创建并注入到当前bean中    Field[] fields = object.getClass().getDeclaredFields();    for (Field field : fields) {        field.setAccessible(true);        // 获取需要注入字段的class        Class<?> fieldClass = field.getType();        String fieldBeanName = fieldClass.getSimpleName().toLowerCase();        // 如果需要注入的bean，已经在缓存Map中，那么把缓存Map中的值注入到该field即可        // 如果缓存没有 继续创建        field.set(object, cacheMap.containsKey(fieldBeanName)                ? cacheMap.get(fieldBeanName) : getBean(fieldClass));    }    // 属性填充完成，返回    return (T) object;}

这段代码的效果，其实就是处理了循环依赖，并且处理完成后，cacheMap 中放的就是完整的“Bean”了。

这就是“循环依赖”的本质，而不是“Spring如何解决循环依赖”。

之所以要举这个例子，是发现一小部分朋友陷入了“阅读源码的泥潭”，而忘记了问题的本质。

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

如果真看不懂，不如先写出基础版本，逆推 Spring 为什么要这么实现，可能效果会更好。

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

看完笔者刚才的代码有没有似曾相识？没错，和 two sum 的解题是类似的。

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

two sum 是刷题网站 LeetCode 序号为 1 的题，也就是大多人的算法入门的第一题。

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

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

比如：给定 nums = [2, 7, 11, 15], target = 9 那么要返回 [0, 1]，因为 2 + 7 = 9。

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


class Solution {    public int[] twoSum(int[] nums, int target) {        Map<Integer, Integer> map = new HashMap<>();        for (int i = 0; i < nums.length; i++) {            int complement = target - nums[i];            if (map.containsKey(complement)) {                return new int[] { map.get(complement), i };            }            map.put(nums[i], i);        }        throw new IllegalArgumentException("No two sum solution");    }}

先去 Map 中找需要的数字，没有就将当前的数字保存在 Map 中，如果找到需要的数字，则一起返回。

和笔者上面的代码是不是一样？

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

结尾

如果你是上文笔者提到的“陷入阅读源码的泥潭”的读者，上文应该可以帮助到你。

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

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

Spring 可不只有依赖注入，同样 Java 也不仅是 Spring。如果我们陷入了某个“牛角尖”，不妨跳出来看看，可能会更清晰哦。

转自：Vt
链接：juejin.cn/post/6844904122160775176

— 【 THE END 】—

本公众号全部博文已整理成一个目录，请在公众号里回复「m」获取！

最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。

获取方式：点“在看”，关注公众号并回复 PDF 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）

图解Spring解决循环依赖

正文

Spring 解决循环依赖

循环依赖的本质

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

结尾