关注“苏三说技术”，回复：开发手册、时间管理 有惊喜。

也许有些朋友对spring的循环依赖问题并不了解，让我们先一起看看这个例子。

@Service



@Service



@RequestMapping("/test")



@SpringBootApplication

我们在运行Application类的main方法启动服务时，报了如下异常：

Requested bean is currently in creation: Is there an unresolvable circular reference?

这里提示得很明显，出现了循环依赖。

什么是循环依赖？

循环依赖是实例a依赖于实例b，实例b又依赖于实例a。

或者实例a依赖于实例b，实例b依赖于实例c，实例c又依赖于实例a。

像这种多个实例之间的相互依赖关系构成一个环形，就是循环依赖。

为什么会形成循环依赖？

上面的例子中AService实例化时会调用构造方法 public AService(BService bService)，该构造方法依赖于BService的实例。此时BService还没有实例化，需要调用构造方法public BService(AService aService)才能完成实例化，该构造方法巧合又需要AService的实例作为参数。由于AService和BService都没有提前实例化，在实例化过程中又相互依赖对方的实例作为参数，这样构成了一个死循环，所以最终都无法再实例化了。

spring要如何解决循环依赖？

只需要将上面的例子稍微调整一下，不用构造函数注入，直接使用Autowired注入。

@Service



@Service

我们看到可以正常启动了，说明循环依赖被自己解决了

spring为什么能循环依赖？

调用applicationContext.getBean(xx)方法，最终会调到AbstractBeanFactory类的doGetBean方法。由于该方法很长，我把部分不相干的代码省略掉了。

protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,

我们可以看到，该方法一进来会调用getSingleton方法从缓存获取实例，如果获取不到。会判断作用域是否为：单例，多列 或者 都不是，不同的作用域创建实例的规则不一样。接下来，我们重点看一下getSingleton方法。

  public Object getSingleton(String beanName) {



  protected Object getSingleton(String beanName, boolean allowEarlyReference) {

我们发现有三个Map集合：

  /** Cache of singleton objects: bean name --> bean instance */

singletonObjects对应一级缓存，earlySingletonObjects对应二级缓存，singletonFactories对应三级缓存。

上面getSingleton方法的逻辑是：

1. 先从singletonObjects（一级缓存）中获取实例，如果可以获取到则直接返回singletonObject实例。

2. 如果从singletonObjects（一级缓存）中获取不对实例，再从earlySingletonObjects（二级缓存）中获取实例，如果可以获取到则直接返回singletonObject实例。

3. 如果从earlySingletonObjects（二级缓存）中获取不对实例，则从singletonFactories（三级缓存）中获取singletonFactory，如果获取到则调用getObject方法创建实例，把创建好的实例放到earlySingletonObjects（二级缓存）中，并且从singletonFactories（三级缓存）删除singletonFactory实例，然后返回singletonObject实例。

4. 如果从singletonObjects、earlySingletonObjects和singletonFactories中都获取不到实例，则singletonObject对象为空。

获取实例需要调用applicationContext.getBean("xxx")方法，第一次调用getBean方法，代码走到getSingleton方法时返回的singletonObject对象是空的。然后接着往下执行，默认情况下bean的作用域是单例的，接下来我们重点看看这段代码：

createBean方法会调用doCreateBean方法，该方法同样比较长，我们把不相干的代码省略掉。

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)

该方法的主要流程是：

1. 创建bean实例

2. 判断作用域是否为单例，允许循环依赖，并且当前bean正在创建，还没有创建完成。如果都满足条件，则调用addSingletonFactory将bean实例放入缓存中。

3. 调用populateBean方法进行依赖注入

4. 调用initializeBean方法完成对象初始化和AOP增强

我们关注的重点可以先放到addSingletonFactory方法上。

  protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {

该方法的逻辑是判断如果singletonObjects（一级缓存）中找不到实例，则将singletonFactory实例放到singletonFactories（三级缓存）中，并且移除earlySingletonObjects（二级缓存）中的实例。

createBean方法执行完之后，会调用外层的getSingleton方法

我们重点看看这个getSingleton方法

public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {

该方法逻辑很简单，就是先从singletonObjects（一级缓存）中获取实例，如果获取不到，则调用singletonFactory.getObject()方法创建一个实例，然后调用addSingleton方法放入singletonObjects缓存中。

  protected void addSingleton(String beanName, Object singletonObject) {

该方法会将实例放入singletonObjects（一级缓存），并且删除singletonFactories（二级缓存），这样以后再调用getBean时，都能从singletonObjects（一级缓存）中获取到实例了。

说了这么多，再回到示例中的场景。

spring为什么要用三级缓存，而不是二级缓存？

像示例的这种情况只用二级缓存是没有问题的。

但是假如有这种情况：a实例同时依赖于b实例和c实例，b实例又依赖于a实例，c实例也依赖于a实例。

a实例化时，先提前暴露objectFactorya到三级缓存，调用getBean(b)依赖注入b实例。b实例化之后，提前暴露objectFactoryb到三级缓存，调用getBean(a)依赖注入a实例，由于提前暴露了objectFactorya，此时可以从三级缓存中获取到a实例， b实例完成了依赖注入，升级为一级缓存。a实例化再getBean(c)依赖注入c实例，c实例化之后，提前暴露objectFactoryc到三级缓存，调用getBean(a)依赖注入a实例，由于提前暴露了objectFactorya，此时可以从三级缓存中获取到a实例。注意这里又要从三级缓存中获取a实例，我们知道三级缓存中的实例是通过调用singletonFactory.getObject()方法获取的，返回结果每次都可能不一样。如果不用二级缓存，这里会有问题，两次获取的a实例不一样。

总结：

    只有单例的情况下才能解决循环依赖问题，并且allowCircularReferences要设置成true。

以下情况还是会出现循环依赖：

1. 构造器注入

2. 作用域非单例的情况，当然在自定义作用域，自己可以实现避免循环依赖的逻辑

3. allowCircularReferences参数设置为false

大家喜欢这篇文章的话，烦请关注一下 ：苏三说技术

本文分享自微信公众号 - 苏三说技术（gh_9f551dfec941）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。