Spring IOC（十）几种BeanPostProcessor 关系

前面几篇文章分析了一些BeanPostProcessors，包括 AutowiredAnnotationBeanPostProcessor 、 ConfigurationClassPostProcessor
、CommonAnnotationBeanPostProcessor。这几种是AnnotationApplicationContext 默认注册的 BeanPostProcessor。

本篇文章则 以 BeanPostProcessor 基础接口开始，分析Spring 一些特定的BeanProcessor 功能。

BeanPostProcessor

BeanPostProcessor 实际会在 bean初始化前后调用，其结构为：

public interface BeanPostProcessor {

	@Nullable
	default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
		return bean;
	}

	@Nullable
	default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		return bean;
	}

}

默认返回的bean即为即将初始化或者初始化之后的bean，你可以选择手动在这里修改它。
而实际上，Spring 容器在启动时，会通过区分各种不同 BeanPostProcess，而选择在不同位置调用它们。

InstantiationAwareBeanPostProcessor

• 简介：InstantiationAwareBeanPostProcessor 在实例化前会被调用，是 BeanPostProcessor 的子接口之一。
  在doCreateBean 的 resolveBeforeInstantiation 中，会判断是否为 InstantiationAwareBeanPostProcessor，是则会调用其 postProcessBeforeInstantiation 方法。
  这个类默认在Spring 容器中是不提供的，因为它会提前的返回bean实例，而不会走通用流程，即在createBean中，一旦 InstantiationAwareBeanPostProcessor 中的 postProcessBeforeInstantiation 有返回bean，则不回在走 doCreateBean 逻辑了。
• 方法：

1. postProcessBeforeInstantiation：在实例化前被调用。而在 resolveBeforeInstantiation 中，如果有 InstantiationAwareBeanPostProcessor ，也同样是 BeanPostProcessor，而当其创建完成后，则会调用 BeanPostProcessor 的 postProcessAfterInitialization 方法。
2. postProcessAfterInstantiation： 实例化之后的逻辑，这个返回true或者false，直接决定了是否需要对属性进行判定赋值（例如@Autowired 等字段解析赋值）
3. postProcessProperties ： 在 返回实例化后bean之前的设值。
4. postProcessPropertyValues：赋值阶段，即上一步获取的值在这一步设置。

是不是有点抽象？

SmartInstantiationAwareBeanPostProcessor

接着往下面看 InstantiationAwareBeanPostProcessor 的子接口 SmartInstantiationAwareBeanPostProcessor，译为聪明的 InstantiationAwareBeanPostProcessor？

这是一个有特殊目的接口，当然最好的就是通过使用装饰模式来继承 InstantiationAwareBeanPostProcessorAdapter 来实现自己目的。

• predictBeanType：预测bean的类型
• determineCandidateConstructors：决定使用哪一个构造方法
• getEarlyBeanReference：提前获取暴露的引用，主要解决 循环依赖问题，前面分析过 循环依赖中 Spring 的解决方法

具体 AutowiredAnnotationBeanPostProcessor 前面文章有分析

DestructionAwareBeanPostProcessor

即在beanDestory之前被调用，DestructionAwareBeanPostProcessor 主要在 DisposableBeanAdapter 中使用，而DisposableBeanAdapter 是一个 DisposableBean。
DisposableBean 主要是在 Spring 容器摧毁时候才被调用。如果项目中有配置的 DisposableBean，则在Spring 启动时候会被加入到集合中，当关闭时候会被调用。
另一方面 DisposableBeanAdapter 则会在 BeanFactory 要 destory 某个bean时候，直接包装一层 DisposableBeanAdapter 返回。

	protected void destroyBean(String beanName, Object bean, RootBeanDefinition mbd) {
		new DisposableBeanAdapter(bean, beanName, mbd, getBeanPostProcessors(), getAccessControlContext()).destroy();
	}

• postProcessBeforeDestruction 摧毁前调用
• requiresDestruction： 判断是否需要destory，可以根据名字选择返回。

MergedBeanDefinitionPostProcessor

这个接口 主要可以用于解析，改造beanDefinition吧。调用点在 doCreateBean时候。

		// Allow post-processors to modify the merged bean definition.
		synchronized (mbd.postProcessingLock) {
			if (!mbd.postProcessed) {
				try {
					applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
				}
				catch (Throwable ex) {
					throw new BeanCreationException(mbd.getResourceDescription(), beanName,
							"Post-processing of merged bean definition failed", ex);
				}
				mbd.postProcessed = true;
			}
		}

• postProcessMergedBeanDefinition：
  前面分析的 AutowiredAnnotationBeanPostProcessor 和 CommonAnnotationBeanPostProcessor 会选择在 postProcessMergedBeanDefinition这个方法来解析Class，即找出所有有注解的类。（在populateBean前）
• resetBeanDefinition，则是重置bean。

总结

Spring 内部有很多种 BeanPostProcessor，并且基于其也有许多子接口，可以实现不同的逻辑。而开发者只需要实现其并注册进入，不用改变Spring内部代码，即可实现其功能。

利用 BeanPostProcessor，也可以实现自己的功能，例如Spring AOP逻辑。

遵循设计模式的开闭原则，开放扩展，而不用修改代码。

觉得博主写的有用，不妨关注博主公众号: 六点A君。
哈哈哈，一起研究Spring：