spring源码：BeanPostProcessor（li）

　　在spring管理Bean的初始化过程中，除了正常管理bean的实例化（初始化、参数注入等）外，还对外提供了丰富的对Bean操作的扩展。例如自定义初始化操作，自定义容器退出时Bean的销毁操作等等。这段时间看源码觉得此方面最实际的一个例子就是，我们在Bean初始化之前以及之后，框架允许我们做一些统一性的逻辑操作。BeanPostProcessor就完成了这个功能，它能够在装配Bean的过程中动态去改变Bean的行为，达到对Bean的增强。首先需要了解整个spring容器对bean初始化的流程，其流程图如下：

上图中已经完成了容器的初始化（对配置文件的加载和解析），已经进入到实例化阶段。能够看出BeanPostProcessor在整个流程中所处的位置，它正好围绕着bean自定义初始化方法前后。那么有一个问题，就是既然能够使用afterPropertySet或者init-method来自行初始化我们的bean，那么为什么还要这些BeanPostProcessor呢？因为afterPropertySet和init-method更关注自身的业务逻辑处理，而BeanPostProcessor更加通用，比如是否需要感知当前环境的上下文等更具有通用性的逻辑。

一、使用BeanPostProcessor来完成Bean实例化前、后处理

　　BeanPostProcessor接口定义了两个方法，postProcessBeforeInitialization和postProcessAfterInitialization。一看名字便一目了然它们各自的作用，那就是在初始化的前后进行预处理和后处理。问题的关键在于容器启动后，BeanFactory是怎么感知到这些BeanPostProcessor的存在呢？或者说我们自定义的BeanPostProcessor怎么能够集成到框架中，让容器感知和使用我们自定义的processor？首先，我们要找到BeanFactory对BeanPostProcessor的处理逻辑代码,这段代码在AbstractAutowireCapableBeanFactory类的initializeBean方法中：

Object wrappedBean = bean; //进入initializeBean方法之前，已经构造了一个Bean对象，不过未经初始化
if (mbd == null || !mbd.isSynthetic()) {
    wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName); //前处理
}

try {
    invokeInitMethods(beanName, wrappedBean, mbd);//这里有机会调用Bean的afterPropertySet方法以及自定义的初始化方法
}
catch (Throwable ex) {
    throw new BeanCreationException(
            (mbd != null ? mbd.getResourceDescription() : null),
                    beanName, "Invocation of init method failed", ex);
}

if (mbd == null || !mbd.isSynthetic()) {
    wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);//后处理
}
return wrappedBean;

再进一步看applyBeanPostProcessorsBeforeInitialization方法。

Object result = existingBean;
// 在这里容器会遍历所有已经注册的BeanPostProcessor，无论是spring框架自身的还是我们自定义的。
for (Iterator it = getBeanPostProcessors().iterator(); it.hasNext();) {
    BeanPostProcessor beanProcessor = (BeanPostProcessor) it.next();
    result = beanProcessor.postProcessBeforeInitialization(result, beanName);
}
return result;

可以看到，我们完全有机会在afterPropertySet方法之前就对Bean进行操作，我们只要在BeanFactory中注册我们的BeanPostProcessor（在BeanFactory中注册我们的processor），那么就会在BeanFactory加载Bean的过程中，回调我们自己的BeanPostProcessor来完成我们的动作（上面代码中循环查找所有注册的BeanPostProcessor）。不过使用BeanPostProcessor带来的一个问题就是任何Bean的加载都会调用你注册过的这个processor，所以一些个性化的业务初始化操作放在这里是不合适的，业务初始化操作应该放到afterPropertySet（需要实现InitializingBean接口，侵入性较大）或者自定义初始化方法（需要在bean配置文件中指定init-method参数，侵入性较小）中完成。所以，BeanPostProcessor的使用应该是通用的业务逻辑处理。比如我们经常使用到的自动绑定（Autowired）就是使用BeanPostProcessor来完成的。我们来简单看一下处理autowired的这个processor是如何完成自动绑定成员变量和方法参数的。Autowired的processor类是：

AutowiredAnnotationBeanPostProcessor.class

autowired的过程都是在bean实例化之后做的，所以我们看postProcessAfterInitialization方法的具体实现。

// 根据当前bean对象的class信息得到使用注解autowired的成员变量和方法
InjectionMetadata metadata = findAutowiringMetadata(bean.getClass());
try {
/*
// 实现了将容器中的bean注入到当前对象成员变量的过程。这里之所以能够拿到容器中的其他bean，是因为AutowiredAnnotationBeanPostProcessor实现了BeanFactoryAware接口，从而得到当前容器的BeanFactory。另外具体看进去里面的实现，autowired的实现实现方式是通过byType实现的。

*/
    metadata.injectFields(bean, beanName);
}
catch (Throwable ex) {
    throw new BeanCreationException(beanName, "Autowiring of fields failed", ex);
}
return true;

spring对bean进行初始化的过程默认使用set方法注入。而且属性注入是在初始化bean之前（参照AbstractAutowireCapableBeanFactory类的doCreateBean方法），也就是说我们的autowired方式应该是在set方法注入之后，autowired是会覆盖set方法注入的属性。我们可以做以下实验来验证我们的猜测：我们在Apple中准备注入另一个Bean seed，同时使用了set方法和autowired。Apple类中代码部分如下：

@Autowired
@Qualifier("seed1")
private Seed seed;

public Sort getSeed() {
    return seed;
}

public void setSeed(Seed seed) {
    this.seed = seed;
}

配置文件如下：

<bean id="apple" class="com.alibaba.china.Apple" >
        <property name="seed">
            <ref bean="seed0" />
        </property>
</bean>

<bean id="seed0" class="com.alibaba.china.Seed" >
        <property name="seedName">
            <value>苹果种子</value>
        </property>
</bean>

<bean id="seed1" class="com.alibaba.china.Seed">
        <property name="seedName">
            <value>Apple Seed</value>
        </property>
</bean>

　　我们用set方法注入seed0，用自动绑定的方式注入seed1。由于BeanPostProcessor在初始化过程中执行，在set属性注入之后，所以预期结果seed1被注入。但是运行结果发现是seed0注入了apple对象。

　　为什么会这样呢？经过调试发现，在使用set方法属性注入的过程之前，会处理一类特殊的BeanPostProcessor------InstantiationAwareBeanPostProcessor，它是BeanPostProcessor的扩展接口，但是容器会在set注入之前优先检查是否存在这类BeanPostProcessor，如果存在InstantiationAwareBeanPostProcessor先执行这类processor。而恰恰巧合的是，AutowiredAnnotationBeanPostProcessor是InstantiationAwareBeanPostProcessor的子类。所以autowired的动作在set方法前做了，set方法的属性覆盖了autowired的属性，所以在上述例子中seed0最终被成功注入到apple这个对象里面。我们用类图能更加形象地描述InstantiationAwareBeanPostProcessor与BeanPostProcessor接口：

当获取一个bean对象时，主要逻辑在AbstractAutowireCapableBeanFactory类的doCreateBean方法中。其父类中维护一个beanPostProcessors列表，我们可以在容器启动时加入我们的processor，在执行到doCreateBean中我们的processor会被回调。我们根据具体的需要去实现BeanPostProcessor接口或者InstantiationAwareBeanPostProcessor接口。前者主要是初始化前后的处理动作，而后者主要是执行实例化前后的逻辑。

ApplicationContext更加简单地使用BeanPostProcessor：

　　如果我们直接使用BeanFactory，需要把我们的BeanPostProcessor注册到BeanFactory上，否则BeanFactory感知不到我们的processor。而ApplicationContext则在此方面做了增强，我们只需在配置文件里面声明我们的BeanPostProcessor，ApplicationContext能够自动做到感知。ApplicationContext是如何做到的呢？我们不妨自己先猜想一下，如果让我们自己实现这个增强功能应该怎么做？大致方向就是自己去扫描配置文件，看所有的bean中有哪些是BeanPostProcessor，然后我们不分青红皂白一股脑把所有的BeanPostProcessor都注册进去。spring对ApplicationContext也正是这么实现的，具体的描述在另一片分享中更具体的提到：

二、