Spring的循环依赖和三级缓存

### Spring 框架中的三级缓存机制 Spring 容器通过其内部实现的三级缓存来解决单例 Bean 的循环依赖问题。以下是关于这一主题的具体说明： #### 单例 Bean 循环依赖概述 在 Spring 中，当两个或多个 Bean 形成相互依赖的关系时，就会发生循环依赖。例如，Bean A 依赖于 Bean B，而 Bean B 又反过来依赖于 Bean A。这种情况下，默认构造函数注入可能会导致实例化失败。 为了处理这种情况，Spring 提供了一种基于 **三级缓存** 的解决方案[^1]。 #### 三级缓存的工作原理 Spring 使用三个不同的缓存结构来存储正在创建和已经完成初始化的 Bean 实例。这些缓存分别是： 1. **`singletonObjects`**: 存储完全初始化后的单例对象。 2. **`earlySingletonObjects`**: 存储尚未完成初始化的对象（即早期暴露的对象）。 3. **`singletonFactories`**: 存储用于延迟加载的工厂方法。 具体流程如下： - 当容器尝试获取某个 Bean 时，它会先检查 `singletonObjects` 缓存是否存在该 Bean。如果存在，则直接返回。 - 如果不存在，继续检查 `earlySingletonObjects` 和 `singletonFactories` 是否有对应的占位符或提前曝光的 Bean 实例。 - 在实际创建过程中，Spring 首先将当前未完成的 Bean 放入 `singletonFactories` 或者 `earlySingletonObjects` 中作为临时状态，以便其他 Bean 能够访问到这个部分构建好的实例。 一旦所有的依赖都已解析完毕并完成了必要的后置处理器调用之后，最终完整的 Bean 就会被移至 `singletonObjects` 并清理掉中间阶段使用的缓存条目[^2]。 #### 示例代码展示 下面是一个简单的例子演示如何配置以及可能触发上述机制的情况: ```java @Component public class ServiceA { private final ServiceB serviceB; @Autowired public ServiceA(ServiceB serviceB) { this.serviceB = serviceB; } } @Component public class ServiceB { private final ServiceA serviceA; @Autowired public ServiceB(ServiceA serviceA) { this.serviceA = serviceA; } } ``` 在这个场景下,如果没有特别设置允许此类情况(Such as setting primary or qualifier annotations),则默认情况下,Spring能够自动利用它的三重缓冲策略去妥善管理这两个互相引用的服务组件. #### 局限性和注意事项 尽管如此强大的功能可以帮助我们简化很多复杂关系的设计考量,但也并非适用于所有场合: - 原型(Prototype)作用域下的 bean 不支持此方式解决循环依赖. - 对某些自定义生命周期或者特殊需求的应用程序来说,过度依赖框架自带的行为可能导致不可预测的结果.[^3] ### 结论 综上所述,Spring Framework确实具备一套完善的体系用来应对常见的开发难题之一——循环依赖问题;借助精心设计过的多级内存映射技术实现了优雅高效的资源调配方案.