当前位置： 首页 > news >正文

Spring Boot循环依赖：三级缓存机制、配置方法与设计重构实战

news 2026/7/30 8:37:32

1. 项目概述：为什么我们会遇到循环依赖？

在Spring Boot项目开发中，尤其是随着业务模块不断拆分和聚合，我们经常会遇到一个经典的工程难题：Bean A依赖Bean B，而Bean B又反过来依赖Bean A。这就是所谓的“循环依赖”。很多开发者第一次遇到Spring抛出的“BeanCurrentlyInCreationException”异常时，都会感到困惑。这个异常信息通常会指向一个Bean正在创建中，但它的依赖项又需要它本身，形成了一个死锁。

实际上，Spring框架本身提供了一定的机制来处理循环依赖，但这并不意味着我们应该放任不管。Spring Boot作为Spring的“约定大于配置”的实践者，其默认配置和自动装配机制在简化开发的同时，也可能让循环依赖问题更隐蔽地出现。理解如何配置Spring Boot以允许或管理循环依赖，本质上是在理解Spring容器的Bean生命周期、依赖注入机制以及如何在工程实践中做出更合理的设计决策。

本文将从一个资深开发者的视角，深入拆解Spring Boot中循环依赖的成因、Spring的默认处理机制、如何通过配置来允许它，以及更重要的是，探讨为什么我们最终应该致力于从设计上避免它。我会结合真实的项目场景，分享配置的细节、背后的原理、遇到的坑以及排查技巧，目标是让你不仅知道怎么配，更明白为什么这么配，以及何时不应该这么配。

2. 循环依赖的根源与Spring的解决机制

2.1 循环依赖是如何产生的？

循环依赖通常是不佳设计的一个信号，但在复杂的业务系统中，有时又难以完全避免。常见的产生场景有：

  1. 双向关联的业务对象：例如，OrderService需要调用PaymentService来处理支付，而PaymentService在支付成功后需要回调OrderService来更新订单状态。如果两者都通过@Autowired相互注入，就构成了循环依赖。
  2. 事件监听器之间的调用：ServiceA发布一个事件，EventListenerB监听并处理，在处理过程中又需要调用ServiceA的某个方法，如果EventListenerB也注入了ServiceA，就可能形成循环。
  3. 配置类之间的相互引用：使用@Configuration类时，如果一个@Bean方法需要引用另一个配置类中定义的Bean，而那个配置类又反过来引用当前类的Bean，也可能导致问题。

从Spring容器的视角看，创建一个Bean（假设叫Bean A）的过程大致是：实例化（调用构造器） -> 属性填充（注入依赖） -> 初始化（执行@PostConstruct等方法）。如果在属性填充阶段，Spring发现需要注入Bean B，而Bean B又尚未创建，它就会去创建Bean B。如果创建Bean B的过程中，又需要在属性填充阶段注入Bean A，而此时Bean A正处于“正在创建”的状态（已经实例化但未完成初始化），矛盾就产生了。

2.2 Spring的默认解决方案：三级缓存

Spring框架并非对循环依赖束手无策。它通过一个精妙的“三级缓存”机制，默认支持解决单例Bean且通过属性注入（Setter注入）或字段注入（@Autowired）构成的循环依赖。理解这个机制是理解后续所有配置和问题的基础。

Spring容器内部维护了三个重要的Map，我们称之为缓存：

  • 一级缓存（singletonObjects）：存放已经完全初始化好的Bean实例。我们通过ApplicationContext.getBean()获取到的就是这里的Bean。
  • 二级缓存（earlySingletonObjects）：存放早期的Bean引用，即已经实例化（调用了构造器），但尚未完成属性填充和初始化的“半成品”Bean。
  • 三级缓存（singletonFactories）：存放Bean的工厂对象（ObjectFactory）。这个工厂能够在需要时，返回该Bean的早期引用（可能是一个代理对象）。

解决循环依赖的关键流程（以A依赖B，B依赖A为例）：

  1. 开始创建A，实例化A（调用A的构造器），然后将能够生成A早期引用的工厂放入三级缓存。
  2. 准备为A填充属性，发现需要B。于是去获取B。
  3. 开始创建B，实例化B，将B的工厂放入三级缓存。
  4. 为B填充属性，发现需要A。于是去获取A。
  5. 此时，A尚未创建完成，但在一级缓存找不到。Spring会依次检查二级和三级缓存。
  6. 在三级缓存中找到了A的工厂。调用这个工厂的getObject()方法。这个方法可能会直接返回A的原始实例，也可能返回一个A的代理对象（如果A被AOP切面代理）。然后将得到的这个“早期引用”放入二级缓存，并从三级缓存移除A的工厂。
  7. 将这个A的早期引用注入给B。B完成属性填充和初始化，变成一个完整的Bean，放入一级缓存。
  8. B创建完毕，返回给第2步。A成功获得B的完整实例，完成自己的属性填充和初始化，也变成一个完整的Bean，放入一级缓存。同时，清理二级缓存中关于A的早期引用。

注意：这个机制仅对单例Bean有效。对于原型（Prototype）作用域的Bean，Spring容器不负责其完整生命周期的管理，每次请求都创建一个新实例，因此无法解决其循环依赖，会直接抛出异常。

实操心得：很多开发者知道Spring能解决循环依赖，但不知道为什么。理解三级缓存机制，不仅能让你在遇到相关异常时快速定位，更能理解为什么构造器注入（Constructor Injection）无法被这种机制解决。因为构造器注入发生在实例化阶段，此时Bean的实例还未产生，更谈不上将工厂放入三级缓存，所以一旦构造器参数形成循环，Spring将无法处理。

3. Spring Boot中配置允许循环依赖的几种方式

Spring Boot 2.6版本是一个重要的分水岭。在这个版本之前，Spring Boot默认是允许循环依赖的。但从2.6版本开始，为了鼓励更好的设计实践，Spring Boot默认将循环依赖视为错误，并在应用启动时如果检测到就会报错终止。因此，我们的“配置”主要针对的是Spring Boot 2.6及之后的版本。

3.1 通过应用配置文件（主流方式）

这是最常用、最推荐的方式，因为它无需改动代码，且意图明确。

在application.properties中配置：

spring.main.allow-circular-references=true

在application.yml中配置：

spring: main: allow-circular-references: true

这个配置的作用是告诉Spring Boot的SpringApplication，在准备应用上下文（ApplicationContext）时，设置一个名为allowCircularReferences的标志为true。这个标志最终会影响AbstractAutowireCapableBeanFactory的行为，使其在检测到循环依赖时，不是直接抛出错误，而是尝试使用上述的三级缓存机制去解决它。

为什么推荐这种方式？

  1. 配置外置：将这种“权宜之计”的配置放在外部配置文件里，与业务代码分离，清晰表明了这是一个为了兼容或过渡而采取的临时措施。
  2. 环境可配：你可以在开发环境的配置文件中设置为true以快速启动和调试，而在生产环境的配置文件中保持为false（或不配置，即默认false），强制要求代码质量。
  3. 影响范围明确：它作用于整个Spring应用上下文，对所有Bean生效。

3.2 通过启动类编程式配置

如果你需要在代码中动态控制这个行为，可以在main方法中通过SpringApplication进行配置。

@SpringBootApplication public class MyApplication { public static void main(String[] args) { SpringApplication app = new SpringApplication(MyApplication.class); // 设置允许循环依赖 app.setAllowCircularReferences(true); app.run(args); } }

这种方式和配置文件的效果是等价的。但通常不如配置文件灵活，除非你有特殊的启动逻辑需要根据某些条件来决定是否允许循环依赖。

3.3 理解配置的局限性

设置allow-circular-references=true并不意味着你的所有循环依赖问题都能高枕无忧。它只是放开了Spring容器层面的限制，允许容器尝试去解决循环依赖。最终能否成功解决，还要取决于循环依赖的具体类型：

  • 单例Bean + 属性/Setter注入：通常可以成功解决。
  • 原型（Prototype）Bean：无论是否设置此标志，都无法解决，会抛出BeanCurrentlyInCreationException。
  • 构造器注入形成的循环依赖：无法解决。因为如前所述，在调用构造器时Bean的实例还未创建，三级缓存机制无从谈起。你会看到类似“Requested bean is currently in creation: Is there an unresolvable circular reference?”的错误。
  • 涉及@Async、@Transactional等AOP代理的复杂情况：即使允许循环依赖，也可能因为代理创建时机问题导致注入的不是预期的代理对象，进而引发功能异常（如事务不生效）。

注意事项：将这个配置设为true，相当于关闭了Spring Boot 2.6+提供的一个重要的代码质量守护机制。它可能会让潜在的设计缺陷被掩盖，直到在更复杂的情况下（如多线程、特定代理场景）才暴露出来，届时问题会更难调试。因此，这绝对应该被视为一个临时解决方案，而非永久措施。

4. 超越配置：从设计上破解循环依赖

允许循环依赖的配置是一把“双刃剑”，它解决了启动问题，但可能引入了更深层次的设计隐患。一个健康的项目应该致力于从架构和设计层面消除循环依赖。以下是一些经过实战检验的破解方法。

4.1 方法一：使用Setter/字段注入替代构造器注入（治标不治本）

这是最直接的代码改动。如果循环依赖双方都是通过构造器注入，将其改为使用@Autowired注解的字段注入或Setter方法注入，配合spring.main.allow-circular-references=true配置，通常能立即解决问题。

修改前（构造器注入，有问题）：

@Service public class ServiceA { private final ServiceB serviceB; public ServiceA(ServiceB serviceB) { // 构造器注入 this.serviceB = serviceB; } } @Service public class ServiceB { private final ServiceA serviceA; public ServiceB(ServiceA serviceA) { // 构造器注入 this.serviceA = serviceA; } }

修改后（字段注入，可被解决）：

@Service public class ServiceA { @Autowired private ServiceB serviceB; // 字段注入 } @Service public class ServiceB { @Autowired private ServiceA serviceA; // 字段注入 }

评价：这种方法能快速让应用跑起来，但没有改变循环依赖的本质。它依然是代码中的一颗“定时炸弹”，并且违背了使用final字段和构造器注入来实现不可变性和明确依赖的推荐实践。

4.2 方法二：提取公共功能到第三方面（推荐）

分析ServiceA和ServiceB相互依赖的原因，往往是因为它们有一部分共同关注的逻辑或数据。将这部分逻辑抽取到一个新的ServiceC（或CommonService）中，让A和B都依赖于C，从而打破A和B之间的直接循环。

场景：OrderService需要PaymentService来扣款，PaymentService需要OrderService来更新订单状态。重构：创建一个OrderStatusUpdateService，专门负责订单状态的更新和相关的业务逻辑（如发送通知）。PaymentService在支付成功后，调用OrderStatusUpdateService，而OrderService也注入这个服务来更新状态。这样，OrderService和PaymentService之间就不再需要直接依赖。

这种方法从根本上解决了问题，符合单一职责原则，并且通常能更好地组织代码。

4.3 方法三：使用事件驱动模型（解耦利器）

对于“做完A之后需要通知B，而B又可能反过来影响A”这类场景，事件驱动是绝佳的解决方案。Spring提供了强大的应用事件（ApplicationEvent）机制。

重构步骤：

  1. 定义事件：class PaymentSuccessEvent extends ApplicationEvent { private Order order; ... }
  2. 在PaymentService中，支付成功后发布事件：applicationEventPublisher.publishEvent(new PaymentSuccessEvent(this, order))。
  3. 让原本需要调用OrderService的EventListener来监听这个事件，并在其中执行业务逻辑。这个监听器可以注入OrderService。
  4. 移除PaymentService中对OrderService的直接依赖。

这样一来，PaymentService完全不知道OrderService的存在，它只负责发布“支付成功”这个事实。监听器负责响应这个事实并协调后续操作。两者通过事件中介，彻底解耦。

4.4 方法四：使用@Lazy注解（延迟注入）

在其中一个依赖上添加@Lazy注解，告诉Spring延迟初始化这个Bean，或者注入一个代理对象。当实际需要调用这个Bean的方法时，代理才会去触发真正的Bean创建和依赖解析，此时第一个Bean可能已经初始化完成，从而打破循环。

@Service public class ServiceA { private final ServiceB serviceB; public ServiceA(@Lazy ServiceB serviceB) { // 对ServiceB使用@Lazy this.serviceB = serviceB; } } @Service public class ServiceB { private final ServiceA serviceA; public ServiceB(ServiceA serviceA) { this.serviceA = serviceA; } }

在这个例子中，创建ServiceA时，由于ServiceB被标记为@Lazy，Spring会先注入一个ServiceB的代理对象给ServiceA，而不是立即去创建ServiceB。因此ServiceA可以顺利完成实例化和初始化。当ServiceA初始化完成后，ServiceB再被创建时，就能成功注入已经就绪的ServiceA。

实操心得：@Lazy是一个很有用的工具，但它会引入代理，可能会对调试（栈信息变复杂）和某些基于类型匹配的功能（如@Autowired按类型注入）产生细微影响。它更适合用于解决因特定Bean初始化顺序或成本过高导致的依赖问题，而非作为解决循环依赖的常规手段。

4.5 方法五：使用ObjectProvider或Provider进行延迟查找

ObjectProvider（Spring 4.3+）或JSR-330的Provider接口，允许你延迟获取Bean实例，而不是在注入时就立即解析。

@Service public class ServiceA { private final ObjectProvider<ServiceB> serviceBProvider; public ServiceA(ObjectProvider<ServiceB> serviceBProvider) { this.serviceBProvider = serviceBProvider; } public void someMethod() { ServiceB serviceB = serviceBProvider.getIfUnique(); // 在需要时才获取 // 使用serviceB } } @Service public class ServiceB { private final ServiceA serviceA; public ServiceB(ServiceA serviceA) { this.serviceA = serviceA; } }

这种方式将依赖的获取从构造阶段推迟到了运行时的方法调用阶段，从而打破了创建时的循环。它比@Lazy更显式，让你对Bean的获取有更强的控制力（例如getIfAvailable,getObject()等）。

5. 常见问题排查与调试技巧实录

即使配置了允许循环依赖，在实际开发中你仍可能遇到各种诡异的问题。下面是我在多年项目中积累的一些排查经验和技巧。

5.1 启动时报错：BeanCurrentlyInCreationException

这是最经典的错误。排查步骤：

  1. 确认Spring Boot版本：首先检查是否是Spring Boot 2.6+且未配置spring.main.allow-circular-references=true。这是最常见的原因。
  2. 分析错误堆栈：错误信息通常会给出形成循环的Bean名称链，例如“Error creating bean with name ‘a’: Requested bean is currently in creation: Is there an unresolvable circular reference with ‘b’?”。顺着这个链就能找到罪魁祸首。
  3. 检查注入方式：如果错误链中的Bean都是构造器注入，那么即使允许循环依赖也无济于事。必须改为Setter/字段注入，或者采用@Lazy、ObjectProvider等方案。
  4. 检查Bean的作用域：确认涉及的Bean都是单例（@Scope(“singleton”)，默认即是）。原型Bean的循环依赖无法解决。

5.2 配置了allow-circular-references=true但依然报错

这种情况需要深入分析。

  1. 原型Bean的循环依赖：如前所述，此配置对原型Bean无效。
  2. 涉及AOP代理的复杂循环：如果Bean被@Async、@Transactional、@Cacheable等注解代理，Spring需要先创建代理对象。在复杂的循环依赖场景下，代理的创建时机可能导致依赖注入混乱。可以尝试调整切面顺序或检查代理模式（CGLIB vs. JDK动态代理）。
  3. 生命周期回调中的依赖：在@PostConstruct方法中调用另一个Bean，而那个Bean又反过来依赖当前Bean，也可能在允许循环依赖的配置下出现问题，因为@PostConstruct执行时，Bean的早期引用可能已经被使用。
  4. 使用@DependsOn注解：这个注解显式定义了Bean的初始化顺序，如果配置不当，可能会与容器解决循环依赖的自动顺序产生冲突，引发意想不到的错误。

5.3 运行时出现空指针或功能异常

应用启动了，没有报循环依赖错误，但运行时调用某个方法却抛出NullPointerException，或者@Transactional不生效。这很可能是依赖注入成功了，但注入的对象并不是你期望的那个。

  1. @Lazy注入的代理对象未初始化：如果你使用了@Lazy，并且注入的是接口类型，Spring可能会注入一个代理。在调用该代理的方法前，真正的目标对象可能还未被初始化。确保你在调用前，该Bean已经被容器初始化（通常第一次调用其方法时会触发）。
  2. AOP代理对象问题：在允许循环依赖的情况下，如果A和B相互依赖且都被AOP代理，Spring在解决循环依赖时，注入的可能是原始对象的早期引用，而不是最终的代理对象。这会导致后续的AOP增强（如事务）失效。这种情况比较复杂，通常需要重构设计来避免。
  3. 多例（原型）Bean注入单例Bean：这不是循环依赖问题，但症状类似。单例Bean中注入了一个原型Bean，你期望每次调用都获得新实例，但实际上Spring只在单例Bean初始化时注入一次原型Bean。这需要使用@Lookup方法或ObjectProvider来解决。

5.4 实用调试技巧

  1. 开启Spring Debug日志：在application.yml中添加logging.level.org.springframework.beans.factory.support=DEBUG。这会输出非常详细的Bean创建、依赖解析日志，你可以清晰地看到每个Bean的创建步骤和它正在寻找的依赖，是追踪循环依赖路径的终极武器。日志量会很大，建议在复现问题时临时开启。
  2. 使用IDE的Diagram工具：IntelliJ IDEA Ultimate等IDE可以生成Spring Bean的依赖关系图，直观地展示Bean之间的依赖关系，帮助你快速发现循环。
  3. 编写单元测试隔离：为相互依赖的Service编写集成测试，在测试环境中启动相关的Bean，观察启动和调用过程，比在全应用启动时调试更容易定位问题。
  4. 分步重构：当遇到一个复杂的循环依赖网时，不要试图一次性重构完。可以先用@Lazy或allow-circular-references=true让应用先跑起来，然后逐个分析依赖关系，优先重构最核心、最简单的循环，一步步将网状结构梳理成清晰的层次结构。

6. 项目实践中的决策与权衡

经过上述分析，我们应该形成一个清晰的决策路径：

  1. 遇到循环依赖错误，第一步做什么？

    • 如果是Spring Boot 2.6+，首先检查是否配置了spring.main.allow-circular-references=true。如果没有，加上它看能否启动。但这只是获得一个调试机会，不是最终方案。

  2. 应用能启动后，第二步做什么？

    • 立即分析产生循环依赖的代码。使用上文提到的“提取公共功能”、“事件驱动”等方法，制定一个重构计划。目标是彻底消除循环依赖。

  3. 何时可以保留allow-circular-references=true？

    • 遗留系统迁移：在将一个老系统迁移到Spring Boot 2.6+时，可能暂时无法修改所有代码，可以短期开启此配置作为过渡。
    • 第三方库的兼容性问题：极少数情况下，某些第三方库的自动配置可能无意中引入了循环依赖，而你无法修改其源码。
    • 开发/测试环境：为了不阻塞开发进度，可以在开发环境配置中开启，方便快速验证功能。但CI/CD流水线和生产环境必须关闭，将其作为代码质量门禁。

  4. 设计阶段如何预防？

    • 优先使用构造器注入：这能强制你在编码阶段就发现循环依赖，因为构造器注入的循环依赖无法被Spring默认机制解决，会立刻报错。
    • 遵循分层架构：严格遵循Controller -> Service -> Repository/Mapper的调用方向，禁止下层直接调用上层。
    • 模块化与接口隔离：定义清晰的接口，通过接口进行通信，降低模块间的耦合度。
    • 定期进行架构评审：使用工具分析项目依赖，及时发现并讨论新引入的循环依赖。

循环依赖就像代码中的“技术债”，允许循环依赖的配置就像是申请了一笔“高息贷款”，它能让你暂时渡过难关，但长期不还会拖垮整个项目。一个优秀的开发者，应该具备在“快速解决问题”和“构建稳健架构”之间做出明智权衡的能力。希望本文的深度拆解，能让你不仅掌握Spring Boot中处理循环依赖的“术”，更能理解其背后的“道”，从而写出更清晰、更健壮、更易于维护的代码。

http://www.jsqmd.com/news/1292659/

相关文章：

  • 一步一步学习使用LiveBindings（）TListView进阶使用（），创建自定义的列表项打造天气预报程序
  • 2026年如何甄选有实力的农业四情监测系统土壤墒情监测站生产厂家？这份优选指南请收好 - geo交流
  • 以前的关键词研究问的是“这个词有多少人搜“。2026年该问的是——“搜这个词的人，他做完搜索之后做了什么事。“
  • C++课程设计实战：图书信息管理系统开发全解析
  • AI 赋能，东软添翼领跑三级医院数智未来
  • 看完不踩坑！电脑看图软件最全选型攻略
  • Palworld存档工具终极指南：三步实现.sav与JSON双向免费转换
  • 单机部署私有大模型：硬件选型与优化实践
  • 介观尺度电子输运：有效质量与态密度的计算与应用
  • Excel VBA批量套打实战：从数据到打印的自动化解决方案
  • STM32特殊引脚复用实战：释放SWD/JTAG引脚作GPIO的完整指南
  • 2026年嘉兴新型手持气象仪产品怎么选？这份甄选指南帮你精准避坑 - geo交流
  • 2026枣阳市瓷砖空鼓如何妥善处理？地砖墙砖松动微创注浆修复实操方案｜本地专业修缮服务科普 - 宅安选房屋修缮
  • 2026为何国产私有化智能体平台比OpenClaw更安全？企业级OpenClaw定制化平替厂商盘点
  • 直线模组运行不顺畅怎么办？
  • 纯代数推导：步进电机电气角度与机械角度的通用关系
  • 如何安全合规地使用B站视频下载工具：DownKyi的终极完整指南与法律风险防范
  • FDE为何成为AI领域新宠？技术人如何把握落地红利
  • 华东供应链直播基地是什么？和壹亿共创什么关系
  • 2026年茂名耐用的EL检测仪供应商怎么选？这份优选指南帮你避开选型雷区 - geo交流
  • 2026年如何甄选达标排放的废气焚烧稳定运行系统技术方案？ - geo交流
  • Jupyter Notebook中执行Shell命令的三种方法与实践指南
  • PyCharm 安装与使用
  • B站视频转文字终极指南：开源神器bili2text完整教程
  • 液压挖掘机工作装置设计：从四连杆机构原理到UG三维建模实践
  • Android开发转型指南：从XML到Jetpack Compose的实战进阶
  • 基于拓扑排序的依赖任务调度算法研究7
  • AD2s1205旋变解码芯片实战：从硬件设计到软件配置全解析
  • gif压缩免费：投稿系统卡体积时，手机与电脑怎么对照压 - AI测评专家
  • 7款大模型100个ETL任务实测：谁真正能跑起来