企业官网建设流程全解析

让 AI 陪读 Spring 源码（四）：走读 DefaultSingletonBeanRegistry 单例三级缓存锁机制

在之前分析 Spring 解决循环依赖的文章中，我们重点讨论了三级缓存的数据结构和ObjectFactory的提前曝光。
但在多线程高并发容器初始化的场景下，Spring 是如何保证单例 Bean 的创建过程**既不会发生重复实例化，又不会发生死锁（Deadlock）**的？

翻看DefaultSingletonBeanRegistry.java，你会发现整个单例管理模块充斥着精妙的加锁策略、双重检查锁定（DCL，Double-Checked Locking）以及分段集合控制。

今天我们借助大模型辅助，深入走读getSingleton(String beanName, boolean allowEarlyReference)的并发控制源码。

核心源码：getSingleton的双重检查锁定实现

// Spring 源码 DefaultSingletonBeanRegistry.java @Nullable protected Object getSingleton(String beanName, boolean allowEarlyReference) { // 1. 快速无锁快照读：尝试从一级缓存中直接获取已完全初始化的 Bean Object singletonObject = this.singletonObjects.get(beanName); // 2. 一级缓存没有，且当前 Bean 正在被某个线程创建中（说明可能存在循环依赖） if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { // 尝试从二级缓存中获取半成品 Bean singletonObject = this.earlySingletonObjects.get(beanName); // 3. 二级缓存也没有，且允许提前引用 if (singletonObject == null && allowEarlyReference) { // 关键点：进入 synchronized 同步代码块，锁住全局单例注册表监视器对象 synchronized (this.singletonObjects) { // 4. 双重检查锁定（DCL）：再次检查一级缓存 singletonObject = this.singletonObjects.get(beanName); if (singletonObject == null) { // 再次检查二级缓存 singletonObject = this.earlySingletonObjects.get(beanName); if (singletonObject == null) { // 5. 命中三级缓存：从工厂中获取对象引用 ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName); if (singletonFactory != null) { // 调用 ObjectFactory.getObject() 触发 getEarlyBeanReference 生成代理或返回原生对象 singletonObject = singletonFactory.getObject(); // 晋升到二级缓存 this.earlySingletonObjects.put(beanName, singletonObject); // 从三级缓存中移除，防止重复执行工厂逻辑 this.singletonFactories.remove(beanName); } } } } } } return singletonObject; }

深度剖析：为什么需要两道 DCL 双重检查？

在向大模型提问时，我追问了一个非常刁钻的问题：

“在第 15 行进入synchronized (this.singletonObjects)之后，为什么必须再次执行singletonObjects.get(beanName)和earlySingletonObjects.get(beanName)两次判空？”

AI 帮我推导了如下极端并发场景：

假设有两个线程 Thread 1 和 Thread 2 同时在初始化 Bean A 和 Bean B：

1. 线程 1 和线程 2 几乎在同一毫秒发现一级和二级缓存为空，都通过了第 7 行的外层if (singletonObject == null)判断；
2. 线程 1 率先抢占到了synchronized (this.singletonObjects)锁，执行三级缓存的singletonFactory.getObject()，将 Bean 升级到了二级缓存并释放锁；
3. 紧接着，等待锁的线程 2 获取了锁进入同步块。
4. 如果同步块内部没有进行二次判空检查：
   线程 2 会再次从singletonFactories获取工厂并执行getObject()。
   如果该 Bean 配置了 AOP 切面，getObject()会导致生成一个全新的代理对象，覆盖掉线程 1 已经生成的代理对象，直接破坏了 Spring 的单例唯一性契约！

为什么锁的是this.singletonObjects而不是当前 BeanName？

在源码中，加锁的对象是synchronized (this.singletonObjects)（即整个一级缓存的 ConcurrentHashMap 实例）。
很多同学会问：为什么不按beanName细粒度加锁？

大模型给出的架构解释非常精辟：

• 循环依赖涉及跨 Bean 的级联访问：在复杂的循环依赖网（如 A $\to$ B $\to$ C $\to$ A）中，如果按 BeanName 分段加锁，线程 1 持有 A 尝试锁 B，线程 2 持有 B 尝试锁 C，线程 3 持有 C 尝试锁 A，会瞬间构成循环等待资源的典型死锁（Deadlock）！
• 粗粒度锁保平安：Spring 容器在启动初始化阶段，创建 Bean 的绝对耗时主要在类加载与依赖计算上，从三级缓存读取工厂并升级到二级缓存的操作极其轻量（微秒级）。使用全局监视器锁虽然损失了微弱的并发度，但彻底排除了死锁风险。

实习生读源码总结

通过借助大模型对 Spring 锁机制的推演，我们能深刻体会到工业级框架在处理高并发场景时的严谨：

• 读写分离与无锁优先：能无锁读先无锁读，最大化提升热点查询吞吐；
• 锁内双检守底线：在写操作前用 DCL 严格守住单例唯一性；
• 死锁防御高于微优化：在复杂拓扑关系下，宁可使用粗粒度监视器锁，也绝不为了追求极致并发引入死锁隐患。