BeanPostProcessor
和BeanFactoryPostProcessor
是Spring
中两个最重要的扩展的。如果说BeanFactoryPostProcessor
是面向IoC
进行扩展,BeanPostProcessor
就是面向Bean
进行扩展。
从上面类结构图可以看出,BeanPostProcessor
是一个顶层接口,下面有衍生出几个接口,实现对Bean
创建、初始化等各个阶段进行更细化的扩展,所以BeanPostProcessor
要比BeanFactoryPostProcessor
复杂一些,可以实现更多扩展场景。
BeanPostProcessor
被注册到IoC
中才能起作用,在refresh()
方法中registerBeanPostProcessors(beanFactory);
这一语句完成BeanPostProcessor
的注册工作,注册使用:addBeanPostProcessor(BeanPostProcessor beanPostProcessor)
方法完成。
注册BeanPostProcessor
也涉及到先后顺序关系,大致逻辑总结如下:
1、获取实现PriorityOrdered接口的BeanPostProcessor,然后通过getBean()方法实例化,排序后注册到容器中;
2、获取实现Ordered接口的BeanPostProcessor,然后通过getBean()方法实例化,排序后注册到容器中;
3、获取常规没有实现PriorityOrdered和Ordered接口BeanPostProcessor,然后通过getBean()方法实例化,注册到容器中;
4、上述步骤中MergedBeanDefinitionPostProcessor类型会单独存储到internalPostProcessors集合中,排序后保证放到末尾
5、最后移除ApplicationListenerDetector重新追加到最末尾
上面只是BeanPostProcessor
注册先后顺序关系,并不会涉及到BeanPostProcessor
的执行,由于BeanPostProcessor
扩展出几个子类,下面我们来分析下每个子类的执行时机。
接口定义见下:
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;
}
}
之前分析IoC
容器启动流程时,介绍过initializeBean()
方法完成Bean
的init-method
初始化工作,BeanPostProcessor
就是在init-method
执行前后进行扩展。
protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
Object wrappedBean = bean;
if (mbd == null || !mbd.isSynthetic()) {
//触发BeanPostProcessor#postProcessBeforeInitialization()方法执行
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
//执行init-method方法
invokeInitMethods(beanName, wrappedBean, mbd);
if (mbd == null || !mbd.isSynthetic()) {
//触发BeanPostProcessor#postProcessAfterInitialization()方法执行
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
return wrappedBean;
}
再来看下这两个方法的调用逻辑:
public Object applyBeanPostProcessorsBeforeInitialization(Object existingBean, String beanName)
throws BeansException {
Object result = existingBean;
for (BeanPostProcessor processor : getBeanPostProcessors()) {
Object current = processor.postProcessBeforeInitialization(result, beanName);
if (current == null) {
return result;
}
result = current;
}
return result;
}
如果有postProcessBeforeInitialization()
方法返回null
,则表示该扩展点提前结束,不再需要继续执行后续BeanPostProcessor
的postProcessBeforeInitialization
方法。
再来看下postProcessAfterInitialization()
方法执行逻辑是一样的:
@Override
public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
throws BeansException {
Object result = existingBean;
for (BeanPostProcessor processor : getBeanPostProcessors()) {
Object current = processor.postProcessAfterInitialization(result, beanName);
if (current == null) {
return result;
}
result = current;
}
return result;
}
invokeInitMethods(beanName, wrappedBean, mbd);
方法执行Bean
的init-method
方法进行初始化,进入这个方法可以发现,这里只会执行实现InitializingBean
和@Bean(initMethod="xxx")
这两种方式设置的init-method
方法,我们平时使用很多的@PostConstruct
注解方式,其实是通过InitDestroyAnnotationBeanPostProcessor
这个扩展类实现:
InitDestroyAnnotationBeanPostProcessor
类实现了DestructionAwareBeanPostProcessor
和MergedBeanDefinitionPostProcessor
这两个接口,间接方式继承BeanPostProcessor
。InitDestroyAnnotationBeanPostProcessor
就是在postProcessBeforeInitialization()
方法中完成了对@PostConstruct
注解方法的调用,所以其执行优先级比InitializingBean
和@Bean(initMethod="xxx")
这两种方式更加靠前。
如果你需要在init-method
等Bean
的初始化执行前后进行扩展,可以使用此接口实现。比如:判断Bean
是否是线程池类,如果是则统一设置管理的线程名前缀:
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
if (bean instanceof ThreadPoolTaskExecutor) {
((ThreadPoolTaskExecutor) bean).setThreadNamePrefix("Post-");
}
return bean;
}
还比如ApplicationListenerDetector
在postProcessAfterInitialization()
方法中实现将ApplicationListener
类型的单例Bean
注册到事件多播器上,实现对事件的监听:
public Object postProcessAfterInitialization(Object bean, String beanName) {
if (bean instanceof ApplicationListener) {
Boolean flag = this.singletonNames.get(beanName);
if (Boolean.TRUE.equals(flag)) {
// 如果当前 ApplicationListener bean scope 是 singleton 单例模式,则将它注册到应用的事件多播器上
this.applicationContext.addApplicationListener((ApplicationListener<?>) bean);
}
else if (Boolean.FALSE.equals(flag)) {
// 如果ApplicationListener bean scope 不是 singleton 单例模式,则尝试输出警告日志,说明情况,并移除
//所以ApplicationListener类型的只能是单例模式才会起作用
this.singletonNames.remove(beanName);
}
}
return bean;
}
还比如ApplicationContextAwareProcessor
这个就是在postProcessBeforeInitialization()
方法中实现如ApplicationContextAware
、EnvironmentAware
等*Aware
接口注入功能。实现原理非常简单,就是判断Bean
是否实现接口,然后通过setter
方式注入即可:
private void invokeAwareInterfaces(Object bean) {
if (bean instanceof EnvironmentAware) {
((EnvironmentAware) bean).setEnvironment(this.applicationContext.getEnvironment());
}
if (bean instanceof EmbeddedValueResolverAware) {
((EmbeddedValueResolverAware) bean).setEmbeddedValueResolver(this.embeddedValueResolver);
}
if (bean instanceof ResourceLoaderAware) {
((ResourceLoaderAware) bean).setResourceLoader(this.applicationContext);
}
if (bean instanceof ApplicationEventPublisherAware) {
((ApplicationEventPublisherAware) bean).setApplicationEventPublisher(this.applicationContext);
}
if (bean instanceof MessageSourceAware) {
((MessageSourceAware) bean).setMessageSource(this.applicationContext);
}
if (bean instanceof ApplicationContextAware) {
((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
}
}
前面分析BeanPostProcessor
接口是在Bean的init-method
方法执行前后进行扩展,其子接口InstantiationAwareBeanPostProcessor
则可以在Bean
的创建前后进行扩展,所以此扩展比BeanPostProcessor
扩展更靠前。
接口定义见下:
public interface InstantiationAwareBeanPostProcessor extends BeanPostProcessor {
//Bean创建之前回调该方法,beanClass就是将要被创建的Bean对应的Class信息
@Nullable
default Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
return null;
}
//Bean创建之后回调该方法,参数bean就是创建完成的Bean对象
default boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
return true;
}
//postProcessProperties()方法在postProcessAfterInstantiation()方法之后紧挨着执行,其提供PropertyValues类型入参,所以在该方法中可以实现依赖操作
@Nullable
default PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName)
throws BeansException {
return null;
}
//这个方法标注@Deprecated已经被废弃了,被postProcessProperties()方法取代了
@Deprecated
@Nullable
default PropertyValues postProcessPropertyValues(
PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
return pvs;
}
}
createBean()
方法中Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
这条语句中会触发对postProcessBeforeInstantiation()
方法的执行。
protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
throws BeanCreationException {
Object bean = resolveBeforeInstantiation(beanName, mbdToUse);//触发对postProcessBeforeInstantiation()方法的执行
if (bean != null) {
return bean;
}
...
Object beanInstance = doCreateBean(beanName, mbdToUse, args);//创建Bean实例(一般真正创建Bean的方法)
...
}
InstantiationAwareBeanPostProcessor#postProcessBeforeInstantiation()
方法有个重要特性:如果该方法返回非null
结果,则表示Bean
提前创建完成,同时也会忽略掉后续的依赖注入、init-method
初始化等步骤执行,最后只需要执行下BeanPostProcessor#postProcessAfterInitialization
这个方法则整个Bean
的创建流程就全部完成。
总结:在创建对象之前调用了postProcessBeforeInstantiation
方法可以实现给扩展点一次创建代理的机会,如果代理对象返回不为空则不再继续常规方式创建Bean
。
我们再来看下InstantiationAwareBeanPostProcessor
接口中定义的另两个方法执行时机,Bean
创建完成后会执行populateBean()
进行依赖注入,它们就是在这个方法中进行触发回调,pupulateBean()
方法大致见下:
protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
//执行InstantiationAwareBeanPostProcessor#postProcessAfterInstantiation方法回调
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
return;
}
}
}
}
// 注解注入:后置处理器ibp#postProcessProperties,大名鼎鼎的@Autowired就是在这处理的。
PropertyDescriptor[] filteredPds = null;
if (hasInstAwareBpps) {
//执行InstantiationAwareBeanPostProcessor#postProcessProperties方法回调
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
PropertyValues pvsToUse = ibp.postProcessProperties(pvs, bw.getWrappedInstance(), beanName);
if (pvsToUse == null) {
if (filteredPds == null) {
//获取出对象的所有set get方法,现在是有一个 getClass()方法,因为继承了Object, 没什么其他卵用
filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
}
//postProcessPropertyValues方法已废弃,被postProcessProperties替代
pvsToUse = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
if (pvsToUse == null) {
return;
}
}
pvs = pvsToUse;
}
}
}
if (pvs != null) {
applyPropertyValues(beanName, mbd, bw, pvs);
}
}
上面代码翻译下大概就是:先执行InstantiationAwareBeanPostProcessor#postProcessAfterInstantiation
方法回调,然后再去执行InstantiationAwareBeanPostProcessor#postProcessProperties
,最后再去执行applyPropertyValues()
完成PropertyValue
方式的依赖注入。这里有个大名鼎鼎的@Autowired
、@Value
方式的依赖注入,就是借助于InstantiationAwareBeanPostProcessor#postProcessProperties()
方法实现,这个实现类就是:AutowiredAnnotationBeanPostProcessor
,简单看下依赖注入逻辑:
public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) {
/**
* 从缓存中找到此类的@Autowired、@Value注解元数据,尝试注入
* InjectionMetadata,持有待注入的元数据信息,执行inject()方法,开始注入属性或方法参数。
*/
InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
try {
//为beanName填充上属性bean
metadata.inject(bean, beanName, pvs);
}
catch (BeanCreationException ex) {
throw ex;
}
catch (Throwable ex) {
throw new BeanCreationException(beanName, "Injection of autowired dependencies failed", ex);
}
return pvs;
}
这里有意义的代码就两行:
1、InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
获取Bean
中需要依赖注入注入的元素,封装成一个InjectionMetadata
对象,该对象有两个重要属性:
targetClass
指定目标对象的Class
;Collection<InjectedElement> injectedElements
:目标对象中每个需要依赖注入的元素都会封装成一个InjectedElement
,然后存储到该集合中。根据@Autowired
/@Value
注解到字段上还是方法上,InjectedElement
又可以分为两类:AutowiredFieldElement
和AutowiredMethodElement
。2、metadata.inject(bean, beanName, pvs);
:这个方法内部就是循环,对每个依赖元素InjectedElement
调用inject()方法
if (!elementsToIterate.isEmpty()) {
for (InjectedElement element : elementsToIterate) {
if (logger.isTraceEnabled()) {
logger.trace("Processing injected element of bean '" + beanName + "': " + element);
}
element.inject(target, beanName, pvs);
}
}
比如我们一般将@Autowired
标注到字段上,则这里会触发AutowiredFieldElement#inject()
方法执行:
protected void inject(Object bean, @Nullable String beanName, @Nullable PropertyValues pvs) throws Throwable {
Field field = (Field) this.member;//依赖注入字段
Object value;//存储需要注入的值
if (this.cached) {//如果已被缓存,则直接先从缓存中获取依赖注入值
value = resolvedCachedArgument(beanName, this.cachedFieldValue);
}
else {//还未被缓存过
//1.DependencyDescriptor:用于对该依赖注入描述信息
DependencyDescriptor desc = new DependencyDescriptor(field, this.required);
desc.setContainingClass(bean.getClass());
Set<String> autowiredBeanNames = new LinkedHashSet<>(1);
Assert.state(beanFactory != null, "No BeanFactory available");
TypeConverter typeConverter = beanFactory.getTypeConverter();
try {
/*
2.查找依赖注入的值
比如:
@Autowired
private TestService03 testService03;
这个value就是从IoC容器中查找到的TestService03对象
还比如:@Value("${spring.name}"),这个value就是从Spring上下文环境变量中解析出的spring.name变量值
*/
value = beanFactory.resolveDependency(desc, beanName, autowiredBeanNames, typeConverter);
}
catch (BeansException ex) {
throw new UnsatisfiedDependencyException(null, beanName, new InjectionPoint(field), ex);
}
//3.下面synchronized块主要实现缓存功能,已被解析过的包装成ShortcutDependencyDescriptor类型,上面resolvedCachedArgument对这种类型会特殊处理
synchronized (this) {
if (!this.cached) {
if (value != null || this.required) {
this.cachedFieldValue = desc;
registerDependentBeans(beanName, autowiredBeanNames);
if (autowiredBeanNames.size() == 1) {
String autowiredBeanName = autowiredBeanNames.iterator().next();
if (beanFactory.containsBean(autowiredBeanName) &&
beanFactory.isTypeMatch(autowiredBeanName, field.getType())) {
this.cachedFieldValue = new ShortcutDependencyDescriptor(
desc, autowiredBeanName, field.getType());
}
}
}
else {
this.cachedFieldValue = null;
}
this.cached = true;
}
}
}
//4.查找到的依赖值不为null,则使用反射方式注入,因为是通过反射方式,所以@Autowired、@Value是不需要setter/getter方法也可以注入
if (value != null) {
//通过反射方式将查找到的需要依赖注入的值设置到对象实例中
ReflectionUtils.makeAccessible(field);
field.set(bean, value);
}
}
InstantiationAwareBeanPostProcessor
还有个子接口:SmartInstantiationAwareBeanPostProcessor
,其定义如下:
public interface SmartInstantiationAwareBeanPostProcessor extends InstantiationAwareBeanPostProcessor {
//推断类型
@Nullable
default Class<?> predictBeanType(Class<?> beanClass, String beanName) throws BeansException {
return null;
}
//根据一定规则推断出Bean中优选的构造方法
@Nullable
default Constructor<?>[] determineCandidateConstructors(Class<?> beanClass, String beanName)
throws BeansException {
return null;
}
default Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
return bean;
}
}
SmartInstantiationAwareBeanPostProcessor
接口有三个方法,在实例创建前智能判断实例类型、智能判断构造函数、提起获取暴露Bean
引用,该接口主要是spring
框架内部使用,开发时很少去扩展该接口。
这里主要注意第三个方法:getEarlyBeanReference()
,这个扩展方法主要与Spring
中的循环依赖有关系。前面分析IoC
容器启动时分析过:为了解决Spring
中的循环依赖问题,在doCreateBean()
方法内部,会将刚创建还未来得及进行依赖注入和初始化的半成品Bean
提前暴露出去,addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
,注意这里不是直接将Bean
暴露出去,而是通过() -> getEarlyBeanReference(beanName, mbd, bean)
这句将Bean
包装成ObjectFactory
类型再暴露出去。
这里的一个核心就是:为什么不直接暴露Bean
,而是将Bean
包装成ObjectFactory
再去暴露?将Bean
包装成ObjectFactory
再去暴露,调用getObject()
方法时会触发SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference
方法回调。
分析到这里,还不够完善,因为你可能会问:那这个方法回调又可以给我们解决什么问题呢?
可以利用Spring AOP
原理来回答这个问题,Spring AOP
主要基于AnnotationAwareAspectJAutoProxyCreator
这个类实现,这个类实现了BeanPostProcessor
接口,在postProcessAfterInitialization()
方法中对创建完成的Bean
采用动态代理方式将增强逻辑织入进去。
如果存在这样情况:A
依赖B
,B
同时依赖A
,这就是所说的Spring
循环依赖,但是如果我们对A
采用了AOP
增强,这个过程会是怎样情况呢?
init-method
初始化方法后,postProcessAfterInitialization()
执行时会给A通过动态代理方式织入增强逻辑;这时,步骤3中给B注入的是A的原生对象,但是步骤6会给A创建一个代理对象,但是B中这时还是原生对象没法改变,这就会导致有的依赖注入的是原生对象,有的依赖注入的是代理对象,会出现错乱问题。如何解决呢?这个就是SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference
这个扩展点作用。
A对象提前暴露时,利用ObjectFactory包装了一层,B对象在进行依赖注入时获取到对象A时,不是直接返回A,而是触发getEarlyBeanReference()
方法执行,AnnotationAwareAspectJAutoProxyCreator
类在getEarlyBeanReference()
方法中实现判断A需要做动态代理,则对A进行动态代理后返回,这时B中依赖注入的就不是原生对象。
总结:SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference()
方法是在循环依赖场景下,对提前暴露的Bean
可以通过该扩展点进行处理。只有因为存在循环依赖,才会导致需要需要获取那些提前暴露的Bean
时才会触发该扩展点,所以,理解这个扩展点关键在于你对Spring
循环依赖的理解。
DestructionAwareBeanPostProcessor
是BeanPostProcessor
子接口,其定义如下:
public interface DestructionAwareBeanPostProcessor extends BeanPostProcessor {
//Bean销毁前回调方法
void postProcessBeforeDestruction(Object bean, String beanName) throws BeansException;
//可以根据Bean进行过滤,哪些Bean需要用到当前这个回调
default boolean requiresDestruction(Object bean) {
return true;
}
}
从名称就可以看出,该扩展主要用于Bean
销毁之前,回调时机在:DisposableBeanAdapter#destroy()
public void destroy() {
//调用DestructionAwareBeanPostProcessor#postProcessBeforeDestruction,Bean销毁之前回调接口
if (!CollectionUtils.isEmpty(this.beanPostProcessors)) {
for (DestructionAwareBeanPostProcessor processor : this.beanPostProcessors) {
processor.postProcessBeforeDestruction(this.bean, this.beanName);
}
}
...
((DisposableBean) this.bean).destroy();//调用DisposableBean.destroy()
...
}
DestructionAwareBeanPostProcessor
接口有个实现类InitDestroyAnnotationBeanPostProcessor
,实现对@PreDestroy
注解支持。该扩展接口本身是比较简单的,后续分析Bean
生命周期destroy
流程整体梳理。
MergedBeanDefinitionPostProcessor
public interface MergedBeanDefinitionPostProcessor extends BeanPostProcessor {
void postProcessMergedBeanDefinition(RootBeanDefinition beanDefinition, Class<?> beanType, String beanName);
//Spring5.1新增接口,实现BeanDefinition重置通知,一般该方法实现重置前清理metadata等元数据缓存
default void resetBeanDefinition(String beanName) {
}
}
我们主要看下postProcessMergedBeanDefinition()
方法调用时机:
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
throws BeanCreationException {
//1.创建对象
//2.执行MergedBeanDefinitionPostProcessor#postProcessMergedBeanDefinition回调方法
synchronized (mbd.postProcessingLock) {
if (!mbd.postProcessed) {
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
mbd.postProcessed = true;
}
}
//3.提前暴露Bean
//4.populateBean(beanName, mbd, instanceWrapper);
//5.exposedObject = initializeBean(beanName, exposedObject, mbd);
}
MergedBeanDefinitionPostProcessor#postProcessMergedBeanDefinition
发生在Bean
刚创建完成,Bean
还未提前暴露之前。MergedBeanDefinitionPostProcessor
在Spring
中有很多的应用,比如:AutowiredAnnotationBeanPostProcessor
、CommonAnnotationBeanPostProcessor
、InitDestroyAnnotationBeanPostProcessor
等。这个扩展的一般套路是和其它扩展点一起使用,其起到一个帮手角色,postProcessMergedBeanDefinition
将需要处理的注解信息解析成元数据信息缓存起来,其它扩展点就可以从缓存中获取需要处理的注解信息进行处理。有关这扩展点更多的情况会在后续案例分析中再详细分析。
BeanFactoryPostProcessor
和BeanPostProcessor
是Spring
提供的两个最核心、最基础的扩展方式:一个面向IoC
进行扩展,另一个面向Bean
的创建流程进行各种扩展。BeanPostProcessor
及其子类实现了对Bean
创建过程中的各种扩展:Bean
创建前后、Bean
初始化前后、获取提前暴露对象前等等这些。Spring中大量注解简化了我们使用框架的复杂性,而这些注解很大一部分就是基于这些扩展进行处理,学习这些扩展点可以帮助我们更好的熟悉Spring
的运行机理,同时可以在开发中帮助我们灵活的实现各种功能扩展。