深度剖析Spring循环依赖：@Async为何打破三级缓存机制

作者：热心市民鹿先生2026.11.07 02:03浏览量：0

简介：本文深度解析Spring框架循环依赖的解决机制，重点探讨三级缓存的设计原理。通过剖析@Async注解引发的BeanCurrentlyInCreationException异常，揭示异步代理提前暴露导致的类型冲突根源，并提供工程级的规避方案与架构优化建议，助力开发者构建更稳健的微服务系统。

引言：从一次典型的启动报错说起

在构建复杂的微服务系统或大型企业级应用时，组件之间的相互依赖是不可避免的。有时，为了业务逻辑的内聚，两个服务组件可能会互相注入对方的实例，这就构成了所谓的“循环依赖”。在设计优雅的架构时，我们通常会尽量避免这种情况，但在某些历史遗留系统或快速迭代的业务场景中，它依然时有发生。

通常情况下，我们依赖的基础开发框架能够自动处理通过属性注入构成的循环依赖。然而，当我们在某个方法上加入异步处理注解时，原本平静的系统可能会在启动瞬间抛出异常。

一、 异常复现：当循环依赖遇上异步处理

为了更好地剖析底层机制，我们首先构建一个最小化的问题模型。假设系统中存在两个核心业务组件：订单服务与库存服务。订单服务在初始化时需要库存服务来校验库存，而库存服务在某些反向查询场景下也需要订单服务的数据。代码结构如下：

  1. @Service
  2. public class OrderService {
  3.     @Autowired
  4.     private InventoryService inventoryService;
  6.     @Async
  7.     public void processOrderAsync() {
  8.         // 异步处理订单逻辑
  9.     }
  10. }
  12. @Service
  13. public class InventoryService {
  14.     @Autowired
  15.     private OrderService orderService;
  17.     public void checkStock() {
  18.         // 库存校验逻辑
  19.     }
  20. }

在这段代码中，OrderService 和 InventoryService 相互注入，构成了循环依赖。同时，OrderService 的 processOrderAsync 方法上使用了 @Async 注解，意图将其放入异步线程池中执行。

启动上述项目，控制台会立刻抛出如下致命异常：

  1. org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'orderService': Bean with name 'orderService' has been injected into other beans [inventoryService] in its raw version as part of a circular reference, but has eventually been wrapped.

异常信息明确指出：orderService 在作为循环引用的一部分以“原始版本”注入到其他 Bean 后，最终被“包装”了。这意味着引用它的其他 Bean 使用的并非最终版本的 Bean。

二、 核心机制：三级缓存如何化解常规循环依赖

要理解上述异常为何发生，必须先透彻理解常规情况下的循环依赖是如何被化解的。框架内部引入了著名的“三级缓存”机制，通过提前暴露半成品的 Bean 实例来打破死循环。这三级缓存分别扮演着不同的角色：

  1. 一级缓存
    这是单例池，存放的是经历了完整生命周期、已经初始化完毕的成品 Bean。日常通过 getBean 获取到的就是这里的实例。

  2. 二级缓存
    存放的是早期的半成品 Bean。这些 Bean 已经实例化（调用了构造方法），但尚未完成属性注入和初始化。它的主要作用是在循环依赖发生时，提供尚未完工的实例引用。

  3. 三级缓存
    这是最关键的一环，存放的是 Bean 工厂。它是一个 ObjectFactory，本质上是一个提供了获取早期 Bean 引用的回调函数。

当一个 ServiceA 依赖 ServiceB，而 ServiceB 又反过来依赖 ServiceA 时，执行流程如下：

  1. 框架开始创建 ServiceA，首先调用其构造方法实例化一个“早期对象”。
  2. 框架将这个能够生成早期对象的 ObjectFactory 放入三级缓存。
  3. 框架准备为 ServiceA 注入属性，发现需要 ServiceB，于是去创建 ServiceB。
  4. 在创建 ServiceB 的过程中，发现 B 需要 ServiceA。此时 B 去缓存中寻找 A。
  5. B 在一级缓存找不到 A，在二级缓存也找不到，但在三级缓存中找到了 A 对应的 ObjectFactory。
  6. B 通过调用三级缓存中的工厂方法，拿到了 A 的早期引用，并将这个早期引用放入二级缓存，同时从三级缓存中移除。
  7. B 拿着 A 的早期引用完成了自身的属性注入和初始化，将自己放入一级缓存。
  8. 流程回到 A，A 成功拿到了完成的 B，完成了自身的属性注入，随后 A 也完成初始化进入一级缓存。

这套机制巧妙地利用了 Java 的引用传递特性，即便 A 还没完全初始化，B 持有它的早期引用，等 A 彻底完工后，B 内部的引用自然也就指向了完整的 A。

三、 破局点分析：@Async 注解引发的代理错位

既然三级缓存机制如此强大，为何加上 @Async 注解后就彻底失效了呢？问题的核心在于 AOP（面向切面编程）与早期暴露机制的冲突。

  1. 代理对象的生成时机
    @Async 注解的核心原理是 AOP 动态代理。为了让方法在独立线程中执行，框架必须创建一个目标类的代理对象，在代理对象中拦截方法调用，将其提交到异步线程池。
    正常情况下，代理对象的生成是在 Bean 生命周期的最后阶段——即“初始化后”阶段完成的。

  2. 三级缓存的早期暴露逻辑
    回到之前的流程，当 B 通过三级缓存的 ObjectFactory 获取 A 的早期引用时，框架会进行一次判断：如果 A 需要 AOP 代理，那么此时就会提前生成 A 的代理对象，并将其暴露给 B。

  3. 灾难性的双重代理
    当循环依赖遭遇 @Async 时，情况变得异常复杂。我们梳理 OrderService (A) 和 InventoryService (B) 的交织过程：

  • 框架创建 OrderService，将其早期工厂放入三级缓存。
  • OrderService 尝试注入 InventoryService，触发 InventoryService 的创建。
  • InventoryService 尝试注入 OrderService，去缓存中寻找。
  • 框架发现 OrderService 需要 AOP 代理（假设因为有其他普通切面存在），于是通过三级缓存提前生成了 OrderService 的代理对象，放入二级缓存并交给 InventoryService。
  • InventoryService 完成创建，进入一级缓存。
  • 流程回到 OrderService，它继续走完初始化流程。在最后的“初始化后”阶段，由于 @Async 注解的存在，框架再次对 OrderService 进行切面增强，生成了一个新的代理对象。
  1. 异常的底层根源
    此时，系统内部出现了两个 OrderService 的代理对象：一个是早期为了满足 InventoryService 而临时生成的，另一个是最终因为 @Async 生成的。框架在最后进行状态检查时敏锐地发现：InventoryService 内部持有的 OrderService 并非当前最终版本的代理对象（因为它缺少了异步增强的逻辑）。为了保证应用的严谨性，防止在没有异步特性的代理上执行同步阻塞调用，框架直接抛出 BeanCurrentlyInCreationException，拒绝启动。

四、 避坑指南：异步循环依赖的破局方案

针对上述由于异步注解引起的循环依赖崩溃，在实际工程开发中，我们可以采取以下几种可靠的策略进行规避和重构。

  1. 推迟异步代理的执行
    既然在 Bean 初始化阶段相互注入会导致代理对象错位，最简单的解法是将异步方法的调用剥离出循环依赖的链路。可以通过依赖查找的方式，在真正执行业务方法时再去获取目标组件。
    将 @Autowired 注入改为通过 ApplicationContextAware 接口注入上下文，在方法内部使用 context.getBean() 动态获取对方实例。这样打破了初始化期的强依赖，使得两个 Bean 都能完整走完生命周期。

  2. 使用 @Lazy 懒加载注解
    在相互注入的字段上添加 @Lazy 注解。这意味着框架在启动时不会立刻要求注入真实的 Bean 实例，而是注入一个代理对象。只有当真正调用该对象的方法时，才会去容器中获取真实的 Bean。这种方式延迟了依赖的解析时机，有效规避了早期暴露带来的冲突。

  3. 引入中间层解耦
    这是架构层面最彻底的解决方案。如果两个组件存在深度的双向交互，说明它们之间的边界划分不够清晰。应该引入第三个中间组件来协调它们。例如，创建一个 EventDispatcher 或者 CoordinatorService。OrderService 和 InventoryService 都依赖这个中间件，通过事件驱动或协调者模式进行通信，从而彻底消除双向的循环依赖。

五、 架构层面的反思与最佳实践

解决技术 Bug 只是第一步，作为资深开发者，更应该从异常中反思架构设计的健壮性。在微服务架构中，无论是内部组件还是接入如对象存储、消息队列等云通用产品组件，都应遵循单一职责原则。

循环依赖往往是领域模型划分不合理的信号。当两个类互相需要对方才能工作时，通常意味着有一块共享的逻辑没有被正确抽取。在日常代码审查中，一旦发现循环依赖的苗头，不应仅仅依赖框架的缓存兜底机制，而应主动重构，将相互依赖的逻辑下沉为一个独立的第三方服务类。

此外，对于异步机制的使用，@Async 虽然方便，但它模糊了方法的调用边界，在复杂的依赖网中极易引发难以排查的并发和代理问题。在高并发要求的场景下，建议采用成熟的行业常见技术方案，如显式的消息队列解耦、事件总线架构等，这比单纯的注解异步更加可控，也更容易与日志服务、监控告警等基础设施集成。

总结

基础框架的三级缓存机制通过提前暴露半成品引用，精妙地化解了常规的循环依赖死锁。然而，当 @Async 等 AOP 增强手段介入时，由于代理对象的多次生成与版本不一致，三级缓存机制便会失效并抛出异常。作为开发者，理解底层 Bean 的生命周期与缓存机制，不仅能帮助我们快速定位此类疑难杂症，更能促使我们在架构设计时遵循低耦合、高内聚的原则，从根源上消除破坏性的依赖循环，构建出更加稳健的分布式系统。

最热文章