监控K8S和Docker的热门开源工具

概意思是：

如果您主要使用构造器注入，循环依赖场景是无法解决的。建议你用 setter 注入方式代替构造器注入

其实也不是说只要是构造器注入就会有循环依赖问题，Spring 在创建 Bean 的时候默认是按照自然排序来进行创建的，我们暂且把先创建的 bean 叫主 bean，上文的 A 即主 bean，只要主 bean 注入依赖 bean 的方式是 setter 方式，依赖 bean 的注入方式无所谓，都可以解决，反之亦然

所以上文我们 AB 循环依赖问题，只要 A 的注入方式是 setter ，就不会有循环依赖问题。

面试官问：为什么呢?

Spring 解决循环依赖依靠的是 Bean 的“中间态”这个概念，而这个中间态指的是已经实例化，但还没初始化的状态。实例化的过程又是通过构造器创建的，如果 A 还没创建好出来，怎么可能提前曝光，所以构造器的循环依赖无法解决，我一直认为应该先有鸡才能有蛋。

小总结 | 面试这么答B 中提前注入了一个没有经过初始化的 A 类型对象不会有问题吗?

虽然在创建 B 时会提前给 B 注入了一个还未初始化的 A 对象，但是在创建 A 的流程中一直使用的是注入到 B 中的 A 对象的引用，之后会根据这个引用对 A 进行初始化，所以这是没有问题的。

Spring 是如何解决的循环依赖?

Spring 为了解决单例的循环依赖问题，使用了三级缓存。其中一级缓存为单例池(singletonObjects)，二级缓存为提前曝光对象(earlySingletonObjects)，三级缓存为提前曝光对象工厂(singletonFactories)。

假设A、B循环引用，实例化 A 的时候就将其放入三级缓存中，接着填充属性的时候，发现依赖了 B，同样的流程也是实例化后放入三级缓存，接着去填充属性时又发现自己依赖 A，这时候从缓存中查找到早期暴露的 A，没有 AOP 代理的话，直接将 A 的原始对象注入 B，完成 B 的初始化后，进行属性填充和初始化，这时候 B 完成后，就去完成剩下的 A 的步骤，如果有 AOP 代理，就进行 AOP 处理获取代理后的对象 A，注入 B，走剩下的流程。

为什么要使用三级缓存呢?二级缓存能解决循环依赖吗?

如果没有 AOP 代理，二级缓存可以解决问题，但是有 AOP 代理的情况下，只用二级缓存就意味着所有 Bean 在实例化后就要完成 AOP 代理，这样违背了 Spring 设计的原则，Spring 在设计之初就是通过 AnnotationAwareAspectJAutoProxyCreator 这个后置处理器来在 Bean 生命周期的最后一步来完成 AOP 代理，而不是在实例化后就立马进行 AOP 代理。

 

再问：AOP 代理对象提前放入了三级缓存，没有经过属性填充和初始化，这个代理又是如何保证依赖属性的注入的呢?

这个又涉及到了 Spring 中动态代理的实现，不管是cglib代理还是jdk动态代理生成的代理类，代理时，会将目标对象 target 保存在最后生成的代理 $proxy 中，当调用 $proxy 方法时会回调 h.invoke，而 h.invoke 又会回调目标对象 target 的原始方法。所有，其实在 AOP 动态代理时，原始 bean 已经被保存在 提前曝光代理中了，之后 原始 bean 继续完成属性填充和初始化操作。因为 AOP 代理$proxy中保存着 traget 也就是是 原始bean 的引用，因此后续 原始bean 的完善，也就相当于Spring AOP中的 target 的完善，这样就保证了 AOP 的属性填充与初始化了!

非单例循环依赖

看完了单例模式的循环依赖，我们再看下非单例的情况，假设我们的配置文件是这样的：

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!