Spring 的三级缓存，两级够吗

Spring 的三级缓存机制主要是为了解决 循环依赖 问题，同时保证 AOP 代理 的正确性。

结论是：两级缓存不够，必须用三级缓存。

一级缓存 ：singletonObjects（已经完成初始化的单例 Bean）
二级缓存 ：earlySingletonObjects（提前暴露的 Bean，尚未完全初始化，但已可被引用）
三级缓存 ：singletonFactories（对象工厂 ObjectFactory，用于生成 Bean 的早期引用，通常是为了生成 AOP 代理）

理论上，仅为了解决循环依赖，二级缓存是足够的：

但问题出现在 A 需要被 AOP 代理 时。

Spring AOP 通常是在 Bean 初始化后 （postProcessAfterInitialization）通过后置处理器生成代理对象。

但在循环依赖中：

实例化 （createBeanInstance） → 原始对象
属性填充 （populateBean） → 依赖注入
初始化 （initializeBean）：
- 调用 applyBeanPostProcessorsBeforeInitialization
- 调用 init-method
- 调用 applyBeanPostProcessorsAfterInitialization
  这一步中，AOP 后置处理器 会检查 Bean 是否需要代理，如果需要则生成代理对象，并返回代理。
最终放入一级缓存 （singletonObjects）

正常情况下，AOP 代理确实是在初始化完成后才创建的。

假设 A 需要 AOP，B 依赖 A。

A 实例化 ：创建原始对象 A_raw。
提前暴露 ：addSingletonFactory 将 A_raw 包装成一个 ObjectFactory 放入三级缓存。
这个工厂的 getObject 方法内部会调用 getEarlyBeanReference(beanName, mbd, A_raw)。
A 属性填充：发现需要 B → 去获取 B。
B 开始创建 ：实例化 B → 属性填充时发现需要 A → 从缓存获取 A。
- 一级缓存无（A 未完成）
- 二级缓存无
- 三级缓存有工厂 → 调用工厂 ，即执行 getEarlyBeanReference。
getEarlyBeanReference 的作用 ：
它会遍历所有 SmartInstantiationAwareBeanPostProcessor（AOP 后置处理器实现了该接口），并调用其 getEarlyBeanReference 方法。
此时，AOP 后置处理器发现 A_raw 需要被代理（比如有 @Transactional 或 @Aspect），就直接生成代理对象 A_proxy 并返回。
返回的代理对象 ：
- 存入二级缓存 earlySingletonObjects（key=beanName, value=代理对象）
- 从三级缓存移除工厂
B 获取到 A_proxy，完成 B 的创建。
A 继续初始化 ：
A 在完成属性填充后，进入初始化阶段。但在 applyBeanPostProcessorsAfterInitialization 中，AOP 后置处理器会检查该 Bean 是否已经存在代理（通过一个缓存标记），发现代理已经提前生成，就不会再生成新的代理，直接返回现有的代理对象。
最终 A 的代理对象被放入一级缓存。

这是因为 SmartInstantiationAwareBeanPostProcessor 接口专门定义了一个 getEarlyBeanReference 方法，允许后置处理器在 Bean 实例化后、属性填充前 就提供一个对象引用（通常是代理）。

Spring AOP 的 AbstractAutoProxyCreator 实现了这个方法，它会在循环依赖发生时，提前创建代理，而不是等到初始化之后。

所以代理的创建时机有两个可能路径：

这样设计就是为了保证：即使循环依赖，依赖方拿到的也是最终要用的代理对象，而不是原始对象。

如果强行用两级缓存，有两个方案，但都有问题：

三级缓存本质是 将"提前暴露"与"生成最终对象"解耦 ，通过 ObjectFactory 延迟决定早期引用是原始对象还是代理对象，兼顾了循环依赖和 AOP。