当前位置：首页 > news >正文

spring为什么使用三级缓存而不是两级？

news 2026/5/11 23:08:11

Spring 使用三级缓存（而不是两级）来解决循环依赖，主要目的是兼容 AOP（动态代理）场景，同时保持 Bean 创建过程的语义一致性和扩展性。

如果只用两级缓存，在大多数普通属性注入的循环依赖场景下确实可以工作，但一旦引入 AOP（@Transactional、@Async、@Cacheable 等），就会出现非常严重的问题：提前暴露的对象和最终容器里的对象不是同一个（类型/引用不一致），导致运行时类型转换异常、代理失效、事务不生效等。

三级缓存各自职责（DefaultSingletonBeanRegistry）

缓存层级	Map 类型	存放的内容	什么时候放入	什么时候取出并移除	核心目的
一级缓存 singletonObjects	普通 bean（成品）	完全初始化好的 bean（可能已代理）	初始化完成、放入成品后	几乎所有 getBean 最终都走这里	成品缓存，正常使用的地方
二级缓存 earlySingletonObjects	早期普通对象（半成品）	已实例化但还没完成属性填充和初始化的原始对象	从三级缓存拿到并暴露早期引用后	被其他 bean 依赖时取出，移到一级	防止重复创建同一个早期对象
三级缓存 singletonFactories	ObjectFactory（lambda 工厂）	生成早期引用的工厂（通常是 getEarlyBeanReference 的 lambda）	put 时创建 bean 实例后立即放入	第一次被循环依赖时调用 getObject() → 生成早期对象（或代理对象）→ 放入二级	延迟决定是否要 AOP 代理的关键点

为什么二级缓存不够？（最核心原因）

假设我们只有一级 + 二级（成品 + 早期普通对象）：

A → B → A (A 被 AOP 代理)

创建 A → 实例化（new A） → 放入二级缓存（早期 A，原始对象）
A 需要注入 B → 创建 B
B 需要注入 A → 从二级缓存拿到原始 A（还没代理）
B 完成 → 放入一级缓存
A 继续 → 填充属性、初始化、AOP 后生成代理对象 proxyA
proxyA 放入一级缓存

问题来了：

B 手里拿到的 A 是原始 A
容器最终暴露的是proxyA
B 拿到的引用和最终容器里的 bean 不是同一个对象！

这会导致：

B 调用 A 的方法时绕过了代理 → 事务/日志/权限等切面全部失效
类型检查失败（有些地方强转成代理接口会报错）
equals()/hashCode() 异常行为

三级缓存如何解决这个问题？

关键就在第三级：它放的不是对象本身，而是一个 ObjectFactory（lambda），这个 lambda 会在真正被别人依赖的时候才执行：

// 大致伪代码protectedObjectgetEarlyBeanReference(StringbeanName,RootBeanDefinitionmbd,Objectbean){returngetSingleton(beanName,()->{// 这里才是真正决定要不要代理的地方returnapplyBeanPostProcessorsBeforeInitialization(bean,beanName);// → post-processor 可能返回代理对象});}