Spring三级缓存解决单例Bean属性注入循环依赖，核心是提前暴露未初始化Bean引用：一级缓存存成品Bean，二级缓存存半成品实例，三级缓存存ObjectFactory工厂以延迟生成代理对象，确保AOP一致性；不支持构造器注入和原型Bean循环依赖。
Spring 通过三级缓存解决单例 Bean 的属性注入型循环依赖，核心在于“提前暴露未初始化完成的 Bean 引用”，打破创建过程中的死锁闭环。它不靠强行创建完整对象，而是利用 Java 对象引用的特性——只要拿到内存地址，后续填充属性、执行初始化方法，所有持有该引用的地方都能看到最终结果。
三级缓存各存什么？关键角色分工明确
三个缓存都是 Map
- 一级缓存 singletonObjects：存完全走完生命周期的成品 Bean（实例化 + 属性填充 + 初始化方法 + Aware 回调等全部完成），可直接对外提供服务。
- 二级缓存 earlySingletonObjects：存已实例化（new 出来）、但尚未填充属性和执行初始化的“半成品”Bean 实例，是真正被其他 Bean 拿去注入的对象。
- 三级缓存 singletonFactories：不存实例，而存 ObjectFactory 工厂对象（通常是 Lambda 表达式），用于按需生成早期引用。它延迟了真实对象的创建，避免无谓的代理对象提前生成（尤其有 AOP 时）。
循环依赖发生时，三级缓存怎么协作？
以 A 依赖 B、B 又依赖 A 为例，流程如下：
- A 开始创建 → 实例化完成 → 立即注册一个 ObjectFactory 到三级缓存（标记“A 正在创建中”，但暂不生成实例）→ 进入属性填充，发现要注入 B → 调用 getBean("b")
- B 开始创建 → 实例化完成 → 同样注册工厂到三级缓存 → 属性填充时发现要注入 A → 调用 getBean("a")
- getBean("a") 先查一级缓存（空）→ 再查二级缓存（空）→ 最后查三级缓存（命中！）→ 执行 ObjectFactory.getObject()，得到 A 的原始实例 → 将该实例放入二级缓存，同时从三级缓存移除 A 的工厂
- B 拿到这个早期 A 实例，完成自身属性填充与初始化 → 成功后放入一级缓存，清理自身在三级缓存的记录
- 回到 A 的创建流程，此时 B 已在一级缓存中 → A 注入 B，完成自身初始化 → 放入一级缓存，清理二级缓存中的 A 实例
为什么必须是三级？两级为什么不行？
如果只有两级缓存（比如去掉三级，直接把刚 new 出来的 A 放进二级缓存）：
立即学习“Java免费学习笔记（深入）”；
- 当 A 有 AOP 增强（如 @Transactional）时，Spring 应该返回的是代理对象 proxyA，而不是原始对象 rawA；但二级缓存里存的是 rawA，B 注入后就永远拿不到代理，事务失效
- 三级缓存用 ObjectFactory 封装了“要不要加代理”的逻辑：getObject() 里可判断是否需要创建代理，确保无论谁第一次取 A，拿到的都是最终该有的对象（rawA 或 proxyA）
- 这样既支持循环依赖，又不破坏 AOP 语义，职责清晰：三级缓存管“怎么造”，二级缓存管“造好了先放哪”，一级缓存管“能用了放这”
哪些循环依赖它解决不了？原因很实在
三级缓存机制有明确边界，不是万能的：
- 构造器注入循环依赖：new A 时就必须传入 B，但 B 还没 new 出来；new B 又必须传入 A —— 连实例都造不出来，根本进不了缓存流程，直接抛 BeanCurrentlyInCreationException
- 原型（prototype）Bean 循环依赖：每次 getBean 都要新创建，没有全局单例池，三级缓存无处安放，同样报循环依赖异常
- 字段/Setter 注入 + 单例：这是唯一被 Spring 官方支持且稳定解决的场景，也是三级缓存设计的全部目标
