Spring为什么用三级缓存来解决循环依赖问题? 二级不行吗?

为了直击重点, 循环依赖的概念就不多介绍了, 大家可以自己去看一下; 

我在学习循环依赖的解决方案时, 一直有这样的疑惑: A, B 循环依赖的话, A 实例化以后直接放到二级缓存, B 注入的时候直接到二级缓存取 A 就可以了, 为什么 A 要先放到三级缓存, 被注入的时候再挪到二级缓存?

一句话总结: 为了优雅地引入 AOP;

一开始, Spring 没有引入 AOP 的时候, 是采用两级缓存来解决循环依赖问题的;

后来引入了 AOP, 为了尽量不让 AOP 影响原本 Bean 的创建过程，AOP 应该尽量在注入都完成以后再做;

那么在原本两级缓存的基础上我可以这样做: bean 实例化以后放到二级缓存, 完成注入以后再生成代理对象放到一级缓存; 这样看似可以;

但是, 还有一个原则, 如果别的类需要注入 AOP 的对象, 那么应该注入代理对象, 而非原本的对象;

在有循环依赖的时候, 这两条原则是冲突的, 上面的两级缓存设计没法同时满足这两条原则:

• 例如 A 要做代理, 并且 A B 循环依赖;

• A 实例化以后放在二级缓存, 注入B的时候触发 B 的实例化;

• B 实例化完成以后需要注入 A, 此时只有一个没有代理的原本的 a 对象; 并没有 A 的代理对象;

只能做出让步, 不去完全贯彻注入后再 AOP 的原则了, 在有循环依赖的时候, 先生成代理对象;

• A 实例化以后放在二级缓存, 如果这时候有bean 要注入 A, 那么A 对应的 ObjectFactory 的 getObject 方法新创建一个代理对象返回;

这样又有新的问题, 假设 A 要进行 AOP, 并且和 B C 都有循环依赖; 那么 B C 都要到缓存中去取 getObject 来获取 A 的代理, 问题是每次 getObject 返回的都是新的代理对象, 这样 B C 所持有的 A 不是同一个;

所以引入三级缓存, 对象实例化后封装为 ObjectFactory, 放到三级缓存, 将解决循环依赖过程中第一次生成的代理对象, 放到二级缓存里; 以后再要获取, 直接到二级缓存取;

如果没有发生循环依赖, 正常应该是在 A 完成注入以后, 检查是否生成了代理, 如果没有, 再去生成代理;