spring的三级缓存及二三级缓存解决的问题

spring的三级缓存及二三级缓存解决的问题 - 指南

news/2025/12/3 22:29:03/文章来源:https://www.cnblogs.com/yangykaifa/p/19304203

一、三级缓存解决单例循环依赖的完整流程

Spring通过三级缓存（singletonObjects、earlySingletonObjects、singletonFactories）配合单例Bean的循环依赖（如A依赖B，B依赖A），核心是提前暴露Bean的早期引用，同时保证Bean的单例性和完整性。

三级缓存定义：

一级缓存（singletonObjects）：存储完全初始化达成的单例Bean，是最终对外提供的实例。
二级缓存（earlySingletonObjects）：存储提前暴露的早期引用（可能是原始Bean或AOP代理），用于解决循环依赖时的临时缓存。
三级缓存（singletonFactories）：存储ObjectFactory工厂对象，用于延迟创建早期引用（原始Bean或代理），避免提前固定Bean形态。

解决循环依赖的完整步骤（以A依赖B，B依赖A为例）：

创建A的实例：
- 执行A的构造器（实例化），生成原始对象A（未注入依赖，未初始化）。
- 创建ObjectFactory工厂对象，存入三级缓存singletonFactories。工厂的getEarlyBeanReference方法逻辑：若A需要AOP代理，则创建代理；否则返回原始对象A。
A需要注入B：
- 检查一级/二级缓存，未找到B（B尚未创建），触发B的创建流程。
创建B的实例：
- 执行B的构造器（实例化），生成原始对象B（未注入依赖，未初始化）。
- 创建ObjectFactory工厂对象，存入三级缓存singletonFactories。
B需要注入A：
- 检查一级缓存（无，A未完成）→ 检查二级缓存（无）→ 从三级缓存获取A的工厂。
- 调用A的工厂getEarlyBeanReference方法，生成A的早期引用（若A需要AOP，则是代理对象P；否则是原始A）。
- 将A的早期引用存入二级缓存earlySingletonObjects，并移除三级缓存中的A工厂（避免重复创建）。
- B注入A的早期引用（代理P或原始A），结束依赖注入。
B达成初始化：
- B执行初始化方法（如@PostConstruct），成为完整Bean，存入一级缓存singletonObjects。
A继续初始化：
- A注入已完成的B（从一级缓存获取），执行初始化办法，成为完整Bean。
- 检查二级缓存：若存在A的早期引用（如代理P），则将其移至一级缓存（替代原始A，保证对外暴露的是代理）；若不存在，则将原始A存入一级缓存。
最终结果：
- A和B均为完整Bean，且相互引用的是对方的有效实例（AOP代理或原始对象），循环依赖消除。

二、二级缓存（earlySingletonObjects）解决的核心挑战

二级缓存是“早期引用的临时仓库”，克服的是“避免同一Bean的早期引用被重复创建”的问题，直接保障单例唯一性。

具体场景：

若多个Bean依赖同一个Bean（如B、C都依赖A），且A需要AOP代理：

无二级缓存时：B依赖A时调用A的工厂创建代理P1，C依赖A时再次调用工厂创建代理P2，导致A的代理不唯一（破坏单例）。
有二级缓存时：B依赖A时创建代理P并存入二级缓存，C依赖A时直接从二级缓存获取P，确保代理唯一。

核心作用：

缓存经过三级缓存工厂创建的早期引用（代理或原始Bean），避免工厂被重复调用。
作为一级缓存的“过渡区”，在Bean未完全初始化前临时存储早期引用，保证循环依赖时的引用可获取。

三、三级缓存（singletonFactories）解决的核心问题

三级缓存是“延迟创建早期引用的工厂容器”，解决的是“循环依赖时如何安全暴露Bean引用” 和“AOP代理的按需创建”问题。

核心作用1：解决循环依赖的“引用暴露时机”困难

循环依赖的本质矛盾是“Bean未初始化完成却需要被引用”。三级缓存的工厂通过以下方式应对：

暴露“能创建早期引用的工厂”，避免提前暴露未完整的Bean。就是Bean实例化后，不直接暴露对象，而
当其他Bean依赖它时，才通过工厂生成早期引用（延迟暴露），确保引用在“必要时”才被获取。

核心作用2：保证AOP代理的“按需创建”与“状态完整”

无循环依赖时：工厂不会被调用，AOP代理在Bean初始化后创建（遵循“初始化后增强”原则）。
有循环依赖时：工厂被触发，提前创建代理，但代理内部的目标Bean会继续完成初始化（最终代理关联完整Bean）。
若直接暴露原始Bean或代理（无工厂），会导致AOP代理失效或关联不完整状态（如实例化后直接创建代理，目标Bean未初始化）。

四、构造器注入的循环依赖与@Lazy解决方式

问题：构造器注入为何容易引发循环依赖？

“实例化阶段”的依赖注入（通过构造器参数注入），而Bean的实例化必须在依赖注入之前。若A的构造器依赖B，B的构造器依赖A，则：就是构造器注入

创建A时，需要先实例化B（因为A的构造器需B）；
创建B时，需要先实例化A（由于B的构造器需要A）；
陷入“先有鸡还是先有蛋”的死循环，三级缓存无法应对（三级缓存作用于“实例化后”，而构造器注入在“实例化中”）。

@Lazy注解的应对原理

@Lazy通过延迟初始化依赖对象，将“构造器注入的即时依赖”转为“代理对象的延迟引用”，打破循环。

示例（A和B相互构造器依赖）：

@Component
public class A {
private B b;
// A的构造器依赖B，添加@Lazy
public A(@Lazy B b) {
this.b = b;
}
}
@Component
public class B {
private A a;
// B的构造器依赖A，添加@Lazy
public B(@Lazy A a) {
this.a = a;
}
}