Spring三级缓存解决循环依赖难题详解

Spring的三级缓存机制并非万能解药，它明确不支持构造器注入引发的循环依赖——因为构造阶段连对象都未实例化，根本无法提前暴露“半成品”，而仅对单例Bean的字段或setter注入有效，通过singletonFactories→earlySingletonObjects→singletonObjects三阶段严格时序协作实现解耦；但即便如此，原型作用域、AOP代理、手动getBean或Spring Boot 2.6+默认禁用等现实约束，仍会让缓存失效；真正值得警惕的是：频繁依赖三级缓存“兜底”循环依赖，往往暴露了架构设计的深层问题——是时候审视接口拆分、事件驱动或领域边界重构了。

Spring 三级缓存机制 **不解决构造器注入的循环依赖**，无论业务模型多复杂，只要存在 @Autowired 在构造器上且形成闭环，就会抛 BeanCurrentlyInCreationException。它只对单例 Bean 的字段注入 / setter 注入生效。

为什么构造器循环依赖一定失败？

构造器注入要求：实例化 A 的同时必须拿到 B 的完整实例；而 B 的构造器又要求 A 的完整实例 —— 二者互为前提，无法“提前暴露半成品”。三级缓存中的 singletonFactories 存的是 ObjectFactory，但构造阶段连对象都还没 new 出来，根本无法注册工厂。

• 构造器注入发生在 Bean 实例化（new）阶段，早于任何缓存写入时机
• singletonFactories 只在实例化完成、属性填充前才被写入，构造器场景跳过了这个窗口
• 哪怕你手动加 @Lazy，也仅延迟 B 的创建时机，无法绕过构造器参数必须非 null 的校验

字段注入循环依赖能走通的关键路径

以 A 和 B 字段注入为例，三级缓存协作的核心在于“错开完整生命周期”：

• A 实例化后（new A()），立刻将 () -> A 工厂塞进 singletonFactories
• A 填充属性时发现依赖 B，转而创建 B
• B 实例化后也注册工厂；填充属性时发现依赖 A，此时从 singletonFactories 拿出工厂，调用 getObject() 得到早期 A 对象，并移入 earlySingletonObjects
• B 完成初始化，放入 singletonObjects；A 继续填充，从一级缓存取到已就绪的 B

整个过程依赖三个缓存的严格时序：singletonFactories → earlySingletonObjects → singletonObjects，缺一不可。

真实项目中容易踩的坑

你以为加了 @Lazy 就万事大吉？不一定。这些情况会让三级缓存失效：

• Bean 作用域是 @Scope("prototype")：原型 Bean 不进任何一级缓存，singletonFactories 根本不参与
• A 或 B 被 AOP 代理（如 @Transactional）：代理对象生成时机可能晚于早期引用获取点，导致注入的是原始对象而非代理，引发事务/切面失效
• 使用 ApplicationContext.getBean(Class) 手动触发依赖：绕过 Spring 自动装配流程，三级缓存逻辑不会被触发
• Spring Boot 2.6+ 默认禁用循环依赖：需显式配置 spring.main.allow-circular-references=true，否则直接启动失败

真正复杂的业务模型里，循环依赖往往不是技术问题，而是设计信号 —— 当你反复琢磨怎么让三级缓存“多撑一会儿”，大概率该拆接口、引入事件或重构领域边界了。缓存只是兜底，不是解耦的替代品。

到这里，我们也就讲完了《Spring三级缓存解决循环依赖难题详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！