摘要：Spring的三级缓存机制（singletonObjects、earlySingletonObjects、singletonFactories）是IoC容器的核心设计之一，其目的是解决循环依赖问题，尤其是涉及AOP代理的场景。然而，这一设计长期存在争议，既被赞
Spring的三级缓存机制（singletonObjects、earlySingletonObjects、singletonFactories）是IoC容器的核心设计之一，其目的是解决循环依赖问题，尤其是涉及AOP代理的场景。然而，这一设计长期存在争议，既被赞誉为“天才方案”，也被质疑为“技术债务”。以下从多个角度深入探讨其本质。
核心目标：解决循环依赖当Bean A依赖Bean B，而Bean B又依赖Bean A时，Spring通过三级缓存提前暴露半成品Bean，打破初始化死锁。例如，A实例化后未完成属性注入时，其工厂对象被存入三级缓存，供B依赖注入使用149。AOP代理的延迟创建
三级缓存的核心价值在于处理AOP动态代理。通过ObjectFactory延迟代理对象的生成，确保循环依赖中所有Bean引用同一代理实例，避免因代理对象多次生成导致的不一致问题110。三级缓存的协同流程一级缓存：存储完全初始化的Bean，确保单例唯一性34。二级缓存：临时存储半成品Bean，解决循环依赖中的早期引用需求58。三级缓存：通过工厂模式动态生成代理对象，支持AOP场景下的循环依赖108。复杂性过高
三级缓存的逻辑嵌套在DefaultSingletonBeanRegistry中，涉及多级缓存的查询与状态切换，代码可读性差，调试困难58。构造器注入的局限性
若循环依赖的Bean通过构造器注入，三级缓存无法解决，需依赖其他方案（如@Lazy），暴露设计边界49。内存与性能隐患内存泄漏风险：未及时清理的缓存条目可能导致内存占用过高（如earlySingletonObjects未释放）26。反射性能损耗：动态代理依赖反射和字节码生成，可能拖累性能（尤其在频繁代理场景下）510。对代码设计的隐性鼓励
Spring允许循环依赖的解决，可能导致开发者忽视代码分层与模块化设计，间接助长“坏味道”代码37。
三级缓存既是Spring解决循环依赖的“杀手锏”，也是框架复杂性的缩影。其设计巧妙性毋庸置疑，但过度依赖可能掩盖代码设计问题。开发者需在理解其原理的基础上，权衡使用场景，避免将框架特性作为技术债务的避风港。
来源：大龄程序猿小武