Boot更是封装了Spring#xff0c;遵循约定大于配置#xff0c;加上自动装配的机制。

很多时候我们只要引用了一个…Spring的核心思想就是容器当容器refresh的时候外部看上去风平浪静其实内部则是一片惊涛骇浪汪洋一片。

Spring

Boot更是封装了Spring遵循约定大于配置加上自动装配的机制。

很多时候我们只要引用了一个依赖几乎是零配置就能完成一个功能的装配。

我非常喜欢这种自动装配的机制所以在自己开发中间件和公共依赖工具的时候也会用到这个特性。

让使用者以最小的代价接入。

想要把自动装配玩的转就必须要了解Spring

对于bean的构造生命周期以及各个扩展接口。

当然了解了bean的各个生命周期也能促进我们加深对Spring

的理解。

业务代码也能合理利用这些扩展点写出更加漂亮的代码。

在网上搜索Spring

扩展点发现很少有博文说的很全的只有一些常用的扩展点的说明。

所以在这篇文章里我总结了几乎Spring

Spring

Boot所有的扩展接口以及各个扩展点的使用场景。

并且整理出了一个bean在Spring

内部从被加载到最后初始化完成所有可扩展点的顺序调用图。

从而我们也能窥探到bean是如何一步步加载到Spring

容器中的。

可扩展的接口启动调用顺序图以下是我整理的Spring

容器中Bean的生命周期内所有可扩展的点的调用顺序下面会一个个分析ApplicationContextInitializer“org.springframework.context.ApplicationContextInitializer这是整个spring容器在刷新之前初始化ConfigurableApplicationContext的回调接口简单来说就是在容器刷新之前调用此类的initialize方法。

这个点允许被用户自己扩展。

用户可以在整个spring容器还没被初始化之前做一些事情。

可以想到的场景可能为在最开始激活一些配置或者利用这时候class还没被类加载器加载的时机进行动态字节码注入等操作。

扩展方式为public

class

TestApplicationContextInitializer

implements

initialize(ConfigurableApplicationContext

applicationContext)

{System.out.println([ApplicationContextInitializer]);}

}因为这时候spring容器还没被初始化所以想要自己的扩展的生效有以下三种方式在启动类中用springApplication.addInitializers(new

TestApplicationContextInitializer())语句加入配置文件配置context.initializer.classescom.example.demo.TestApplicationContextInitializerSpring

SPI扩展在spring.factories中加入org.springframework.context.ApplicationContextInitializercom.example.demo.TestApplicationContextInitializerBeanDefinitionRegistryPostProcessor“org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor这个接口在读取项目中的beanDefinition之后执行提供一个补充的扩展点使用场景你可以在这里动态注册自己的beanDefinition可以加载classpath之外的bean扩展方式为:public

class

TestBeanDefinitionRegistryPostProcessor

implements

BeanDefinitionRegistryPostProcessor

{Overridepublic

postProcessBeanDefinitionRegistry(BeanDefinitionRegistry

registry)

{System.out.println([BeanDefinitionRegistryPostProcessor]

postProcessBeanDefinitionRegistry);}Overridepublic

void

postProcessBeanFactory(ConfigurableListableBeanFactory

beanFactory)

{System.out.println([BeanDefinitionRegistryPostProcessor]

}BeanFactoryPostProcessor“org.springframework.beans.factory.config.BeanFactoryPostProcessor这个接口是beanFactory的扩展接口调用时机在spring在读取beanDefinition信息之后实例化bean之前。

在这个时机用户可以通过实现这个扩展接口来自行处理一些东西比如修改已经注册的beanDefinition的元信息。

扩展方式为public

class

postProcessBeanFactory(ConfigurableListableBeanFactory

beanFactory)

{System.out.println([BeanFactoryPostProcessor]);}

}InstantiationAwareBeanPostProcessor“org.springframework.beans.factory.config.InstantiationAwareBeanPostProcessor该接口继承了BeanPostProcess接口区别如下BeanPostProcess接口只在bean的初始化阶段进行扩展注入spring上下文前后而InstantiationAwareBeanPostProcessor接口在此基础上增加了3个方法把可扩展的范围增加了实例化阶段和属性注入阶段。

该类主要的扩展点有以下5个方法主要在bean生命周期的两大阶段实例化阶段和初始化阶段下面一起进行说明按调用顺序为postProcessBeforeInstantiation实例化bean之前相当于new这个bean之前postProcessAfterInstantiation实例化bean之后相当于new这个bean之后postProcessPropertyValuesbean已经实例化完成在属性注入时阶段触发Autowired,Resource等注解原理基于此方法实现postProcessBeforeInitialization初始化bean之前相当于把bean注入spring上下文之前postProcessAfterInitialization初始化bean之后相当于把bean注入spring上下文之后使用场景这个扩展点非常有用

无论是写中间件和业务中都能利用这个特性。

比如对实现了某一类接口的bean在各个生命期间进行收集或者对某个类型的bean进行统一的设值等等。

扩展方式为public

class

TestInstantiationAwareBeanPostProcessor

implements

InstantiationAwareBeanPostProcessor

{Overridepublic

postProcessBeforeInitialization(Object

bean,

{System.out.println([TestInstantiationAwareBeanPostProcessor]

before

postProcessAfterInitialization(Object

bean,

{System.out.println([TestInstantiationAwareBeanPostProcessor]

after

postProcessBeforeInstantiation(Class?

beanClass,

{System.out.println([TestInstantiationAwareBeanPostProcessor]

before

postProcessAfterInstantiation(Object

bean,

{System.out.println([TestInstantiationAwareBeanPostProcessor]

after

postProcessPropertyValues(PropertyValues

pvs,

{System.out.println([TestInstantiationAwareBeanPostProcessor]

beanName);return

pvs;}SmartInstantiationAwareBeanPostProcessor“org.springframework.beans.factory.config.SmartInstantiationAwareBeanPostProcessor该扩展接口有3个触发点方法predictBeanType该触发点发生在postProcessBeforeInstantiation之前(在图上并没有标明因为一般不太需要扩展这个点)这个方法用于预测Bean的类型返回第一个预测成功的Class类型如果不能预测返回null当你调用BeanFactory.getType(name)时当通过bean的名字无法得到bean类型信息时就调用该回调方法来决定类型信息。

determineCandidateConstructors该触发点发生在postProcessBeforeInstantiation之后用于确定该bean的构造函数之用返回的是该bean的所有构造函数列表。

用户可以扩展这个点来自定义选择相应的构造器来实例化这个bean。

getEarlyBeanReference该触发点发生在postProcessAfterInstantiation之后当有循环依赖的场景当bean实例化好之后为了防止有循环依赖会提前暴露回调方法用于bean实例化的后置处理。

这个方法就是在提前暴露的回调方法中触发。

扩展方式为public

class

TestSmartInstantiationAwareBeanPostProcessor

implements

SmartInstantiationAwareBeanPostProcessor

{Overridepublic

{System.out.println([TestSmartInstantiationAwareBeanPostProcessor]

predictBeanType

determineCandidateConstructors(Class?

beanClass,

{System.out.println([TestSmartInstantiationAwareBeanPostProcessor]

beanName);return

{System.out.println([TestSmartInstantiationAwareBeanPostProcessor]

beanName);return

}BeanFactoryAware“org.springframework.beans.factory.BeanFactoryAware这个类只有一个触发点发生在bean的实例化之后注入属性之前也就是Setter之前。

这个类的扩展点方法为setBeanFactory可以拿到BeanFactory这个属性。

使用场景为你可以在bean实例化之后但还未初始化之前拿到

BeanFactory在这个时候可以对每个bean作特殊化的定制。

也或者可以把BeanFactory拿到进行缓存日后使用。

扩展方式为public

class

{System.out.println([TestBeanFactoryAware]

beanFactory.getBean(TestBeanFactoryAware.class).getClass().getSimpleName());}

}ApplicationContextAwareProcessor“org.springframework.context.support.ApplicationContextAwareProcessor该类本身并没有扩展点但是该类内部却有6个扩展点可供实现

这些类触发的时机在bean实例化之后初始化之前可以看到该类用于执行各种驱动接口在bean实例化之后属性填充之后通过执行以上红框标出的扩展接口来获取对应容器的变量。

所以这里应该来说是有6个扩展点这里就放一起来说了EnvironmentAware用于获取EnviromentAware的一个扩展类这个变量非常有用

可以获得系统内的所有参数。

当然个人认为这个Aware没必要去扩展因为spring内部都可以通过注入的方式来直接获得。

EmbeddedValueResolverAware用于获取StringValueResolver的一个扩展类

StringValueResolver用于获取基于String类型的properties的变量一般我们都用Value的方式去获取如果实现了这个Aware接口把StringValueResolver缓存起来通过这个类去获取String类型的变量效果是一样的。

ResourceLoaderAware用于获取ResourceLoader的一个扩展类ResourceLoader可以用于获取classpath内所有的资源对象可以扩展此类来拿到ResourceLoader对象。

ApplicationEventPublisherAware用于获取ApplicationEventPublisher的一个扩展类ApplicationEventPublisher可以用来发布事件结合ApplicationListener来共同使用下文在介绍ApplicationListener时会详细提到。

这个对象也可以通过spring注入的方式来获得。

MessageSourceAware用于获取MessageSource的一个扩展类MessageSource主要用来做国际化。

ApplicationContextAware用来获取ApplicationContext的一个扩展类ApplicationContext应该是很多人非常熟悉的一个类了就是spring上下文管理器可以手动的获取任何在spring上下文注册的bean我们经常扩展这个接口来缓存spring上下文包装成静态方法。

同时ApplicationContext也实现了BeanFactoryMessageSourceApplicationEventPublisher等接口也可以用来做相关接口的事情。

BeanNameAware“org.springframework.beans.factory.BeanNameAware可以看到这个类也是Aware扩展的一种触发点在bean的初始化之前也就是postProcessBeforeInitialization之前这个类的触发点方法只有一个setBeanName使用场景为用户可以扩展这个点在初始化bean之前拿到spring容器中注册的的beanName来自行修改这个beanName的值。

扩展方式为public

class

{System.out.println([BeanNameAware]

name);}

}PostConstruct“javax.annotation.PostConstruct这个并不算一个扩展点其实就是一个标注。

其作用是在bean的初始化阶段如果对一个方法标注了PostConstruct会先调用这个方法。

这里重点是要关注下这个标准的触发点这个触发点是在postProcessBeforeInitialization之后InitializingBean.afterPropertiesSet之前。

使用场景用户可以对某一方法进行标注来进行初始化某一个属性扩展方式为public

class

constructor);}PostConstructpublic

void

init(){System.out.println([PostConstruct]

NormalBeanA);}

}InitializingBean“org.springframework.beans.factory.InitializingBean这个类顾名思义也是用来初始化bean的。

InitializingBean接口为bean提供了初始化方法的方式它只包括afterPropertiesSet方法凡是继承该接口的类在初始化bean的时候都会执行该方法。

这个扩展点的触发时机在postProcessAfterInitialization之前。

使用场景用户实现此接口来进行系统启动的时候一些业务指标的初始化工作。

扩展方式为public

class

InitializingBean{Overridepublic

void

{System.out.println([InitializingBean]

NormalBeanA);}

}FactoryBean“org.springframework.beans.factory.FactoryBean一般情况下Spring通过反射机制利用bean的class属性指定支线类去实例化bean在某些情况下实例化Bean过程比较复杂如果按照传统的方式则需要在bean中提供大量的配置信息。

配置方式的灵活性是受限的这时采用编码的方式可能会得到一个简单的方案。

Spring为此提供了一个org.springframework.bean.factory.FactoryBean的工厂类接口用户可以通过实现该接口定制实例化Bean的逻辑。

FactoryBean接口对于Spring框架来说占用重要的地位Spring自身就提供了70多个FactoryBean的实现。

它们隐藏了实例化一些复杂bean的细节给上层应用带来了便利。

从Spring3.0开始FactoryBean开始支持泛型即接口声明改为FactoryBeanT的形式使用场景用户可以扩展这个类来为要实例化的bean作一个代理比如为该对象的所有的方法作一个拦截在调用前后输出一行log模仿ProxyFactoryBean的功能。

扩展方式为public

class

FactoryBeanTestFactoryBean.TestFactoryInnerBean

{Overridepublic

TestFactoryBean.TestFactoryInnerBean

getObject()

{System.out.println([FactoryBean]

getObject);return

TestFactoryBean.TestFactoryInnerBean();}Overridepublic

Class?

TestFactoryBean.TestFactoryInnerBean.class;}Overridepublic

boolean

}SmartInitializingSingleton“org.springframework.beans.factory.SmartInitializingSingleton这个接口中只有一个方法afterSingletonsInstantiated其作用是是

在spring容器管理的所有单例对象非懒加载对象初始化完成之后调用的回调接口。

其触发时机为postProcessAfterInitialization之后。

使用场景用户可以扩展此接口在对所有单例对象初始化完毕后做一些后置的业务处理。

扩展方式为public

class

{System.out.println([TestSmartInitializingSingleton]);}

}CommandLineRunner“org.springframework.boot.CommandLineRunner这个接口也只有一个方法run(String...

args)触发时机为整个项目启动完毕后自动执行。

如果有多个CommandLineRunner可以利用Order来进行排序。

使用场景用户扩展此接口进行启动项目之后一些业务的预处理。

扩展方式为public

class

{System.out.println([TestCommandLineRunner]);}

}DisposableBean“org.springframework.beans.factory.DisposableBean这个扩展点也只有一个方法destroy()其触发时机为当此对象销毁时会自动执行这个方法。

比如说运行applicationContext.registerShutdownHook时就会触发这个方法。

扩展方式为public

class

{System.out.println([DisposableBean]

NormalBeanA);}

}ApplicationListener“org.springframework.context.ApplicationListener准确的说这个应该不算springspringboot当中的一个扩展点ApplicationListener可以监听某个事件的event触发时机可以穿插在业务方法执行过程中用户可以自定义某个业务事件。

但是spring内部也有一些内置事件这种事件可以穿插在启动调用中。

我们也可以利用这个特性来自己做一些内置事件的监听器来达到和前面一些触发点大致相同的事情。

接下来罗列下spring主要的内置事件ContextRefreshedEventApplicationContext

被初始化或刷新时该事件被发布。

这也可以在ConfigurableApplicationContext接口中使用

refresh()方法来发生。

此处的初始化是指所有的Bean被成功装载后处理Bean被检测并激活所有Singleton

Bean

被预实例化ApplicationContext容器已就绪可用。

ContextStartedEvent当使用

start()

ApplicationContext时该事件被发布。

你可以调查你的数据库或者你可以在接受到这个事件后重启任何停止的应用程序。

ContextStoppedEvent当使用

ConfigurableApplicationContext接口中的

时发布这个事件。

你可以在接受到这个事件后做必要的清理的工作ContextClosedEvent当使用

ConfigurableApplicationContext接口中的

close()方法关闭

时该事件被发布。

一个已关闭的上下文到达生命周期末端它不能被刷新或重启RequestHandledEvent这是一个

web-specific

请求已经被服务。

只能应用于使用DispatcherServlet的Web应用。

在使用Spring作为前端的MVC控制器时当Spring处理用户请求结束后系统会自动触发该事件最后我们从这些Spring

Spring

Boot的扩展点当中大致可以窥视到整个bean的生命周期。

在业务开发或者写中间件业务的时候可以合理利用spring提供给我们的扩展点在Spring启动的各个阶段内做一些事情。

以达到自定义初始化的目的。