Spring循环依赖解决方案

1.概述

之前我们对Spring Bean生命周期和Bean实例化、属性填充、初始化、销毁等整体流程进行全面分析与总结，不熟悉的可查看：Spring Bean生命周期。我们也提到在创建Bean过程中贯穿着循环依赖问题，Spring使用三级缓存解决循环依赖，这也是一个重要的知识点，所以我们下面就来看看Spring是如何使用三级缓存解决循环依赖的。

什么是循环依赖？

循环依赖，也可以叫做循环引用，就是一个或者多个bean对象之间互相引用，存在依赖关系，大致相互引用情况如下：

由上可知，循环依赖其实就是一个闭环，像图中情况二Spring在创建单例bean A的时候发现引用了B，这时候就会去容器中查找单例bean B，发现没有然后就会创建bean B，创建bean B时又发现引用了bean A，这时候又会去容器中查找bean A，发现没有，接下来就会循环重复上面的步骤，这是不是像极了死锁？其实循环依赖就是一个死循环的过程。

项目推荐：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企业级系统架构底层框架封装，解决业务开发时常见的非功能性需求，防止重复造轮子，方便业务快速开发和企业技术栈框架统一管理。引入组件化的思想实现高内聚低耦合并且高度可配置化，做到可插拔。严格控制包依赖和统一版本管理，做到最少化依赖。注重代码规范和注释，非常适合个人学习和企业使用

Github地址：https://github.com/plasticene/plasticene-boot-starter-parent

Gitee地址：https://gitee.com/plasticene3/plasticene-boot-starter-parent

微信公众号：Shepherd进阶笔记

2.循环依赖案例

在讲述循环依赖示例前，我们先来看看什么是依赖注入？知道了依赖注入之后才能了解循环依赖出现的场景所在。

2.1 什么是依赖注入

依赖注入是Spring IOC(控制反转)模块的一个核心概念，DI (Dependency Injection)：依赖注入是指在 Spring IOC 容器创建对象的过程中，将所依赖的对象通过配置进行注入，我们可以通过依赖注入的方式来降低对象间的耦合度。这里的配置注入可以基于XML配置文件也可以基于注解配置，当下注解配置开发是主流，所以在这里主要讨论基于注解的注入方式，基于注解的常规注入方式通常有三种：

• 基于field属性注入
• 基于setter方法注入
• 基于构造器注入

接下来就让我们分别来看看这三种常规的注入方式。

field属性注入

这种方式是我们平时开发中使用最多的，原因是这种方式使用起来非常简单，代码更加简洁。

@Service
public class UserService {
    @Autowired
    private UserDAO userDAO;  //通过属性注入
  
}

setter方法注入

@Service
public class UserService {
    private UserDAO userDAO;
    
    @Autowired  //通过setter方法实现注入
    public void setUserDAO(serDAO userDAO) {
        this.userDAO = userDAO;
    }
}

构造器注入

@Service
public class UserService {
  private UserDAO userDAO;
    
    @Autowired //通过构造器注入
    public UserService(UserDAO userDAO) {
        this.userDAO = userDAO;
    }
}

2.2 循环依赖示例

首先需要强调一点，虽然Spring允许Bean对象的循环依赖，但事实上，项目中存在Bean的循环依赖，是Bean对象职责划分不明确、代码质量不高的表现，如果存在大量的Bean之间循环依赖，那么代码的整体设计也就越来越糟糕。所以SpringBoot在后续的版本中终于受不了这种滥用，默认把循环依赖给禁用了！从2.6版本开始，如果你的项目里还存在循环依赖，SpringBoot将拒绝启动！

我在2.7版本的Spring Boot中有两个Bean：UserService, RoleService，UserService需要查询某个用户有哪些角色，RoleService需要查询某个角色关联了哪些用户，这样就形成了相互引用循环依赖啦，代码如下：

@Service
public class UserService {

    @Autowired
    private RoleService roleService;
}

@Service
public class RoleService {
    @Autowired
    private UserService userService;
}

启动项目报错如下：存在循环依赖

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  UserService (field private com.plasticene.fast.service.impl.RoleService com.plasticene.fast.service.impl.UserService.roleService)
↑     ↓
|  RoleService (field private com.plasticene.fast.service.impl.UserService com.plasticene.fast.service.impl.RoleService.userService)
└─────┘

接下来我们在配置文件中配置开启允许循环依赖

spring:
  main:
    allow-circular-references: true

项目就能正常启动了。

上面演示的基于field数据注入方式的循环依赖，在开启允许循环依赖的配置的情况下项目正常启动，接下来我们基于开启配置的情况改为构造器依赖注入看看：

@Service
public class UserService {

    private RoleService roleService;

    @Autowired
    public UserService(RoleService roleService) {
        this.roleService = roleService;
    }
}

@Service
public class RoleService {

    private UserService userService;

    @Autowired
    public RoleService(UserService userService) {
        this.userService = userService;
    }
}

在开启允许循环依赖的配置启动项目还是会报错。是的，对于构造器的循环依赖，Spring 是无法解决的，只能抛出 BeanCurrentlyInCreationException 异常表示循环依赖

3.循环依赖解决方案

Spring解决循环依赖的核心思想在于提前曝光，使用三级缓存进行提前曝光。

在DefaultListableBeanFactory的上四级父类DefaultSingletonBeanRegistry中提供如下三个Map作为三级缓存：

public class DefaultSingletonBeanRegistry ... {
  //1、最终存储单例Bean成品的容器，即实例化和初始化都完成的Bean，称之为"一级缓存"
  Map<String, Object> singletonObjects = new ConcurrentHashMap(256);
  //2、早期Bean单例池，缓存半成品对象，且当前对象已经被其他对象引用了，称之为"二级缓存"
  Map<String, Object> earlySingletonObjects = new ConcurrentHashMap(16);
  //3、单例Bean的工厂池，缓存半成品对象，对象未被引用，使用时在通过工厂创建Bean，称之为"三级缓存"
  Map<String, ObjectFactory<?>> singletonFactories = new HashMap(16);
}

我们知道在项目启动时会进行Bean的加载、注入到Spring容器中，当创建某个Bean时发现引用依赖于另一个Bean，就会进行依赖查找，就会来到顶层接口BeanFactory的#getBean()方法，所以接下来看看AbstractBeanFactory的#doGetBean()的实现逻辑，发现首先会根据 beanName 从单例 bean 缓存中获取，如果不为空则直接返回

Object sharedInstance = getSingleton(beanName);

这个#getSingleton()是在DefaultSingletonBeanRegistry实现的：

    @Nullable
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        // Quick check for existing instance without full singleton lock
        // 从单例缓存中加载bean
        Object singletonObject = this.singletonObjects.get(beanName);
        // 单例缓存中没有获取到bean，同时bean在创建中
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            // 从 earlySingletonObjects 获取
            singletonObject = this.earlySingletonObjects.get(beanName);
            // 还是没有加载到bean，并且允许提前创建
            if (singletonObject == null && allowEarlyReference) {
                // 对单例缓存map加锁
                synchronized (this.singletonObjects) {
                    // Consistent creation of early reference within full singleton lock
                    // 再次从单例缓存中加载bean
                    singletonObject = this.singletonObjects.get(beanName);
                    if (singletonObject == null) {
                        // 再次从 earlySingletonObjects 获取
                        singletonObject = this.earlySingletonObjects.get(beanName);
                        if (singletonObject == null) {
                            // 从 singletonFactories 中获取对应的 ObjectFactory
                            ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                            if (singletonFactory != null) {
                                // 获得 bean
                                singletonObject = singletonFactory.getObject();
                                // 添加 bean 到 earlySingletonObjects 中
                                this.earlySingletonObjects.put(beanName, singletonObject);
                                // 从 singletonFactories 中移除对应的 ObjectFactory
                                this.singletonFactories.remove(beanName);
                            }
                        }
                    }
                }
            }
        }
        return singletonObject;
    }

这个方法就是从三级缓存中获取Bean对象，可以看到这里先从一级缓存singletonObjects中查找，没有找到的话接着从二级缓存earlySingletonObjects，还是没找到的话最终会去三级缓存singletonFactories中查找，需要注意的是如果在三级缓存中找到，

就会从三级缓存升级到二级缓存了。所以，二级缓存存在的意义，就是缓存三级缓存中的 ObjectFactory 的 #getObject() 方法的执行结果，提早曝光的单例 Bean 对象。

#getSingleton()返回空就会接着执行AbstractBeanFactory的#doGetBean()的下面逻辑，来到：

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

可以看到原型模式的Bean循环依赖是直接报错，对于单例模式的Bean循环依赖Spring通过三级缓存提前曝光Bean来解决，因为单例Bean在整个容器中就一个，但是原型模式是每次都会创建一个新的Bean，无法使用缓存解决，所以直接报错了。

经过一系列代码之后还是没有当前查找的Bean，就会创建一个Bean，来到代码：

// 上面的缓存中没找到，需要根据不同的模式创建
// bean实例化
// Create bean instance.
if (mbd.isSingleton()) {   // 单例模式
  sharedInstance = getSingleton(beanName, () -> {
    try {
      return createBean(beanName, mbd, args);
    }
    catch (BeansException ex) {
      // Explicitly remove instance from singleton cache: It might have been put there
      // eagerly by the creation process, to allow for circular reference resolution.
      // Also remove any beans that received a temporary reference to the bean.
      // 显式从单例缓存中删除 Bean 实例
      // 因为单例模式下为了解决循环依赖，可能他已经存在了，所以销毁它
      destroySingleton(beanName);
      throw ex;
    }
  });
  bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}

最终来到了AbstractAutowireCapableBeanFactory的#createBean()，真正执行逻辑实现的是#doCreateBean()方法的里面代码片段如下所示：

// Eagerly cache singletons to be able to resolve circular references
        // even when triggered by lifecycle interfaces like BeanFactoryAware.
        // <4> 解决单例模式的循环依赖
        boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                isSingletonCurrentlyInCreation(beanName));
        if (earlySingletonExposure) {
            if (logger.isTraceEnabled()) {
                logger.trace("Eagerly caching bean '" + beanName +
                        "' to allow for resolving potential circular references");
            }
            // 提前将创建的 bean 实例加入到 singletonFactories 中
            // 这里是为了后期避免循环依赖
            addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
        }

这里将创建的Bean工厂对象加入到 singletonFactories 三级缓存中，用来生成半成品的Bean并放入到二级缓存中，提前曝光bean意味着别的bean引用它时依赖查找就可以在前面的#getSingleton()中拿到当前bean直接返回啦，从而解决循环依赖

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
    Assert.notNull(singletonFactory, "Singleton factory must not be null");
    synchronized (this.singletonObjects) {
        if (!this.singletonObjects.containsKey(beanName)) {
            this.singletonFactories.put(beanName, singletonFactory);
            this.earlySingletonObjects.remove(beanName);
            this.registeredSingletons.add(beanName);
        }
    }
}

可以看出，singletonFactories 这个三级缓存是解决 Spring Bean 循环依赖的重要所在。同时这段代码发生在 #createBeanInstance(...) 方法之后，也就是说这个 bean 其实已经被创建出来了，但是它还不是很完美（没有进行属性填充和初始化），但是对于其他依赖它的对象而言已经足够了（可以根据对象引用定位到堆中对象），能够被认出来了。所以 Spring 在这个时候将该对象提前曝光出来，可以被其他对象所使用。

当然也需要注意到addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean))的() -> getEarlyBeanReference(beanName, mbd, bean)匿名函数调用，使用lambda方式生成一个ObjectFactory对象放到三级缓存中，提前曝光的是ObjectFactory对象，在被注入时才在ObjectFactory.getObject方式内实时生成代理对象，也就是调用#getEarlyBeanReference()进行实现的。

// 这里如果当前Bean需要aop代理增强，就是这里生成代理Bean对象的
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (BeanPostProcessor bp : getBeanPostProcessors()) {
            if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
            }
        }
    }
    return exposedObject;
}

这也是为什么 Spring 需要额外增加 singletonFactories 三级缓存的原因，解决 Spring 循环依赖情况下的 Bean 存在动态代理等情况，不然循环注入到别人的 Bean 就是原始的，而不是经过动态代理的！

这里有个值得思考的问题：为什么要包装一层ObjectFactory对象存入三级缓存，说是为了解决Bean对象存在aop代理情况，那么直接生成代理对象半成品Bean放入二级缓存中，这样就可以不用三级缓存了！！！这么一说使用三级缓存的意义在哪里

首先需要明确一点：正常情况下（没有循环依赖），Spring都是在创建好完成品Bean之后才创建对应的代理对象。为了处理循环依赖，Spring有两种选择：

1. 不管有没有循环依赖，都提前创建好代理对象，并将代理对象放入缓存，出现循环依赖时，其他对象直接就可以取到代理对象并注入。
2. 不提前创建好代理对象，在出现循环依赖被其他对象注入时，才实时生成代理对象。这样在没有循环依赖的情况下，Bean就可以按着Spring设计原则的步骤来创建。

显然Spring使用了三级缓存，选择第二种方案，这是为啥呢？

原因是：如果要使用二级缓存解决循环依赖，意味着Bean在构造完后就创建代理对象，这样违背了Spring设计原则。Spring结合AOP跟Bean的生命周期，是在Bean创建完全之后通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来完成的，在这个后置处理的postProcessAfterInitialization方法中对初始化后的Bean完成AOP代理。如果出现了循环依赖，那没有办法，只有给Bean先创建代理，但是没有出现循环依赖的情况下，设计之初就是让Bean在生命周期的最后一步完成代理而不是在实例化后就立马完成代理。

经过实例化，初始化、属性赋值等操作之后，bean对象已经是一个完整的实例了，最终会调用DefaultSingletonBeanRegistry的#addSingleton()将完整bean放入一级缓存singletonObjects。

protected void addSingleton(String beanName, Object singletonObject) {
    synchronized (this.singletonObjects) {
        this.singletonObjects.put(beanName, singletonObject);
        this.singletonFactories.remove(beanName);
        this.earlySingletonObjects.remove(beanName);
        this.registeredSingletons.add(beanName);
    }
}

到这里一个真真正正完整的Bean已经存入Spring容器中，可以随意被使用啦。

这里还涉及到一个比较细节的知识点，也是面试的一个考点：说说BeanFactory、FactoryBean及ObjectFactory三者的作用和区别？

BeanFactory: BeanFactory是IOC容器的核心接口，用于管理Bean的一个工厂接口类，主要功能有实例化、定位、配置应用程序中的对象及建立这些对象间的依赖

FactoryBean: 一般情况下，Spring 通过反射机制利用 bean 的 class 属性指定实现类来实例化 bean 。某些情况下，实例化 bean 过程比较复杂，如果按照传统的方式，则需要提供大量的配置信息，配置方式的灵活性是受限的，这时采用编码的方式可能会得到一个简单的方案。Spring 为此提供了一个 FactoryBean 的工厂类接口，用户可以通过实现该接口定制实例化 bean 的逻辑。FactoryBean在BeanFacotry的实现中有着特殊的处理，如果一个对象实现了FactoryBean 那么通过它get出来的对象实际是
factoryBean.getObject() 得到的对象，如果想得到FactoryBean必须通过在 '&' + beanName 的方式获取。

ObjectFactory: ObjectFactory则只是一个普通的对象工厂接口，从上面可以看到spring对ObjectFactory的应用之一就是，将创建对象 的步骤封装到ObjectFactory中，从而通过ObjectFactory在合适的时机创建合适的bean

4.总结

以上全部就是Spring对单例Bean的循环依赖的解决方案，核心就是使用三级缓存提前曝光Bean对象。两个Bean A,B互相引用循环依赖，Spring的解决过程如下：

1. 通过构建函数创建A对象（A对象是半成品，还没注入属性和调用init方法）。
2. A对象需要注入B对象，发现缓存里还没有B对象，将半成品对象A放入半成品缓存。
3. 通过构建函数创建B对象（B对象是半成品，还没注入属性和调用init方法）。
4. B对象需要注入A对象，从半成品缓存里取到半成品对象A。
5. B对象继续注入其他属性和初始化，之后将完成品B对象放入完成品缓存。
6. A对象继续注入属性，从完成品缓存中取到完成品B对象并注入。
7. A对象继续注入其他属性和初始化，之后将完成品A对象放入完成品缓存。

最后附上一张源码执行流程图：(可自行放大查看)