让 AI 陪读 Spring 源码四走读 DefaultSingletonBeanRegistry 单例三级缓存锁机制在之前分析 Spring 解决循环依赖的文章中我们重点讨论了三级缓存的数据结构和ObjectFactory的提前曝光。但在多线程高并发容器初始化的场景下Spring 是如何保证单例 Bean 的创建过程**既不会发生重复实例化又不会发生死锁Deadlock**的翻看DefaultSingletonBeanRegistry.java你会发现整个单例管理模块充斥着精妙的加锁策略、双重检查锁定DCLDouble-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 和线程 2 几乎在同一毫秒发现一级和二级缓存为空都通过了第 7 行的外层if (singletonObject null)判断线程 1 率先抢占到了synchronized (this.singletonObjects)锁执行三级缓存的singletonFactory.getObject()将 Bean 升级到了二级缓存并释放锁紧接着等待锁的线程 2 获取了锁进入同步块。如果同步块内部没有进行二次判空检查线程 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 严格守住单例唯一性死锁防御高于微优化在复杂拓扑关系下宁可使用粗粒度监视器锁也绝不为了追求极致并发引入死锁隐患。
让 AI 陪读 Spring 源码四走读 DefaultSingletonBeanRegistry 单例三级缓存锁机制在之前分析 Spring 解决循环依赖的文章中我们重点讨论了三级缓存的数据结构和ObjectFactory的提前曝光。但在多线程高并发容器初始化的场景下Spring 是如何保证单例 Bean 的创建过程**既不会发生重复实例化又不会发生死锁Deadlock**的翻看DefaultSingletonBeanRegistry.java你会发现整个单例管理模块充斥着精妙的加锁策略、双重检查锁定DCLDouble-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 和线程 2 几乎在同一毫秒发现一级和二级缓存为空都通过了第 7 行的外层if (singletonObject null)判断线程 1 率先抢占到了synchronized (this.singletonObjects)锁执行三级缓存的singletonFactory.getObject()将 Bean 升级到了二级缓存并释放锁紧接着等待锁的线程 2 获取了锁进入同步块。如果同步块内部没有进行二次判空检查线程 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 严格守住单例唯一性死锁防御高于微优化在复杂拓扑关系下宁可使用粗粒度监视器锁也绝不为了追求极致并发引入死锁隐患。
