Spring框架解决循环依赖的核心机制与实践

作者：宇宙中心我曹县2026.11.07 02:27浏览量：0

简介：本文系统剖析Spring框架中循环依赖的产生场景、底层解决原理及多级缓存机制，详细拆解三级缓存如何协同完成提前暴露对象引用，并给出构造器注入无法解决、setter与字段注入可解决等关键差异，帮助开发者深入理解IoC容器生命周期，避免常见配置陷阱。

一、什么是循环依赖

在基于IoC（控制反转）容器的应用开发中，Bean之间的依赖关系由容器统一管理和注入。当两个或多个Bean之间形成了相互引用的闭环时，就产生了循环依赖。典型场景包括：

  • 直接循环依赖：A依赖B，B又依赖A；
  • 间接循环依赖：A依赖B，B依赖C，C又依赖A；
  • 自我依赖：某个Bean的属性或构造参数引用自身。

以最简单的直接循环依赖为例，假设存在两个业务类：

  1. public class OrderService {
  2.     private PaymentService paymentService;
  3.     public void setPaymentService(PaymentService paymentService) {
  4.         this.paymentService = paymentService;
  5.     }
  6. }
  8. public class PaymentService {
  9.     private OrderService orderService;
  10.     public void setOrderService(OrderService orderService) {
  11.         this.orderService = orderService;
  12.     }
  13. }

若通过XML或注解方式声明两者互相引用，容器在启动时需要先实例化其中一个Bean，但该Bean的创建过程又要求另一个Bean已就绪，由此形成”先有鸡还是先有蛋”的困境。

二、Spring解决循环依赖的核心机制

Spring IoC容器通过三级缓存和提前暴露对象引用的策略来解决单例作用域下的setter/字段注入循环依赖。下面从源码层面拆解这一过程。

2.1 三级缓存体系

Spring在DefaultSingletonBeanRegistry中维护了三个Map作为缓存：

缓存层级 数据结构 作用
一级缓存 singletonObjects（ConcurrentHashMap） 存放已完全初始化的成品Bean
二级缓存 earlySingletonObjects（ConcurrentHashMap） 存放提前暴露的早期引用（未填充属性）
三级缓存 singletonFactories（HashMap） 存放ObjectFactory工厂，用于生成早期引用

这三级缓存协同工作，构成了解决循环依赖的基础设施。

2.2 详细解决流程

以Bean A依赖Bean B、Bean B依赖Bean A为例，完整的实例化过程如下：

  1. 实例化A：容器获取A的Class对象，通过反射调用无参构造方法创建A的原始实例（此时A的属性尚未填充）。
  2. 提前暴露A：容器将A包装成ObjectFactory放入三级缓存（singletonFactories）。
  3. 填充A的属性：容器发现A需要注入B，于是去获取B。
  4. 实例化B：容器创建B的原始实例。
  5. 提前暴露B：B也被放入三级缓存。
  6. 填充B的属性：容器发现B需要注入A，此时从三级缓存中获取A的ObjectFactory，调用getObject()得到A的早期引用，放入二级缓存，并从三级缓存移除。
  7. B完成初始化：B的属性全部填充完毕，放入一级缓存，从二级、三级缓存中清除。
  8. A完成初始化：容器回到A，此时B已就绪，注入B的成品对象到A中，A完成初始化放入一级缓存。

整个过程的核心在于：通过三级缓存中的工厂对象提前暴露一个”半成品”引用，使后续依赖方能拿到一个虽未完全初始化但已存在的对象实例，从而打破死锁。

2.3 关键代码示意

  1. // 伪代码：提前暴露逻辑
  2. protected Object getSingleton(String beanName) {
  3.     // 1. 从一级缓存获取
  4.     Object bean = singletonObjects.get(beanName);
  5.     if (bean == null) {
  6.         // 2. 从二级缓存获取
  7.         bean = earlySingletonObjects.get(beanName);
  8.         if (bean == null) {
  9.             // 3. 从三级缓存获取
  10.             ObjectFactory factory = singletonFactories.get(beanName);
  11.             if (factory != null) {
  12.                 bean = factory.getObject();   // 生成早期引用
  13.                 earlySingletonObjects.put(beanName, bean);
  14.                 singletonFactories.remove(beanName);
  15.             }
  16.         }
  17.     }
  18.     return bean;
  19. }

三、哪些场景能解决、哪些不能

3.1 可以解决的场景

  • 单例（singleton）作用域 + setter注入/字段注入：这是三级缓存机制的主战场，绝大多数业务Bean属于此类。
  • 单例作用域 + @Autowired字段注入：等同于setter注入，容器通过反射赋值。
  • 单例作用域 + @Resource注解注入：同样适用。

3.2 无法解决的场景

  • 构造器注入（constructor injection）：当循环依赖的Bean通过构造方法相互引用时，Spring无法提前暴露对象，因为构造方法要求所有参数都已就绪，而此时对方尚未实例化。容器会直接抛出BeanCurrentlyInCreationException异常。
  1. // 构造器注入的循环依赖——会报错
  2. public class BeanA {
  3.     private final BeanB beanB;
  4.     public BeanA(BeanB beanB) {  // 需要BeanB已实例化
  5.         this.beanB = beanB;
  6.     }
  7. }
  • 原型（prototype）作用域：原型Bean每次请求都新建，容器不会缓存原型Bean，因此三级缓存机制对其不适用。循环依赖的原型Bean同样会报错。

四、工程实践与避坑建议

4.1 推荐做法

  • 优先使用setter或字段注入：在允许循环依赖的场景下，避免使用构造器注入。
  • 引入接口隔离：将相互依赖的逻辑抽离到第三方服务中，从设计层面消除循环依赖。
  • 利用@Lazy注解：对于非关键路径的依赖，可使用延迟加载，在首次使用时才初始化，间接缓解循环依赖问题。
  1. @Component
  2. public class BeanA {
  3.     @Lazy
  4.     @Autowired
  5.     private BeanB beanB;  // 延迟加载，不会在A实例化时立即触发B的创建
  6. }

4.2 警惕陷阱

  • 不要依赖循环依赖作为”正常设计”：虽然Spring能解决，但循环依赖往往意味着模块职责划分不清晰，长期维护成本高。
  • 多模块项目中特别注意：跨模块的Bean若存在循环引用，排查难度更大，建议在架构评审阶段规避。

五、总结

Spring通过三级缓存（singletonObjects、earlySingletonObjects、singletonFactories）与提前暴露机制，优雅地解决了单例Bean在setter/字段注入场景下的循环依赖问题。其本质是用”不完整但可用的早期引用”换取初始化流程的推进。但构造器注入和原型作用域下的循环依赖仍需开发者从设计层面主动规避。理解这一机制，不仅有助于排查启动报错，更能指导我们写出职责清晰、依赖健康的代码结构。在百度智能云等云平台的微服务实践中，合理管理Bean依赖关系同样是保障服务稳定启动的关键环节。

最热文章