四探循环依赖 → 当循环依赖遇上 BeanPostProcessor，爱情可能就产生了！

​

前情回顾

　　楼主一而再，再而三的折腾循环依赖，你们不烦，楼主自己都烦了，如果你们实在是受不了，那就...

​

　　言归正传，虽然确实有点像懒婆娘的裹脚布，又臭又长，但确实还是有点东西的，只要大家坚持看完，肯定会有收获的！

　　我们先回顾下前三探

　　一探

Spring 的循环依赖，源码详细分析 → 真的非要三级缓存吗 中讲到了循环依赖问题

Spring 通过三级缓存解决 setter 循环依赖

　　一级缓存 singletonObjects 存的是对外暴露的对象，也就是我们应用真正用到的对象

　　二级缓存 earlySingletonObjects 存的是半成品对象或半成品对象的代理对象，用于处理循环依赖的对象创建问题

　　三级缓存 singletonFactories 存的是创建对象的工厂方法，用于处理存在 AOP + 循环依赖的对象创建问题

　　着重分析了是否一定需要三级缓存来解决循环依赖问题

　　二探

Spring 不能处理构造方法的循环依赖，也不能处理原型循环依赖

再探循环依赖 → Spring 是如何判定原型循环依赖和构造方法循环依赖的，从源码的角度分析了 Spring 是如何鉴别构造方法循环依赖、原型循环依赖的

Set<String> singletonsCurrentlyInCreation 会记录当前正在创建中的实例名称， Spring 创建实例对象之前，会判断 singletonsCurrentlyInCreation 中是否存在该实例的名称，如果存在则表示产生构造方法循环依赖了

ThreadLocal<Object> prototypesCurrentlyInCreation 会记录当前线程正在创建中的原型实例名称， Spring 创建原型实例对象之前，会判断 prototypesCurrentlyInCreation 中是否存在该实例的名称，如果存在则表示产生原型循环依赖了

　　三探

三探循环依赖 → 记一次线上偶现的循环依赖问题，从源码的角度分析了这次偶现问题可能出现的原因

BeanDefinition 的扫描顺序：以启动类为起点，扫描启动类同级目录下的所有文件夹，按文件夹名升序顺序进行扫描，会递归扫描每个文件夹，文件扫描也是按文件名升序顺序进行

BeanDefinition 覆盖， @Configuration + @Bean 修饰的 BeanDefinition 会覆盖 @Component 修饰的 BeanDefinition ， BeanDefinition 的覆盖并不影响 BeanDefinition 的扫描

Bean 的实例化顺序，理论上来讲，先被扫描到的就先被实例化，但实例化过程中的属性填充会打乱这个顺序，会将被依赖的对象提前实例化

　　一通分析下来，虽说没能找到问题的真正原因，但至少知道了如何去规避这个问题，如何正确的书写规范的代码

问题复现

　　经过前面三探，楼主以为对 Spring 的循环依赖已经拿捏的死死的了，然而当他出现后，楼主才发现，不是她离不开我，而是我离不开她了

​

　　我们来看看循环依赖和 BeanPostProcessor 是如何产生爱情的火花的

SpringBoot 版本 2.0.3.RELEASE ，示例代码地址：spring-circular-beanpostprocessor

　　我们只需要关注三个类

　　依赖很简单， ServiceAImpl 依赖 ServiceBImpl ， ServiceBImpl 也依赖 ServiceAImpl ，这种循环依赖，楼主自认为拿捏的死死的

　　直到 BeanPostProcessor 的出现，循环依赖决定不再迁就，她俩的爱情就产生了

　　她俩的爱情信息：

org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'serviceAImpl': Bean with name 'serviceAImpl' has been injected into other beans [serviceBImpl] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.

　　此刻，楼主才明白，小丑竟是我自己！

问题分析

　　其实她俩的爱情信息已经提示的很明显了，楼主再忍痛翻译一下： serviceAImpl 作为循环依赖的一部分注入到了 serviceBImpl 后，又被包装了，这就意味着 serviceBImpl 引用的不是最终版本的 serviceAImpl

　　关于 BeanPostProcessor ，楼主不想过多介绍，大家可以查看：Spring拓展接口之BeanPostProcessor，我们来看看它的底层实现

　　从错误堆栈信息，我们可以追踪到 Spring 报错的代码

　　 因为 ServiceAImpl 比 ServiceBImpl 先被扫描，所以 serviceAImpl 先被实例化，实例化过程如下

　　此时一切都正常，问题就出在 serviceAImpl 填充属性serviceBImpl 完成之后，我们来 debug 下

　　从 debug 结果可以看到， ServiceBImpl 的实例对象 ServiceBImpl@5171 中注入的 ServiceAImpl 对象是 ServiceAImpl@5017

　　而经过 initializeBean(beanName, exposedObject, mbd); 后， Spring 暴露出来的 ServiceAImpl 的最终对象是 $Proxy53@5212

　　这就导致 ServiceBImpl@5171 中注入的 ServiceAImpl@5017 并不是最终版本的 ServiceAImpl ，她们的爱情就这么产生了

问题处理

　　面对这样的问题，我们可以怎么处理了

　　@Lazy

　　通过 @Lazy 延迟注入，在真正使用到的时候才进行注入

　　在任意一个属性上加 @Lazy 即可，例如

　　或者

　　或者两个都加上 @Lazy

　　SmartInstantiationAwareBeanPostProcessor

　　弃用 BeanPostProcessor ，改用 SmartInstantiationAwareBeanPostProcessor

　　重写的方法是： getEarlyBeanReference ，而非 postProcessAfterInitialization 方法，提前暴露代理对象

　　也就是说在 ServiceAImpl 对象填充属性（populateBean(beanName, mbd, instanceWrapper)）之前，就将代理对象提前暴露到第三级缓存中

　　后续给 ServiceBImpl 对象填充 serviceAImpl 属性时，就用第三级缓存中的 ServiceAImpl 代理对象

　　剔除循环依赖

　　循环依赖本就不合理，项目中应尽量避免

　　至于如何剔除，无法一概而论，需要大家自己去琢磨了

总结

　　循环依赖

　　虽说 Spring 通过三级缓存解决了 setter 方式的循环依赖，但这不能成为我们有恃无恐的理由

　　循环依赖本就不合理，尽量去规避

　　真实项目问题

　　相信很多小伙伴会有这样的疑问：楼主，你是怎么就让 循环依赖 遇上 BeanPostProcessor ？

　　因为已有代码的不规范，导致很多地方都产生了循环依赖，而最近又引入 Shareding-JDBC 做分库，而 Shareding-JDBC 又通过 BeanPostProcessor 来生成代理对象

　　就这样，她俩就相遇了