为爱奔跑


无论在家出家。必须上敬下和。忍人所不能忍。行人所不能行。代人之劳。成人之美。静坐长思己过。闲谈不论人非。行住坐卧。穿衣吃饭。从幕至朝。一名佛号。不令间断。或小声念。或默念。除念佛外。不起别念。若或妄念一起。当下就要教他消灭。当生惭愧心及忏悔心。从有修持。总觉我工夫很浅。不自矜夸。只管自家。不管人家。只看好样子。不看坏样子。看一切人都是菩萨。唯我一人是凡夫!

  在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也正是这么实现的,具体的描述在另一片分享中更具体的提到:

二、

posted on 2016-09-01 10:38  RunforLove  阅读(1276)  评论(0编辑  收藏  举报