Spring源码分析-深入理解生命周期之BeanFactoryProcessor

生命周期之BeanFactoryPostProcessor

先来看看bean的生命周期。对于熟悉spring 的朋友来说，bean的生命周期并不陌生。它可以在bean加载，bean初始化的过程中加入我们自己的逻辑。并且这样体现了spring开放式的设计。先来看看生命周期的图：

今天我们要介绍的是生命周期中的BeanFactoryPostProcessor，那这个接口的作用是啥呢？它可以对已经加载好的BeanDefinition进行处理。Spring IOC 容许BeanFactoryPostProcessor 在容器实际实例化任何bean之前读取配置的元数据。有过Spring使用经验的人对 ${property} 这样的表达式肯定很熟悉。它就是对配置信息进行替换。这样使得配置解耦出来。而具体的逻辑就是在BeanFactoryPostProcessor相关的实现类的postProcessBeanFactory方法中实现的。

具体实现逻辑本文不介绍。可以看看BeanFactoryPostProcessor接口的几个实现类（比如PropertyPlaceholderConfigurer）。

今天我们抛出一个疑问：既然BeanFactoryPostProcessor是在Bean加载完毕后，Bean初始化完毕前起作用的。那我们如果在xml配置文件中自定义一个BeanFactoryPostProcessor实现类，按照道理来说这个实现类都没有初始化，是怎么起作用的？

先抛出答案：这个是特殊的bean，它在其他普通bean之前实例化前真的被实例化了。并且如果我们使用BeanFactory而不是用ApplicationContext，那么配置的BeanFactoryPostProcessor实现类不会生效，并且BeanPostProcessor也不会生效。

分析：

原因在于AbstractApplicationContext的 refresh方法中：

这个invokeBeanFactoryPostProcessors 刚好对BeanFactoryPostProcessor实现类进行了实例化，并且进行激活调用。

进去看看：

可以发现，源码中有很多getBean方法，这个正是实例化BeanFactoryPostProcessor的方法。

并且invokeBeanFactoryPostProcessors方法正是对invokeBeanFactoryPostProcessor实现类进行了激活，并对BeanDefinition进行了更改。

可以看到这个for循环里对BeanFactoryPostProcessor实现类进行了调用。

总结：本文开头的图只是ApplicationContext对应的生命周期，并不是BeanFactory对应的bean的生命周期。因为我在BeanFactory实现中没有找到BeanFactoryPostProcessor相应的实现逻辑。题外话，而且对于BeanPostProcessor来说spring容器启动只是注册实例化了BeanPostProcessor并没有调用，而是容器启动的末尾，对其他bean 进行getBean时，才会调用到这些BeanPostProcessor

心得：以前对Bean生命周期只是死记硬背，现在时豁然开朗。不需要死记硬背的，后面将会介绍bean生命周期其他的过程。