JavaSpring处理循环依赖详解

Java中的Spring Spring处理循环依赖 2023-05-17 05:05:01 761人浏览八月长安

Python 官方文档：入门教程 => 点击学习

摘要

目录01-前言：什么是循环依赖？02-spring 如何处理循环依赖？03-Spring 中解决循环依赖的三级缓存01-前言：什么是循环依赖？首先，我们先明确下依赖的定义。如果一

01-前言：什么是循环依赖？

首先，我们先明确下依赖的定义。如果一个 Bean bar 的属性，引用了容器中的另外一个 Bean foo，那么称 foo 为 bar 的依赖，或称 bar 依赖 foo。如果用代码表示，可以表示为：

@Component("foo")
public Class Foo {
    @Autowired
    private Bar bar;  // 称 foo 依赖 bar
}

@Component("bar")
public Class Bar {
    @Autowired
    private Baz baz;  // bar 依赖 baz
}

其次，循环引用的概念是指多个 Bean 之间的依赖关系形成了环。接着上面的例子，如果 baz 依赖 foo 或 bar 都将形成循环依赖。

@Component("baz")
public class Baz {
    @Autowired
    private Foo foo; // 形成了循环依赖，baz -> (依赖) foo -> bar -> baz ...
}

02-Spring 如何处理循环依赖？

在之前的文章中，我跟大家一块学习了 Spring 创建 Bean 过程的源码。我们知道：在 createBeanInstance 阶段，需要解决构造器、工厂方法参数的依赖；在 populateBean 阶段，需要解决类属性中对其他 Bean 的依赖。这其实对应了 Spring 中支持的两种依赖注入方式，基于构造器的依赖注入和基于 setter 方法的依赖注入，分别对应前面的两种情况。

接下来，我会通过上节介绍的示例，来分情况讨论产生循环依赖的场景。为了使讨论过程更清楚、更简洁，我会让 foo 依赖 bar，而 bar 依赖 foo。在接下来的描述中，我假设 Spring 会先创建 Bar 的对象，再创建 Foo 的对象。针对不同的依赖情况，可以分为四种场景：

第一种场景，Bar 在构造器参数中依赖 Foo，Foo 在构造器参数中依赖 Bar。这种场景下，依赖的注入发生在 Bar 和 Foo 的实例化阶段。
第二种场景，Bar 在构造器参数中依赖 Foo，Foo 通过 setter 函数依赖 Bar。这种场景下，Bar 中注入 Foo 发生在实例化阶段，Foo 中注入 Bar 发生在属性填充阶段。
第三种场景，Bar 通过 setter 函数依赖 Foo，Foo 在构造器参数中依赖 Bar。这种场景下，Bar 中输入 Foo 发生在属性填充阶段，而 Foo 中注入 Bar 发生在实例化阶段。
第四种场景，Bar 通过 setter 函数依赖 Foo，Foo 通过 setter 函数依赖 Bar。这种场景下，依赖注入均发生在属性填充阶段。

在具体分析上述四种场景之前，先说下结论： Spring 可以解决场景三、四中出现循环依赖的情况，而第一、二种场景，Spring 无法解决，需要重构依赖或者延迟延迟依赖注入的时机（例如使用 @Lazy 等）。细心的读者可能会问第二种、第三种场景有什么不同呢？其实第二、第三种场景本质上是同一种情况，唯一的不同是实例化的先后顺序。结合这个信息，可以得出，先创建的类以构造器参数方式依赖其他 Bean，则会发生循环依赖异常。反过来，如果先创建的类以 setter 方式依赖其他 Bean，则不会发生循环依赖异常。

接下来，我会详细分析每一种场景，并指出抛循环依赖异常的时机。

首先，所有的单例 Bean 会在容器启动后被创建 ConfigurableListableBeanFactory#preInstantiateSingletons，即所谓的 “eager reGIStration of singletons” 过程。

第一种场景，会先触发 Bar 类的实例 bar 的创建。在 createBeanInstance 阶段，会通过 ConstructorResolver#autowireConstructor 来创建实例。 ConstructorResolver#createArgumentArray 会解析构造器中的参数，并处理对其他 Bean 依赖的引用 ConstructorResolver#resolveAutowiredArgument。处理依赖的方式就是通过 DefaultListableBeanFactory#resolveDependency 来查找符合条件的 Bean，最终还是通过 AbstractBeanFactory#getBean 来从容器中取。当通过 getBean("bar") 来触发 Spring 创建 bar 时，在实例化阶段，根据构造器参数来 getBean("foo") 并触发 foo 的创建。在 foo 的实例化过程与 bar 的是完全一样的，最终 getBean("bar")。这是容器中的 bar 还没有创建好，所以会再次触发创建过程。在真正创建过程之前，在 DefaultSingletonBeanRegistry#getSingleton 中会有一次检查，DefaultSingletonBeanRegistry#beforeSingletonCreation 如果发现要创建的 bean 正在创建过程中，则抛出异常。

org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'bar': Requested bean is currently in creation: Is there an unresolvable circular reference?

第二种场景，同样先构建 bar 实例。与第一种场景不同之处在于 foo 创建时，它的 createBeanInstance 阶段能够执行完毕。原因是 foo 只有一个无参构造器（即默认构造器），不需要注入其他依赖。 foo 的 createBeanInstance 阶段执行完毕后，会进入 populateBean 阶段。在这个阶段中，AutowiredAnnotationBeanPostProcessor#postProcessProperties 会处理 setter 函数依赖的 Bean。大致处理过程为：AutowiredAnnotationBeanPostProcessor 识别到 foo 中包含需要注入依赖的 setter 函数，将其映射为 AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement 对象。然后调用 AutowiredMethodElement#inject 方法注入依赖。在 inject 方法中，会调用 DefaultListableBeanFactory#resolveDependency 来查找对应的依赖。到这里为止，后续的过程与第一种场景完全一致了。从容器中尝试获取 bar，发现不存在，会出发 bar 的再次创建，最终在 DefaultSingletonBeanRegistry#beforeSingletonCreation 中抛出异常。

第三种场景，同样先构建 bar 实例。由于它只包含一个默认构造器，所以它的 createBeanInstance 阶段会顺利完成，然后进入 populateBean 阶段。当你仔细回看一下 Spring 创建 Bean 过程的源码，你会发现下面这段代码：

if (earlySingletonExposure) {
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

这段逻辑发生在 createBeanInstance 之后，尚未进入 populateBean 之前。这里其实就是 Spring 解决循环依赖机制的核心点之一，这里我暂且不深入介绍，后面会有详细的分析。

继续前面的分析。bar 实例创建进入到 populateBean 阶段后，会检查其自身依赖情况，然后注入对应的依赖 Bean。这里的处理逻辑依然是 AutowiredAnnotationBeanPostProcessor#postProcessProperties 来处理。当尝试注入 foo 时，会出发 foo 实例的创建过程。foo 通过构造器依赖 bar，因此在其 createBeanInstance 阶段，会通过 ConstructorResolver#autowireConstructor 完成依赖注入。此时通过 getBean("bar") 从容器中尝试获取 bar 时，能够“获取到”。注：这里为什么不会出发 bar 的创建，反而能够直接得到 bar 对象呢？上面的获取到我加了引号，它其实获得的并不是一个完整、可用的 bar。它获得的是通过 earlySingletonExposure 提前暴露出的对象。这个过程在后面介绍三级缓存时会详细介绍。

篇幅原因，第四种场景我不在这里继续分析，感兴趣的读者可以自己尝试分析下。简单提示下，它的过程有点像第三种场景前半段、第二种场景的后半段结合起来。

在上述四种场景下，第一种情况，依赖双方都是通过构造器依赖对方，这种情况下 Spring 是无法处理的。而且，我认为出现这一情况，属于是设计上的缺陷，应当通过重新设计依赖关系来解决，例如可以将基于构造器的注入修改为基于 setter 的注入，或者通过 @Lazy 将依赖的初始化延迟到使用时。通过 Foo、Bar 类来举例说明。

@Component
public class Foo {
    private Bar bar;
    @Autowired
    public Foo(@Lazy Bar bar) {
        this.bar = bar;
    }
}

@Component
public class Bar {
    private Foo foo;
    @Autowired
    public Bar(Foo foo) {  // 或者将对 foo 的依赖，注解为 @Lazy 表示使用时才初始化
        this.foo = foo;
    }
}

另一种修改方式就是，将第一种情况，修改为第二种情况，即：

@Component
public class Bar {
    private Foo foo;
    @Autowired
    public void setFoo(Foo foo) {
        this.foo = foo;
    }
}

03-Spring 中解决循环依赖的三级缓存

Spring 中设计了一个三级缓存用来解决前面介绍的循环依赖问题的处理。三级缓存包括：

singletonObjects，为一级缓存，保存了 beanName -> bean instance 的映射关系。存放的是完全可用的单例 Bean 对象。
earlySingletonObjects，为二级缓存，保存了 beanName -> bean instance 的映射关系。在一级、二级缓存都没有发现目标对象，但三级缓存中存在 ObjectFactory 对象时，调用 ObjectFactory#getObject 创建实例，放入二级缓存，删除三级缓存中的 ObjectFactory 对象。
singletonFactories，为三级缓存，保存了 beanName -> ObjectFactory 的映射关系。在 doCreateBean 时，会向这个 map 中添加 beanName: () -> getEarlyBeanReference(beanName, mbd, bean) 的映射关系，value 是一个函数式接口 ObjectFactory。

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
    synchronized (this.singletonObjects) {
        if (!this.singletonObjects.containsKey(beanName)) {
            this.singletonFactories.put(beanName, singletonFactory);
            this.earlySingletonObjects.remove(beanName);
            this.registeredSingletons.add(beanName);
        }
    }
}

大概了解了 Spring 中的三级缓存后，我们再回过头来看一下 AbstractBeanFactory#getBean 过程。它的实际工作是在 AbstractBeanFactory#doGetBean 中完成的。 doGetBean 方法的具体实现可以简化、抽象为：

protected <T> T doGetBean(
			String name, @Nullable Class<T> requiredType, @Nullable Object[] args, boolean typeCheckOnly)
			throws BeansException {
    Object sharedInstance = getSingleton(beanName);
    if (sharedInstance != null && args == null) {
        // 缓存中存在
         
        beanInstance = getObjectForBeanInstance(sharedInstance, name, beanName, null);
    } else {
        // 缓存中不存在
        // 创建对象
        
        if (mbd.isSingleton()) {
            
            sharedInstance = getSingleton(beanName, () -> {
                try {
                    return createBean(beanName, mbd, args);
                }
            });
            
            beanInstance = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
        }
    }
    
    return adaptBeanInstance(name, beanInstance, requiredType);
}

从上面的源码可以知道，当 DefaultSingletonBeanRegistry#getSingleton(beanName) 时，会先从多级缓存中取对象（可能是 bean instance，也可能是对应的 ObjectFactory）。从多级缓存中取对象的源码如下：

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    // Quick check for existing instance without full singleton lock
    Object singletonObject = this.singletonObjects.get(beanName);
    
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { 
        
        singletonObject = this.earlySingletonObjects.get(beanName);
        if (singletonObject == null && allowEarlyReference) {
            
            synchronized (this.singletonObjects) {
                
                // Consistent creation of early reference within full singleton lock
                singletonObject = this.singletonObjects.get(beanName);
                if (singletonObject == null) {
                    singletonObject = this.earlySingletonObjects.get(beanName);
                    if (singletonObject == null) {
                        ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                        if (singletonFactory != null) {
                            
                            singletonObject = singletonFactory.getObject();
                            this.earlySingletonObjects.put(beanName, singletonObject);
                            this.singletonFactories.remove(beanName);
                        }
                    }
                }
            }
        }
    }
    return singletonObject;
}

注：

isSingletonCurrentlyInCreation(beanName) 意味着什么呢？意味着对应的 Bean 在 doCreateBean 过程中，可能在 createBeanInstance \ populateBean \ initializeBean 阶段中。
在前面提到，createBeanInstance 后，Bean 会被添加到上述多级缓存中的第三级缓存中，存入对象是 beanName -> objectFactory 映射关系。当其他的 Bean 依赖当前 Bean 时，而且允许引用提前暴露的 Bean（即未完全可用的 Bean），会检查第二级缓存，如果没有还会检查第三级缓存，并在得到对应 objectFactory 时，获得对象并将其从第三级移动到第二级。

有些读者看到这里可能会有个疑问，那二级缓存中的对象什么时候删除呢？我们再来回头看下 doGetBean 中的代码片段：

sharedInstance = getSingleton(beanName, () -> {
    try {
        return createBean(beanName, mbd, args);
    }
});

这里的 singleton

public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
    synchronized (this.singletonObjects) {
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null) {
            
            beforeSingletonCreation(beanName);
            boolean newSingleton = false;
            try {
                
                singletonObject = singletonFactory.getObject();
                newSingleton = true;
            }
            catch (IllegalStateException ex) {
                // Has the singleton object implicitly appeared in the meantime ->
                // if yes, proceed with it since the exception indicates that state.
                singletonObject = this.singletonObjects.get(beanName);
                if (singletonObject == null) {
                    throw ex;
                }
            }
            catch (BeanCreationException ex) {
                throw ex;
            }
            finally {
                afterSingletonCreation(beanName);
            }
            if (newSingleton) {
                
                addSingleton(beanName, singletonObject);
            }
        }
        return singletonObject;
    }
}

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);
		}
	}

到这里为止，相信你对 Spring 创建 Bean 的过程以及处理循环依赖的机制能够有个大致的了解。如果想了解的更深或跟多细节，可以自己单步调试下。希望今天的内容能够对你有所帮助。如果有写得不对的地方，也请大家多批评指正。

以上就是Java Spring处理循环依赖详解的详细内容，更多关于Java Spring循环依赖的资料请关注编程网其它相关文章！

您可能感兴趣的文档:

点击免费下载>>软考高级考试备考技巧/历年真题/备考精华资料

--结束END--

本文标题: JavaSpring处理循环依赖详解

本文链接: https://www.lsjlt.com/news/210696.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341