Spring循环依赖与三级缓存:从原理到实战,彻底搞懂不踩坑
“Bean正在创建中存在无法解决的循环引用”——这就是Spring循环依赖的典型表现。很多人只知道“用Lazy注解能解决”“改Set注入就行”但背后的三级缓存机制却一知半解。一、什么是Spring循环依赖循环依赖本质就是两个或多个Bean之间形成了“你依赖我、我依赖你”的闭环导致Spring容器无法确定初始化顺序陷入死循环。举个最常见的例子真实开发中高频出现// 订单服务ServicepublicclassOrderService{// 依赖用户服务AutowiredprivateUserServiceuserService;}// 用户服务ServicepublicclassUserService{// 依赖订单服务形成闭环AutowiredprivateOrderServiceorderService;}除了这种“双向依赖”还有更复杂的“多Bean闭环”A→B→C→A以及少见的“自依赖”Bean自身依赖自身本质都是一样的——依赖链形成了环。这里要先澄清一个误区循环依赖本身不是Spring的Bug而是代码设计中可能出现的依赖关系Spring只是提供了兜底解决方案三级缓存但并非所有循环依赖都能解决。二、Spring三级缓存到底是什么Spring解决单例Bean循环依赖的核心就是「三级缓存」——本质是三个存储Bean的Map在DefaultSingletonBeanRegistry类中定义作用是“提前暴露未完全初始化的Bean”打破依赖闭环。先上一张核心总结表一目了然缓存级别缓存名称源码字段存储内容核心作用一级缓存singletonObjects完全初始化完成的单例Bean供程序直接获取是最终可用的Bean二级缓存earlySingletonObjects已实例化、但未完成属性注入和初始化的“半成品”Bean或其代理对象临时存储早期Bean避免重复创建解决循环依赖三级缓存singletonFactoriesObjectFactory对象工厂用于生成Bean的早期引用可能是原始对象也可能是AOP代理对象延迟创建代理对象兼顾AOP和循环依赖避免破坏Bean生命周期补充说明三个缓存的优先级是「一级缓存 二级缓存 三级缓存」Spring获取Bean时会先从一级缓存找找不到再找二级最后才会触发三级缓存的工厂创建。为什么需要三级缓存两级缓存不够吗答案核心和AOP有关Spring的AOP代理默认是在Bean“完全初始化后”初始化阶段的后置处理器创建的。如果只用两级缓存就必须在Bean实例化后立即创建代理对象无论这个Bean是否有循环依赖——这会破坏Spring Bean的生命周期设计还会增加不必要的代理开销。三级缓存的精妙之处就是“延迟决策”只有当Bean发生循环依赖时才会调用ObjectFactory创建代理对象或原始对象放入二级缓存如果没有循环依赖就按正常生命周期走在最后一步创建代理对象完美兼顾了AOP和循环依赖。三、Spring如何用三级缓存破解循环依赖结合前面的OrderService和UserService双向依赖案例拆解Spring的执行流程步骤1初始化OrderService放入三级缓存Spring容器启动开始初始化OrderService单例Bean先调用OrderService的构造方法完成「实例化」此时OrderService是个“空壳”属性userService还未注入创建一个ObjectFactory对象放入三级缓存singletonFactories这个工厂的作用是当需要时返回OrderService的早期引用如果需要AOP代理就返回代理对象否则返回原始实例开始给OrderService填充属性发现需要注入UserService——此时UserService还未创建Spring转而初始化UserService。步骤2初始化UserService触发循环依赖使用三级缓存调用UserService的构造方法完成实例化同样创建ObjectFactory放入三级缓存给UserService填充属性发现需要注入OrderService——此时Spring去缓存中找OrderService一级缓存singletonObjects没有OrderService未完全初始化二级缓存earlySingletonObjects也没有最后找到三级缓存singletonFactories中的OrderService工厂调用OrderService的ObjectFactory获取到OrderService的早期引用半成品并将这个引用放入二级缓存同时删除三级缓存中的OrderService工厂避免重复创建UserService注入OrderService的早期引用完成属性填充和自身初始化成为“成品Bean”放入一级缓存singletonObjects。步骤3完成OrderService初始化闭环破解回到OrderService的属性注入步骤此时UserService已经在一级缓存中直接从一级缓存获取UserService并注入OrderService完成属性填充和初始化成为成品Bean放入一级缓存删除二级缓存中OrderService的早期引用三级缓存中已无相关工厂整个流程结束。核心总结三级缓存的核心是「提前暴露半成品Bean」通过ObjectFactory延迟处理AOP代理让两个循环依赖的Bean都能完成初始化打破“你等我、我等你”的死循环。四、哪些循环依赖Spring解决不了别以为三级缓存是“万能的”Spring只能解决「单例Bean Setter注入/字段注入」的循环依赖以下3种场景三级缓存也无能为力会直接抛出异常1. 构造器注入的循环依赖最常见坑如果两个Bean通过构造器相互注入Spring无法解决——因为构造器注入发生在「实例化阶段」此时Bean还未创建无法提前暴露到三级缓存。// 错误示例构造器注入循环依赖启动报错ServicepublicclassOrderService{privatefinalUserServiceuserService;// 构造器注入AutowiredpublicOrderService(UserServiceuserService){this.userServiceuserService;}}ServicepublicclassUserService{privatefinalOrderServiceorderService;// 构造器注入形成闭环AutowiredpublicUserService(OrderServiceorderService){this.orderServiceorderService;}}2. 原型PrototypeBean的循环依赖原型Bean的特点是「每次获取都创建新实例」不参与任何级别的缓存——循环依赖时会不断创建新的Bean实例最终导致栈溢出Spring直接不处理。3. 混合作用域的循环依赖比如「单例Bean A → 原型Bean B → 单例Bean A」这种场景下原型Bean B每次创建都需要注入单例Bean A看似可行但Spring无法保证原型Bean的依赖注入一致性同样无法解决。五、循环依赖的4种解决方案1. 重构代码循环依赖本质是代码设计不合理出现了“双向耦合”。最彻底的方式是重构将公共逻辑提取到新的Bean打破依赖闭环。比如前面的OrderService和UserService可提取一个CommonService将两者共有的逻辑放入让两个服务都依赖CommonService而非互相依赖// 提取公共服务ServicepublicclassCommonService{// 公共逻辑publicvoidcommonMethod(){// ...}}// 订单服务依赖CommonService不再依赖UserServiceServicepublicclassOrderService{AutowiredprivateCommonServicecommonService;}// 用户服务依赖CommonService不再依赖OrderServiceServicepublicclassUserService{AutowiredprivateCommonServicecommonService;}2. 使用Lazy注解快速解决改动最小在循环依赖的Bean注入处添加Lazy注解实现“延迟加载”——Spring会创建一个代理对象暂时替代目标Bean直到第一次使用时才真正初始化打破循环。ServicepublicclassOrderService{// 给依赖的UserService添加LazyAutowiredLazyprivateUserServiceuserService;}ServicepublicclassUserService{AutowiredprivateOrderServiceorderService;}3. 改用Setter注入兼容构造器注入场景如果必须用构造器注入可将其中一个Bean的依赖改为Setter注入让Spring能提前暴露半成品Bean配合三级缓存解决循环依赖ServicepublicclassOrderService{privateUserServiceuserService;// Setter注入AutowiredpublicvoidsetUserService(UserServiceuserService){this.userServiceuserService;}}ServicepublicclassUserService{// 构造器注入privatefinalOrderServiceorderService;AutowiredpublicUserService(OrderServiceorderService){this.orderServiceorderService;}}4. 临时启用循环引用不推荐紧急兜底Spring Boot 2.6 默认禁止循环引用可通过配置临时启用仅用于紧急修复长期使用会隐藏代码设计问题# application.yamlspring:main:allow-circular-references:true# 临时允许循环引用总结Spring循环依赖与三级缓存核心逻辑可以浓缩为一句话用三级缓存提前暴露单例Bean的半成品引用通过ObjectFactory兼顾AOP代理和Bean生命周期最终破解“单例Setter注入”的循环依赖。实战中优先通过重构代码从根源解决循环依赖其次用Lazy或Setter注入快速兜底尽量避免依赖临时配置。记住三级缓存是Spring的“兜底方案”不是“推荐方案”——好的代码设计应该从一开始就避免循环依赖。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2629940.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!