从pageHelper循环依赖看spring bean注入流程（bug定位，源码分析）

升级spring-boot到最新版本，sping报如下错误，pageHelper插件的类

PageHelperAutoConfiguration存在自身循环依赖？为什么spring-boot旧版本没有报？一时间脑子里出现这两个问题。

        分析如下：

spring容器本身通过三级缓存处理了循环依赖，为什么升级了spring-boot这个问题就暴露了？猜测处理循环依赖存在开关.

        原来新版本springboot在初始化的时候，设置了是否允许循环依赖 ，boolean的默认值为false              

        关于spring如何根据这个参数以及三级缓存处理循环依赖，后面单看一篇详细说明。

pageHelper自身循环依赖已经实锤了，因为springboot禁止了循环依赖，那让springboot允许循环依赖不就可以了吗！

        spring.main.allow-circular-references=true  启动项目，成功了！问题解决！但是这样感觉是不是太没劲了，PageHelperAutoConfiguration的循环依赖问题没有找到。

那我们就来看看PageHelperAutoConfiguration为什么产生了循环依赖。同样是先观察分析！

info日志看不出问题，我们先加上debug日志 ：debug=true

果然加上debug日志，输出丰富多了，日志可以是问题的初略定位，很多问题都能从日志看出端倪！ 分析这一堆日志，会发现有两行明显格格不入，他们不是出自spring代码，看看这两行代码干了什么！

@Configuration
@ConditionalOnBean(SqlSessionFactory.class)
@EnableConfigurationProperties(PageHelperProperties.class)
@AutoConfigureAfter(MybatisAutoConfiguration.class)
public class PageHelperAutoConfiguration {
    @Autowired
    private List<SqlSessionFactory> sqlSessionFactoryList;

    @Autowired
    private PageHelperProperties properties;

    @Bean
    @ConfigurationProperties(prefix = PageHelperProperties.PAGEHELPER_PREFIX)
    public Properties pageHelperProperties() {
        return new Properties();
    }

    @PostConstruct
    public void addPageInterceptor() {
        PageInterceptor interceptor = new PageInterceptor();
        Properties properties = new Properties();
        //问题出在这行所引用的方法 
        properties.putAll(pageHelperProperties());
        properties.putAll(this.properties.getProperties());
        interceptor.setProperties(properties);
        for (SqlSessionFactory sqlSessionFactory : sqlSessionFactoryList) {
            sqlSessionFactory.getConfiguration().addInterceptor(interceptor);
        }
    }
}

这是PageHelperAutoConfiguration的代码，@PostConstruct是注入完成后、初始化bean之前执行的代码

        properties.putAll(pageHelperProperties())

这行代码调用了一个PageHelperAutoConfiguration依赖的“bean”，pageHelperProperties()方法被bean修饰。

        猜测：如果在未完成@Configuration注解的 bean初始化的bean中调用要生成的bean会导致循环饮用。

接下来又是验证环境。

        ok，到这里猜测已经得到验证。可是就这？好吧我知道你们想知道它是如何走到循环调用这一步的，我也想知道！接着看👇

         点击堆栈异常行的后几行中某一行跳到代码，我点的是 ConstructorResolver.instantiateUsingFactoryMethod()

 加入条件断点，直接debug

 

 debug执行到断点后可以看到instantiateUsingFactoryMethod下数据情况

正在创建的beanName是test，factoryBeanName是testCircular，这是个什么东西暂时先不管，但是这玩意不为空的话会走获取创建bean(testCircular)流程！

 我们下拉左边执行堆栈找到第一个getBean方法，创建的是testCircular，相信通过前面的铺垫你一点都不意外。testCircular->test->testCircular循环就这样产生了！

脾气不好的同学可能会来一句：跟N*废话一样

爱思考的同学可能说： 上面的factoryBeanName可以为空吗如果为空，就不会走getBean("testCircular")了;

是呀factoryBeanName哪里来的？mbd（BeanDefinition）哪里来的？BeanDefinition是啥？

一个类是啥最好的解释看注释：这玩意描述bean实例，主要用途是让BeanFactoryPostProcessor检查和修改属性值和bean元数据

 看上图的getBean方法下二三行进入refresh方法

可以看到正在执行到的是finishBeanFactoryInitialization方法， 注释是：执行所有剩余单列

看一下我们上面提出的问题：mbd（BeanDefinition）哪里来的

BeanDefinition的注释也说了主要用途是让BeanFactoryPostProcessor检查和修改属性值…所以我们可以断定相关操作是在invokeBeanFactoryPostProcessors方法里完成的

同样加断点、启动👇

 先别着急深入代码，代码会把人绕晕😷，我们先观察下容器，选中右边beanFactory跳到源代码

里边儿有很多集合map，是不是看到了上面眼熟的（beanDefinition相关的），我们可以大胆猜测生成的beanDefinition就是放在beanDefinitionMap里边的，查找调用地方，找到put操作，还好put操作都在一个方法里，同样加入条件断点，

 继续执行会到断点，factoryBeanName为testCircular执行堆栈情况如前面猜想

 点到当前执行代码的上一行堆栈代码loadBeanDefinitionsForBeanMethod，下班这段代码解释了上面为什么factoryBeanName不为空！

非static的@Bean方法会设置factoryBeanName为该方法所在的类名。至于为什么，大家可以思考一下，评论区给我答疑一下。

问题和原因都找到了，可以给pageHelper提一个issue了，不过其实pageHelper新版本已经解决这个bug了，如果只是想快速解决问题不用过多分析，可以看新版本是否已经解决，没有在选择折中方案，比如允许循环依赖。

简单总结一下

1.           在bean初始化工程中，调用自生依赖未初始化完成bean会产生循环依赖。
2.          spring容器启动中，BeanDefination是在容器初始化流程的invokeBeanFactoryPostProcessors方法里处理完成的，bean的初始化依托于BeanDefination主要是在finishBeanFactoryInitialization完成的
3.         @PostConstruct时机是在bean注入完成之后
4.         还有分析异常堆栈真的很重要，不要陷入代码太多细节，根据现象猜测，缩小范围，然后再深入验证