在团队最近一次架构评审会上关于 Spring 循环依赖的处理方式爆发了一场激烈争论。“直接用 Lazy 不就行了” 小李拍着桌子说“我上个月在订单服务里就这么干的上线一点问题没有。”“Lazy 只是绕开问题不是解决问题。” 架构师老张摇头“如果两个核心 Bean 互相依赖延迟加载会导致首次请求超时用户体验直接崩掉。”“那用 setter 注入” 小王插话“我看官方文档说构造器注入不支持循环依赖。”“但 setter 注入破坏了不可变性而且你们有没有想过——Spring 到底是怎么‘变魔术’让循环依赖成立的” 我抛出这个问题会议室瞬间安静。这场争论暴露了一个普遍误区大多数开发者知道 Spring 能处理循环依赖但很少有人真正理解其背后的三级缓存机制。更危险的是很多人误以为只要不抛错就万事大吉却忽略了 Bean 生命周期中的微妙时序问题。本文将带你深入 Spring 源码从一次错误的循环依赖实现开始逐步修正认知偏差最终揭示三级缓存的设计哲学与实战边界。需求约束为什么不能简单粗暴地禁止循环依赖在电商系统中我们有一个典型的循环依赖场景OrderService需要调用PaymentService完成支付PaymentService又需要调用OrderService查询订单状态以决定是否退款业务逻辑上这种双向调用是合理的。如果强行禁止循环依赖会导致以下问题职责拆分困难将两个强相关的服务拆成四个模块增加维护成本事务一致性风险跨服务调用难以保证本地事务原子性性能损耗原本一次本地调用变成两次远程调用因此Spring 选择支持循环依赖而非简单禁止。但这背后是有严格约束的仅支持单例作用域的 Bean仅支持setter/field 注入不支持构造器注入必须启用提前暴露引用机制即三级缓存架构设计三级缓存的演进逻辑错误方案直接实例化 属性注入最直观的想法是先创建 A再创建 B然后互相设置引用。但这样会陷入死循环// 伪代码错误示范 A a new A(); B b new B(); // 此时 A 和 B 都未完成属性注入 a.setB(b); // B 还没注入 Ab.getA() 为 null b.setA(a); // A 的 B 引用虽然有了但 B 本身未完成初始化问题在于对象创建和属性注入是两个阶段如果严格按顺序执行循环依赖必然失败。正确方案三级缓存 提前暴露引用Spring 的解法是引入“半成品”概念通过三级缓存提前暴露尚未完成属性注入的 Bean 引用一级缓存singletonObjects存放完全初始化好的 Bean二级缓存earlySingletonObjects存放已实例化但未完成属性注入的 Bean三级缓存singletonFactories存放生成早期引用的工厂函数关键流程如下创建 A 实例仅调用构造器未完成属性注入将 A 的 ObjectFactory 放入三级缓存发现 A 依赖 B开始创建 B创建 B 实例将 B 的 ObjectFactory 放入三级缓存发现 B 依赖 A从三级缓存获取 A 的早期引用此时 A 虽未完成注入但引用已存在B 完成属性注入放入一级缓存A 完成属性注入放入一级缓存这个设计巧妙地利用了引用提前暴露和延迟初始化的思想打破了创建时序的死锁。关键代码/组件源码走读我们聚焦DefaultSingletonBeanRegistry中的getSingleton方法这是三级缓存的核心入口protected Object getSingleton(String beanName, boolean allowEarlyReference) { // 1. 从一级缓存获取完整 Bean Object singletonObject this.singletonObjects.get(beanName); if (singletonObject null isSingletonCurrentlyInCreation(beanName)) { synchronized (this.singletonObjects) { // 2. 从二级缓存获取早期引用 singletonObject this.earlySingletonObjects.get(beanName); if (singletonObject null allowEarlyReference) { // 3. 从三级缓存获取 ObjectFactory 并生成早期引用 ObjectFactory? singletonFactory this.singletonFactories.get(beanName); if (singletonFactory ! null) { singletonObject singletonFactory.getObject(); this.earlySingletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName); } } } } return singletonObject; }注意allowEarlyReference参数只有在 Bean 创建过程中isSingletonCurrentlyInCreation为 true才允许获取早期引用防止外部提前访问半成品 Bean。再看doCreateBean方法中的关键片段// 将 ObjectFactory 加入三级缓存 addSingletonFactory(beanName, () - getEarlyBeanReference(beanName, mbd, bean)); // 填充属性此时可能触发对依赖 Bean 的创建从而触发三级缓存查询 populateBean(beanName, mbd, instanceWrapper); // 初始化 Bean exposedObject initializeBean(beanName, exposedObject, mbd);getEarlyBeanReference方法会处理 AOP 代理的情况如果 Bean 被 AOP 代理返回的是代理对象否则返回原始对象。这保证了循环依赖中获取的引用始终是一致的。复盘常见误区与边界条件经过这次源码走读我们总结了几个关键教训误区 1认为 Lazy 是银弹Lazy 确实能解决部分循环依赖问题但它改变了 Bean 的初始化时机。在以下场景会出问题启动时需要预热的 Bean如缓存加载依赖 Bean 的PostConstruct方法执行顺序误区 2忽视 AOP 代理的影响如果循环依赖的 Bean 被 AOP 代理必须确保获取的是同一个代理实例。Spring 通过getEarlyBeanReference保证这一点但如果手动创建代理如ProxyFactory就会破坏一致性。误区 3在构造器中调用依赖 Bean 的方法即使 Spring 解决了引用问题如果在构造器中调用b.doSomething()此时 B 可能尚未完成初始化如PostConstruct未执行导致状态不一致。边界条件原型作用域Prototype不支持循环依赖因为每次获取都是新实例构造器注入无法使用三级缓存因为构造器必须在实例化时完成参数注入多例循环依赖即使使用 setter 注入也会因多次创建实例而失败技术补丁包三级缓存机制原理通过 singletonFactories、earlySingletonObjects、singletonObjects 三级结构实现 Bean 引用提前暴露与延迟初始化。 设计动机解决单例 Bean 在 setter/field 注入场景下的循环依赖问题避免创建时序死锁。 边界条件仅适用于单例作用域不支持构造器注入AOP 代理需通过 getEarlyBeanReference 统一处理。 落地建议避免在构造器中调用依赖 Bean 方法优先使用 setter 注入处理循环依赖慎用 Lazy 替代根本解决方案。ObjectFactory 的作用原理作为三级缓存的值封装了生成早期引用的逻辑支持 AOP 代理的动态创建。 设计动机解耦 Bean 实例化与引用暴露的时机允许在属性注入前提供一致引用。 边界条件仅在 Bean 创建过程中有效外部调用 getSingleton 时 allowEarlyReference 必须为 false。 落地建议不要手动操作三级缓存理解 getEarlyBeanReference 对 AOP 的处理逻辑。循环依赖与 AOP 的交互原理通过 SmartInstantiationAwareBeanPostProcessor 在早期阶段创建代理确保循环依赖中获取的是同一代理实例。 设计动机避免因代理对象不一致导致的方法调用异常或事务失效。 边界条件手动创建代理会破坏一致性CGLIB 代理需考虑 final 方法限制。 落地建议避免在 Bean 构造器中执行依赖 Bean 的业务逻辑使用 DependsOn 显式控制初始化顺序。构造器注入的局限性原理构造器参数必须在实例化时确定无法利用三级缓存延迟注入。 设计动机强制显式声明依赖提升代码可读性与不可变性。 边界条件循环依赖场景下必须改用 setter 注入多参数构造器需注意参数顺序。 落地建议非循环依赖场景优先使用构造器注入循环依赖场景权衡不可变性与实用性。Lazy 的适用场景原理通过代理延迟 Bean 的实际初始化打破创建时序依赖。 设计动机简化循环依赖处理适用于初始化成本高或可选依赖的场景。 边界条件首次访问有性能开销PostConstruct 执行时机延后不适用于启动预热场景。 落地建议作为临时解决方案而非架构设计结合 DependsOn 控制初始化顺序监控首次请求延迟。