Spring循环依赖：为什么原型Bean和构造器依赖无解？三级缓存又为何而生？

一、什么是循环依赖一个“先有鸡还是先有蛋”的编程难题想象一下这个场景小明说“我的工作依赖小红完成的数据。”小红说“不行我得等小明先把框架搭好我才能开始处理数据。”两人互相等待工作永远无法开始——这就是现实中的“循环依赖”。简单来说就是A依赖B,B又依赖A。在Spring框架中循环依赖指的是两个或多个BeanSpring管理的对象在创建时相互依赖形成一个闭环。比如Service public class ServiceA { Autowired private ServiceB serviceB; // A依赖B } Service public class ServiceB { Autowired private ServiceA serviceA; // B又依赖A }Spring要创建ServiceA发现它需要ServiceB去创建ServiceB发现它又需要ServiceA……陷入死循环。二、循环依赖解决办法Spring通过三级缓存巧妙地解决了单例Bean通过Setter/Field注入的循环依赖问题。先看这个经典的生活比喻2.1 三级缓存是什么你可以把Spring容器想象成一个房屋建造公司它有三个“仓库”缓存级别仓库名称存放内容类比现实一级缓存singletonObjects完全初始化好的Bean完成实例化且初始化的对象装修完毕、可以入住的房子二级缓存earlySingletonObjects提前暴露的早期引用半成品完成实例化但未初始化的对象刚搭好框架、没装修的毛坯房三级缓存singletonFactories创建Bean的工厂对象房屋设计图纸施工队2.2 解决循环依赖的完整流程以A→B→A为例开始创建ASpring发现需要创建ServiceA先把它标记为“创建中”然后把A的工厂放入三级缓存存图纸。A依赖B开始填充A的属性发现需要ServiceB。转去创建B同样标记B为“创建中”把B的工厂放入三级缓存。B依赖A填充B的属性时发现需要ServiceA。关键一步Spring去缓存找A一级缓存成品房→ 没有二级缓存毛坯房→ 没有三级缓存图纸→ 找到A的工厂工厂执行生成A的早期引用一个代理对象或原始对象放入二级缓存并从三级缓存移除工厂。B完成创建B拿到了A的早期引用属性填充成功B创建完成放入一级缓存。A完成创建回到A的创建流程现在能拿到完整的B了A也创建完成放入一级缓存。整个过程就像两个施工队互相借用对方的“框架”先让房子能立起来再慢慢完善内部装修。三、为什么有些循环依赖Spring也无能为力3.1 原型BeanPrototype的循环依赖为什么不能解决根本原因原型Bean每次获取都是新实例Spring不缓存它们。想象一下单例Bean全村共用一口井缓存起来大家引用同一个原型Bean每家自己打一口新井每次getBean都新建当A原型依赖B原型时创建A1 → 需要B创建B1 → 需要A → 创建A2因为原型要新建A2又需要B → 创建B2 → 需要A → 创建A3……无限套娃直到栈溢出。Spring检测到这种场景会直接抛出BeanCurrentlyInCreationException。3.2 构造器注入的循环依赖为什么不能解决根本原因对象在构造完成前连“早期引用”都无法提供。Service public class ServiceA { private final ServiceB serviceB; // 构造器注入创建A的瞬间就必须有完整的B public ServiceA(ServiceB serviceB) { this.serviceB serviceB; } } Service public class ServiceB { private final ServiceA serviceA; public ServiceB(ServiceA serviceA) { this.serviceA serviceA; } }问题在于Setter/Field注入可以先创建对象实例调用默认构造器得到一个“空壳子”再慢慢填充属性。构造器注入必须在构造函数里就传入完整的依赖对象对象在诞生那一刻就必须是“完整的”。这就好比Setter注入先造出汽车框架再安装发动机、轮胎。构造器注入要求发动机、轮胎在汽车框架诞生前就必须准备好——但发动机又需要汽车框架才能造出来。Spring在创建A时连A的实例都还没产生构造函数没执行自然无法提供A的早期引用给B使用。如果想解决的话可以在构造器方法的参数上添加lazy注解延迟生成依赖的代理对象先完成实例化操作。四、深入思考二级缓存够用吗为什么需要三级4.1 如果只有二级缓存会怎样假设Spring只有一级缓存成品和二级缓存半成品// 伪代码逻辑 Object getBean(String name) { // 1. 从一级缓存找成品 Object bean singletonObjects.get(name); if (bean ! null) return bean; // 2. 从二级缓存找半成品 bean earlySingletonObjects.get(name); if (bean ! null) return bean; // 3. 创建新Bean bean createBean(name); // 创建后直接放入二级缓存 earlySingletonObjects.put(name, bean); // 填充属性可能触发循环依赖 populateBean(bean); // 初始化完成从二级缓存移除放入一级缓存 earlySingletonObjects.remove(name); singletonObjects.put(name, bean); return bean; }问题如果Bean需要AOP代理怎么办Spring AOP会在Bean初始化后生成代理对象替换原始对象。如果只有二级缓存A创建半成品放入二级缓存原始对象B依赖A从二级缓存拿到A的原始对象B创建完成A继续初始化被AOP增强生成代理对象结果B持有的是A的原始对象A最终是代理对象 →不一致4.2 三级缓存如何解决代理问题三级缓存存放的不是Bean实例而是ObjectFactory工厂。这个工厂的聪明之处在于延迟决策只有在真正被其他Bean依赖时才决定返回原始对象还是代理对象。保证一致性所有依赖方通过同一个工厂获取引用拿到的是同一个对象要么都是原始对象要么都是代理对象。// 三级缓存的核心逻辑 addSingletonFactory(beanName, () - { // 这个lambda在需要时才执行 Object earlyReference getEarlyBeanReference(beanName, bean); // 这里会判断是否需要AOP代理 return earlyReference; });关键优势解决代理一致性问题工厂在第一次被调用时如果发现Bean需要代理就生成代理对象否则返回原始对象。之后所有依赖方都拿到同一个引用。避免不必要的代理创建如果Bean没有被循环依赖工厂永远不会执行节省了创建代理的开销。处理复杂的代理逻辑支持Async、Transactional等基于代理的增强。五、面试官想听到的“点睛之笔”当面试官问“为什么用三级缓存而不是二级”时你可以这样回答“Spring设计三级缓存主要是为了优雅地处理AOP代理与循环依赖的兼容问题。二级缓存只能存储Bean的早期引用但无法处理这个引用应该是原始对象还是代理对象的‘决策延迟’问题。三级缓存通过ObjectFactory实现了‘用时才决策’的机制既保证了循环依赖中的对象一致性又避免了不必要的代理创建开销。”六、实际开发中的最佳实践优先使用构造器注入Lombok的RequiredArgsConstructor让循环依赖在编译期就暴露。避免循环依赖这是架构设计问题而不是技术炫技点。如果确实需要循环依赖使用Lazy延迟加载打破僵局Autowired Lazy private ServiceB serviceB;考虑使用事件驱动或观察者模式解耦相互调用的Bean。七、总结循环依赖Bean间相互等待创建的“死锁”问题。三级缓存Spring解决单例Setter注入循环依赖的“破局钥匙”。原型Bean无解因为不缓存每次都是新对象无限递归。构造器注入无解对象在诞生前无法提供引用。为什么是三级不是二级为了处理AOP代理的“决策延迟”和引用一致性。记住能解决循环依赖是Spring的“宽容”而不是鼓励你写出循环依赖的代码。良好的设计应该避免这种结构性问题。