Spring解决循环依赖的思路竟然来自于一道算法题

Posted 2021-06-30 业余草

你知道的越多，不知道的就越多，业余的像一棵小草！

成功路上并不拥挤，因为坚持的人不多。

编辑：业余草

juejin.cn/post/6844904122160775176

推荐：https://www.xttblog.com/?p=5221

前言

「Spring」如何解决的循环依赖，是近两年流行起来的一道 Java 面试题。我今年也面试过很多自称“高级”的 Java 工程师，对循环依赖的回答多数都不是很理想，今天我们一起来学习学习它。

当然，我作为面试官，如果你回答不出来循环以来，我可能会问一些诸如“如果注入的属性为「null」，你会从哪几个方向去排查”这些「场景题」等等。

正文

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

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

Java Bean 相互引用

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

Java Bean 自引用

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

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

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

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

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

基于构造器的循环依赖，就更不用说了，官方文档：https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-dependency-resolution都摊牌了，你想让构造器注入支持循环依赖，是不存在的，不如把代码改了。

那么默认单例的属性注入场景，「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」中。

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

Spring的循环依赖

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

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

当然了，这个地步你肯定要结合Spring源码：https://github.com/spring-projects/spring-framework来看，要不肯定看不懂。

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

循环依赖的本质

上文了解完 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));  
    }

    @SneakyThrows  
    private 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：https://leetcode-cn.com/problems/two-sum/，序号为 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」。如果我们陷入了某个“牛角尖”，不妨跳出来看看，可能会更佳清晰哦。