Spring Bean循环依赖问题及解决

夜雨风云

已于 2024-03-28 19:30:30 修改

阅读量1.2k

点赞数 2

分类专栏： Spring相关文章标签： spring java

于 2023-11-12 14:04:46 首次发布

本文链接：https://blog.csdn.net/wangxufa/article/details/134360210

版权

Spring相关专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一句话总结

针对Spring Bean的循环依赖问题，如果情况允许，尽量不使用临时规避的手段容忍循环依赖问题。如果因存量代码的问题，尽量将消除循环依赖作为高优先级历史债务进行解决。
在Spring Boot 2.6.0版本开始，默认禁用对循环依赖的支持。也就是说，Spring Boot 2.6.0版本及之后版本，如果存在循环依赖，不管是何种场景，都会报启动错误。如果期望启用对循环依赖的支持，则可以先在配置文件中补充下述配置，做临时规避处理。即将spring.main.allow-circular-references属性设置为true。
对于Bean多例(Prototype)场景，Spring 是不支持解决该场景的循环依赖，只支持Bean单例(Singleton)的场景(不支持都是构造器注入的场景)。在创建Bean的时候，会注入一个还没初始化的对象，从而解决了循环依赖重复创建的问题。这里以A属性注入B，B属性注入A为例，介绍Spring是如何支持循环依赖的。首先在创建A的实例时，会先创建A的对象引用，然后再去查找A依赖的对象，如果不存在，则需要进入依赖对象的创建过程，同样地，会先创建对象的引用，这里是对象B的引用。这样在A中就可以使用B，而B也是类似的操作。

什么是循环依赖

类与类之间的依赖关系形成了闭环，就会导致循环依赖问题的产生。举例来说，假设存在两个服务类A和服务类B，如果A通过依赖注入的方式引用了B，且B通过依赖注入的方式引用了A，那么A和B之间就存在循环依赖。
推广来说，如果涉及多个类，也存在这种依赖关系，那么也是循环依赖问题。
循环依赖问题比较严重，有时会影响服务启动，有时会导致死循环调用(如果线上环境出现循环调用，会导致程序进入死循环，然后服务崩溃，进而导致用户请求无法响应，造成生产事故)，应引起足够的重视。

循环依赖的处理现状

Spring 支持解决循环依赖，但是仅能支持特定的场景，对于不支持的场景，会在启动时报错。Spring 提供的能力后面会详细重点说明下，在Spring Boot 2.6.0版本开始，默认禁用对循环依赖的支持。也就是说，Spring Boot 2.6.0版本及之后版本，如果存在循环依赖，不管是何种场景，都会报启动错误。启动报错关键信息如下：

Description:

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

┌─────┐
|  a (field private com.github.courage007.springbootstarter.service.B com.github.courage007.springbootstarter.service.A.b)
↑     ↓
|  b (field private com.github.courage007.springbootstarter.service.A com.github.courage007.springbootstarter.service.B.a)
└─────┘

Action:

Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to true.

总结来说，Spring 支持一定程度的循环依赖的解决，但是在2.6.0版本及之后的版本，默认禁用该功能。也就是说，Spring Boot 2.6.0版本及之后版本，如果存在循环依赖，不管是何种场景，都会报启动错误。
那么Spring 都支持哪些循环依赖的场景呢，后续如果出现循环依赖问题，又该如何解决呢？接下来详细介绍这些内容。

Spring IoC简介

在正式介绍 Spring 如何解决 Bean 的循环依赖问题前，先简要介绍下Spring 如何实现Bean的注入。Spring使用IoC技术实现Bean的注入，在具体策略上采用了依赖注入的方式。在Spring中支持的依赖注入实现主要有三种：构造器注入、setter方法注入(也称属性注入)、接口注入等。相对于前两种注入方式，接口注入比繁琐和死板，被注入对象必须声明和实现另外的接口，所以常用的Bean注入方式主要有两种：构造器注入和setter方法注入。

Spring 如何解决循环依赖

根据依赖注入的方式不同，可以将循环依赖的场景进行以下划分：

依赖注入	A构造器注入	A属性注入
B构造器注入	启动报错，Spring无法自动解决，需要手动解决	启动成功，Spring可以自动解决
B属性注入	启动成功，Spring可以自动解决	启动成功，Spring可以自动解决

A构造器注入B，B构造器注入A

针对A构造器注入B，B构造器注入A的情况，Spring 无法解决这种循环依赖问题，启动时就会报错，报错内容如下：

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

Description:

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

┌─────┐
|  a defined in file [/spring-boot-example/spring-boot-web-starter/target/classes/com/github/courage007/springbootwebstarter/resource/A.class]
↑     ↓
|  b defined in file [/spring-boot-example/spring-boot-web-starter/target/classes/com/github/courage007/springbootwebstarter/resource/B.class]

因为这种循环依赖在启动时就会被发现，所以不会带入到线上环境，影响可控，但错误比较低级。

A构造器注入B，B属性注入A

针对A构造器注入B，B属性注入A的情况，Spring 可以解决这种循环依赖问题，不会影响Spring应用的启动。示例代码如下：

@Service
public class A {
    private B b;

    public A(B a) {
        this.b = b;
    }

    public void test() {
        System.out.println("A");
    }
}

@Service
public class B {
    @Autowired
    private A a;

    public void test() {
        System.out.println("B");
    }
}

虽然Spring可以解决这种循环依赖问题，但是却无法解决方法之间的循环调用，如果同时存在相互调用，则会导致实例不断的被初始化，从而导致栈溢出。示例代码如下：

@Service
public class A {
    private B b;

    public A(B a) {
        this.b = b;
    }

    public void test() {
        System.out.println("A");
        b.test();
    }
}

@Service
public class B {
    @Autowired
    private A a;

    public void test() {
        System.out.println("B");
        a.test();
    }
}

如果客户端调用了实例A的test方法或实例B的test方法，那么将会触发循环调用，进而导致服务崩溃。异常堆栈示例如下：

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at ./open/src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 872
2023-11-10 16:46:03.497 ERROR 13643 --- [nio-8082-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed; nested exception is java.lang.StackOverflowError] with root cause

java.lang.StackOverflowError: null
	at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:1158) ~[na:na]
	at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:263) ~[na:na]
	at java.base/sun.nio.cs.UTF_8.updatePositions(UTF_8.java:80) ~[na:na]
	at java.base/sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:509) ~[na:na]
	at java.base/sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:564) ~[na:na]
	at java.base/java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:576) ~[na:na]
	at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:292) ~[na:na]
	at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:281) ~[na:na]
	at java.base/sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125) ~[na:na]
	at java.base/java.io.OutputStreamWriter.write(OutputStreamWriter.java:208) ~[na:na]
	at java.base/java.io.BufferedWriter.flushBuffer(BufferedWriter.java:120) ~[na:na]
	at java.base/java.io.PrintStream.write(PrintStream.java:605) ~[na:na]
	at java.base/java.io.PrintStream.print(PrintStream.java:745) ~[na:na]
	at java.base/java.io.PrintStream.println(PrintStream.java:882) ~[na:na]
	at com.github.courage007.springbootwebstarter.resource.A.test(A.java:18) ~[classes/:na]
	at com.github.courage007.springbootwebstarter.resource.B.test(B.java:21) ~[classes/:na]
	at com.github.courage007.springbootwebstarter.resource.A.test(A.java:19) ~[classes/:na]
	at com.github.courage007.springbootwebstarter.resource.B.test(B.java:21) ~[classes/:na]

针对这种情况，因为是在运行时才会发现，如果测试用例覆盖该场景，则不会导致问题流出到现网环境，否则会导致服务崩溃，属于生产事故。

A属性注入B，B构造器注入A

针对A属性注入B，B构造器注入A的情况，其分析与A构造器注入B，B属性注入A一致，保持相同结论即可。

A属性注入B，B属性注入A

针对A属性注入B，B属性注入A的情况，其分析与A构造器注入B，B属性注入A相似，保持相同结论即可。这里给出示例代码：

@Service
public class A {
    @Autowired
    private B b;

    public void test() {
        System.out.println("A");
    }
}

@Service
public class B {
    @Autowired
    private A a;

    public void test() {
        System.out.println("B");
    }
}

源码分析循环依赖

接下来从Spring Bean的创建过程，看看 Spring 是如何解决一定程度的循环依赖问题。首先，定位到AbstractBeanFactory抽象类的createBean方法。这个方法是Bean创建的入口。
进入其实现，会进入到AbstractAutowireCapableBeanFactory抽象类(这里仅展示关键源码，完整代码可以执行查看源码)。

public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
		implements AutowireCapableBeanFactory {
  // ...
	@Override
	protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
			throws BeanCreationException {
    // ...
    // 优先尝试从代理中获取Bean实例
    Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
    if (bean != null) {
      return bean;
    }

		try {
			Object beanInstance = doCreateBean(beanName, mbdToUse, args);
			if (logger.isTraceEnabled()) {
				logger.trace("Finished creating instance of bean '" + beanName + "'");
			}
			return beanInstance;
		} catch (BeanCreationException | ImplicitlyAppearedSingletonException ex) {
			// A previously detected exception with proper bean creation context already,
			// or illegal singleton state to be communicated up to DefaultSingletonBeanRegistry.
			throw ex;
		} catch (Throwable ex) {
			throw new BeanCreationException(
					mbdToUse.getResourceDescription(), beanName, "Unexpected exception during bean creation", ex);
		}
	}

  protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
    throws BeanCreationException {
    // 从这几行代码可知，对于多例模式，是会直接创建Bean实例，所以多例模式下，循环依赖问题无法解决
    BeanWrapper instanceWrapper = null;
    if (mbd.isSingleton()) {
      instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
    }
    if (instanceWrapper == null) {
      // 创建bean实例，主要解决构造器注入的场景
      instanceWrapper = createBeanInstance(beanName, mbd, args);
    }
  
    // 缓存的单例集合可以用来解决一定程度的循环依赖问题
    // 启用缓存的场景：(1) 单例场景；(2) 启用允许循环依赖的开关
    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");
      }
      addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
    }

    // Initialize the bean instance.
    Object exposedObject = bean;
    try {
      // 创建bean实例，主要解决属性注入的场景
      populateBean(beanName, mbd, instanceWrapper);
      // bean的实例化
      exposedObject = initializeBean(beanName, exposedObject, mbd);
    }
    catch (Throwable ex) {
      if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
        throw (BeanCreationException) ex;
      }
      else {
        throw new BeanCreationException(
            mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
      }
    }

		if (earlySingletonExposure) {
			Object earlySingletonReference = getSingleton(beanName, false);
			if (earlySingletonReference != null) {
				if (exposedObject == bean) {
					exposedObject = earlySingletonReference;
				}
				else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
					String[] dependentBeans = getDependentBeans(beanName);
					Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
					for (String dependentBean : dependentBeans) {
						if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
							actualDependentBeans.add(dependentBean);
						}
					}
					if (!actualDependentBeans.isEmpty()) {
						throw new BeanCurrentlyInCreationException(beanName,
								"Bean with name '" + beanName + "' has been injected into other beans [" +
								StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
								"] in its raw version as part of a circular reference, but has eventually been " +
								"wrapped. This means that said other beans do not use the final version of the " +
								"bean. This is often the result of over-eager type matching - consider using " +
								"'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");
					}
				}
			}
		}
    // ...
    return exposedObject;
	}

  protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
		Object exposedObject = bean;
		if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
			for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
				exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
			}
		}
		return exposedObject;
	}
}

public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
	// ...
  /** Cache of singleton objects: bean name to bean instance. */
	private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

  /** Cache of singleton factories: bean name to ObjectFactory. */
	private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

	/** Cache of early singleton objects: bean name to bean instance. */
	private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);

	/** Set of registered singletons, containing the bean names in registration order. */
	private final Set<String> registeredSingletons = new LinkedHashSet<>(256);
  
	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);
			}
		}
	}

  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);
      // 根据是否允许启用allowEarlyReference，再次获取对象
			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;
	}

  // ...
}

经过上述源码分析，可知对于Bean多例(Prototype)场景，Spring 是不支持解决该场景的循环依赖，只支持Bean单例(Singleton)的场景。而且Spring还提供了允许循环依赖的开关(默认是关闭的)。在创建Bean的时候，Spring 使用了三级缓存。Spring优先从一级缓存singletonObjects中获取对象；如果没有，则尝试从二级缓存earlySingletonObjects中获取；如果还是没有，就从三级缓存singletonFactory获取对象，然后将对象放置到二级缓存，并从三级缓存溢出该对象。这里只是Spring Bean对象创建的过程，那么Spring 是如何解决Bean的循环依赖的问题呢？
其实，这里的关键是Spring引入了earlyBeanReference(早期Bean的引用)，也就是说在创建Bean的时候，会注入一个还没初始化的对象，从而解决了循环依赖重复创建的问题。这里以A属性注入B，B属性注入A为例，介绍Spring是如何支持循环依赖的。首先在创建A的实例时，会先创建A的对象引用，然后再去查找A依赖的对象，如果不存在，则需要进入依赖对象的创建过程，同样地，会先创建对象的引用，这里是对象B的引用。这样在A中就可以使用B，而B也是类似的操作。
如果仅使用一级缓存和二级缓存就可以解决循环依赖问题，为什么没有这么做呢？这是因为，并不是需要对所有对象都创建二级缓存，这样可以减少不必要的对象创建，从而节省内存。而引入三级缓存后，如果存在允许循环引用的场景，则会基于对象引用工厂创建对象的引用，然后将其存储到二级缓存。可以说，三级缓存的目的就是为了构造二级缓存中的元素，从而达到节省内存的效果。

循环依赖的处理

了解了Spring 支持的循环依赖的解决能力，接下来针对存在循环依赖的场景，给出合适的处理方案。
如果需要Spring Boot版本从低于2.6.0的版本升级到高于2.6.0的版本，如果现有代码存在循环依赖，且无法再短时间内消减掉该问题，则可以先在配置文件中补充下述配置，做临时规避处理：

spring:
    main:
        allow-circular-references:true  #允许循环依赖

当然，不建议在新写的代码中引入循环依赖问题。接下来根据是否存在方法循环调用，对问题进一步的划分：不存在循环调用的循环依赖，存在循环调用的循环依赖。
注意，这里不再关注循环调用的方式，统一使用A属性注入B，B属性注入A这种方式进行说明。

不存在循环调用的循环依赖

如果存在循环依赖，但是不存在循环调用，如果是在2.6.0以下版本，不会有问题，只是有引入循环调用的风险；如果是在2.6.0以上的版本，如果不主动开启允许循环依赖的特性开关，是会在启动的时候报循环依赖的错误的。但是如果开启允许循环依赖的特性开关，则不会影响启动，只是有引入循环调用的风险。
为消减掉循环调用的风险，应尝试解决掉这种循环依赖，这里给出示例代码：

// 修改前
@Service
public class A {
    @Autowired
    private B b;

    public void test() {
        System.out.println("A");
        b.test();
    }
}

@Service
public class B {
    @Autowired
    private A a;

    public void test() {
        System.out.println("B");
    }
}
// 修改后

// 修改前
@Service
public class A {
    @Autowired
    private C c;

    public void test() {
        System.out.println("A");
        c.test();
    }
}

@Service
public class B {
    @Autowired
    private A a;
}

@Service
public class C {
    public void test() {
        System.out.println("B");
    }
}

可见，这里解决掉循环依赖的方式，就是将被依赖的类中的方法，独立包装成一个类，然后被引用。当然，实际的情况可能更复杂，但是核心的处理策略都是一样的。

存在循环调用的循环依赖

如果存在循环依赖，且存在循环调用，不管是哪一个Spring 版本，都会因循环调用，导致对象重复创建，进而导致堆栈溢出，引发程序崩溃。从直接现象来看，这是开发人员因逻辑思考有问题，写入了死循环的代码导致。且该代码并没有做自测，如果没有测试用例看护，那么这种问题流出到现网环境，将会带来生产事故。
为解决这类Bug，就是要思考现有实现，看看代码逻辑，正常来说，可以先将循环调用消减掉，然后再想办法(参考上一节)消减掉循环调用。这里给出存在循环调用的循环依赖的示例代码(之前已有介绍，这里重复一下，方便阅读)：

@Service
public class A {
    private B b;

    public A(B a) {
        this.b = b;
    }

    public void test() {
        System.out.println("A");
        b.test();
    }
}

@Service
public class B {
    @Autowired
    private A a;

    public void test() {
        System.out.println("B");
        a.test();
    }
}

总结

针对Spring Bean的循环依赖问题，如果情况允许，尽量不使用临时规避的手段容忍循环依赖问题。如果因存量代码的问题，尽量将消除循环依赖作为高优先级历史债务进行解决。循环依赖的引入，要么会影响应用的启动，要么会因方法循环调用陷入死循环，从而导致堆栈溢出，给用户带来影响。

参考

https://blog.csdn.net/wangxuelei036/article/details/104960558 spring 循环依赖以及解决方案
https://www.cnblogs.com/daimzh/p/13256413.html 讲一讲Spring中的循环依赖
https://blog.csdn.net/qq_51076413/article/details/131061348 SpringBoot3.x循环依赖
https://juejin.cn/post/7032910060044943373 Spring Boot 2.6.0正式发布：默认禁止循环依赖、增强Docker镜像构建
https://blog.csdn.net/Microhoo_/article/details/132188824 解决Spring Boot 2.6及之后版本取消了循环依赖的支持的问题
https://zhuanlan.zhihu.com/p/647315070 spring bean 三级缓存

夜雨风云

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
Spring Bean循环依赖问题及解决

类与类之间的依赖关系形成了闭环，就会导致循环依赖问题的产生。举例来说，假设存在两个服务类A和服务类B，如果A通过依赖注入的方式引用了B，且B通过依赖注入的方式引用了A，那么A和B之间就存在循环依赖。推广来说，如果涉及多个类，也存在这种依赖关系，那么也是循环依赖问题。循环依赖问题比较严重，有时会影响服务启动，有时会导致死循环调用(如果线上环境出现循环调用，会导致程序进入死循环，然后服务崩溃，进而导致用户请求无法响应，造成生产事故)，应引起足够的重视。
复制链接

扫一扫