1.配景
Spring的焦颔首脑就是容器，当容器refresh的时间，外部看上去风平浪静，着实内部则是一片惊涛骇浪，汪洋一片。Springboot更是封装了Spring，依照约定大于设置，加上主动装配的机制。很多时间我们只要引用了一个依赖，几乎是零设置就能完成一个功能的装配。我非常喜好这种主动装配的机制，以是在本身开辟中心件和公共依赖工具的时间也会用到这个特性。让使用者以最小的代价接入。想要把主动装配玩的转，就必须要相识spring对于bean的构造生命周期以及各个扩展接口。固然相识了bean的各个生命周期也能促进我们加深对spring的明确。业务代码也能公道使用这些扩展点写出更加漂亮的代码。
在网上搜索spring扩展点，发现很少有博文说的很全的，只有一些常用的扩展点的阐明。以是在这篇文章里，我总结了几乎Spring & Springboot全部的扩展接口，以及各个扩展点的使用场景。而且整理出了一个bean在spring内部从被加载到末了初始化完玉成部可扩展点的次序调用图。从而我们也能窥伺到bean是如何一步步加载到spring容器中的。
2.可扩展的接口启动调用次序图
以下是我整理的spring容器中Bean的生命周期内全部可扩展的点的调用次序，下面会一个个分析
3.ApplicationContextInitializer
org.springframework.context.ApplicationContextInitializer这是整个spring容器在革新之前初始化ConfigurableApplicationContext的回调接口，简单来说，就是在容器革新之前调用此类的initialize方法。这个点答应被用户本身扩展。用户可以在整个spring容器还没被初始化之前做一些事故。
可以想到的场景大概为，在最开始激活一些设置，大概使用这时间class还没被类加载器加载的机遇，进办法态字节码注入等使用。
扩展方式为：
public class TestApplicationContextInitializer implements ApplicationContextInitializer {因为这时间spring容器还没被初始化，以是想要本身的扩展的收效，有以下三种方式：
- 在启动类中用springApplication.addInitializers(new TestApplicationContextInitializer())语句参加
- 设置文件设置context.initializer.classes=com.example.demo.TestApplicationContextInitializer
- Spring SPI扩展，在spring.factories中参加org.springframework.context.ApplicationContextInitializer=com.example.demo.TestApplicationContextInitializer
4.BeanDefinitionRegistryPostProcessor
org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor这个接口在读取项目中的beanDefinition之后实验，提供一个增补的扩展点使用场景：你可以在这里动态注册本身的beanDefinition，可以加载classpath之外的bean扩展方式为:
public class TestApplicationContextInitializer implements ApplicationContextInitializer { @Override public void initialize(ConfigurableApplicationContext applicationContext) { System.out.println("[ApplicationContextInitializer]"); }}5.BeanFactoryPostProcessor
org.springframework.beans.factory.config.BeanFactoryPostProcessor这个接口是beanFactory的扩展接口，调用机遇在spring在读取beanDefinition信息之后，实例化bean之前。
在这个机遇，用户可以通过实现这个扩展接口来自行处置惩罚一些东西，比如修改已经注册的beanDefinition的元信息。
扩展方式为：
public class TestBeanFactoryPostProcessor implements BeanFactoryPostProcessor {6.InstantiationAwareBeanPostProcessor
org.springframework.beans.factory.config.InstantiationAwareBeanPostProcessor该接口继承了BeanPostProcess接口，区别如下：
BeanPostProcess接口只在bean的初始化阶段举行扩展（注入spring上下文前后），而InstantiationAwareBeanPostProcessor接口在此根本上增长了3个方法，把可扩展的范围增长了实例化阶段和属性注入阶段。该类告急的扩展点有以下5个方法，告急在bean生命周期的两大阶段：实例化阶段 和初始化阶段 ，下面一起举行阐明，按调用次序为：
- postProcessBeforeInstantiation：实例化bean之前，相称于new这个bean之前
- postProcessAfterInstantiation：实例化bean之后，相称于new这个bean之后
- postProcessPropertyValues：bean已经实例化完成，在属性注入时阶段触发，@Autowired,@Resource等注解原理基于此方法实现
- postProcessBeforeInitialization：初始化bean之前，相称于把bean注入spring上下文之前
- postProcessAfterInitialization：初始化bean之后，相称于把bean注入spring上下文之后
使用场景：这个扩展点非常有效 ，无论是写中心件和业务中，都能使用这个特性。比如对实现了某一类接口的bean在各个生命期间举行收集，大概对某个范例的bean举行同一的设值等等。扩展方式为：
public class TestInstantiationAwareBeanPostProcessor implements InstantiationAwareBeanPostProcessor { @Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { System.out.println("[TestInstantiationAwareBeanPostProcessor] before initialization " + beanName); return bean; } @Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { System.out.println("[TestInstantiationAwareBeanPostProcessor] after initialization " + beanName); return bean; } @Override public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException { System.out.println("[TestInstantiationAwareBeanPostProcessor] before instantiation " + beanName); return null; } @Override public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException { System.out.println("[TestInstantiationAwareBeanPostProcessor] after instantiation " + beanName); return true; } @Override public PropertyValues postProcessPropertyValues(PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException { System.out.println("[TestInstantiationAwareBeanPostProcessor] postProcessPropertyValues " + beanName); return pvs; }7.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 {8.BeanFactoryAware
org.springframework.beans.factory.BeanFactoryAware这个类只有一个触发点，发生在bean的实例化之后，注入属性之前，也就是Setter之前。这个类的扩展点方法为setBeanFactory，可以拿到BeanFactory这个属性。使用场景为，你可以在bean实例化之后，但还未初始化之前，拿到 BeanFactory，在这个时间，可以对每个bean作特别化的定制。也大概可以把BeanFactory拿到举行缓存，日后使用。扩展方式为：
public class TestSmartInstantiationAwareBeanPostProcessor implements SmartInstantiationAwareBeanPostProcessor { @Override public Class<?> predictBeanType(Class<?> beanClass, String beanName) throws BeansException { System.out.println("[TestSmartInstantiationAwareBeanPostProcessor] predictBeanType " + beanName); return beanClass; } @Override public Constructor<?>[] determineCandidateConstructors(Class<?> beanClass, String beanName) throws BeansException { System.out.println("[TestSmartInstantiationAwareBeanPostProcessor] determineCandidateConstructors " + beanName); return null; } @Override public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { System.out.println("[TestSmartInstantiationAwareBeanPostProcessor] getEarlyBeanReference " + beanName); return bean; }}9.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也实现了BeanFactory，MessageSource，ApplicationEventPublisher等接口，也可以用来做相干接口的事故。
10.BeanNameAware
org.springframework.beans.factory.BeanNameAware可以看到，这个类也是Aware扩展的一种，触发点在bean的初始化之前，也就是postProcessBeforeInitialization之前，这个类的触发点方法只有一个：setBeanName使用场景为：用户可以扩展这个点，在初始化bean之前拿到spring容器中注册的的beanName，来自行修改这个beanName的值。扩展方式为：
public class NormalBeanA implements BeanNameAware{ public NormalBeanA() { System.out.println("NormalBean constructor"); } @Override public void setBeanName(String name) { System.out.println("[BeanNameAware] " + name); }}11.@PostConstruct
javax.annotation.PostConstruct这个并不算一个扩展点，着实就是一个标注。其作用是在bean的初始化阶段，假如对一个方法标注了@PostConstruct，会先调用这个方法。这里重点是要关注下这个标准的触发点，这个触发点是在postProcessBeforeInitialization之后，InitializingBean.afterPropertiesSet之前。
使用场景：用户可以对某一方法举行标注，来举行初始化某一个属性
扩展方式为：
public class NormalBeanA { public NormalBeanA() { System.out.println("NormalBean constructor"); } @PostConstruct public void init(){ System.out.println("[PostConstruct] NormalBeanA"); }}12.InitializingBean
org.springframework.beans.factory.InitializingBean这个类，顾名思义，也是用来初始化bean的。InitializingBean接口为bean提供了初始化方法的方式，它只包罗afterPropertiesSet方法，凡是继承该接口的类，在初始化bean的时间都会实验该方法。这个扩展点的触发机遇在postProcessAfterInitialization之前。使用场景：用户实现此接口，来举行体系启动的时间一些业务指标的初始化工作。扩展方式为：
public class NormalBeanA implements InitializingBean{ @Override public void afterPropertiesSet() throws Exception { System.out.println("[InitializingBean] NormalBeanA"); }}13.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开始支持泛型，即接口声明改为FactoryBean<T>的情势使用场景：用户可以扩展这个类，来为要实例化的bean作一个署理，比如为该对象的全部的方法作一个拦截，在调用前后输出一行log，模拟ProxyFactoryBean的功能。
扩展方式为：
public class TestFactoryBean implements FactoryBean<TestFactoryBean.TestFactoryInnerBean> { @Override public TestFactoryBean.TestFactoryInnerBean getObject() throws Exception { System.out.println("[FactoryBean] getObject"); return new TestFactoryBean.TestFactoryInnerBean(); } @Override public Class<?> getObjectType() { return TestFactoryBean.TestFactoryInnerBean.class; } @Override public boolean isSingleton() { return true; } public static class TestFactoryInnerBean{ }}14.SmartInitializingSingleton
org.springframework.beans.factory.SmartInitializingSingleton这个接口中只有一个方法afterSingletonsInstantiated，其作用是是 在spring容器管理的全部单例对象（非懒加载对象）初始化完成之后调用的回调接口。其触发机遇为postProcessAfterInitialization之后。
使用场景：用户可以扩展此接口在对全部单例对象初始化完毕后，做一些后置的业务处置惩罚。
扩展方式为：
public class TestSmartInitializingSingleton implements SmartInitializingSingleton { @Override public void afterSingletonsInstantiated() { System.out.println("[TestSmartInitializingSingleton]"); }}15.CommandLineRunner
org.springframework.boot.CommandLineRunner这个接口也只有一个方法：run(String... args)，触发机遇为整个项目启动完毕后，主动实验。假如有多个CommandLineRunner，可以使用@Order来举行排序。
使用场景：用户扩展此接口，举行启动项目之后一些业务的预处置惩罚。
扩展方式为：
public class TestCommandLineRunner implements CommandLineRunner { @Override public void run(String... args) throws Exception { System.out.println("[TestCommandLineRunner]"); }}16.DisposableBean
org.springframework.beans.factory.DisposableBean这个扩展点也只有一个方法：destroy()，其触发机遇为当此对象烧毁时，会主动实验这个方法。比如说运行applicationContext.registerShutdownHook时，就会触发这个方法。扩展方式为：
public class NormalBeanA implements DisposableBean { @Override public void destroy() throws Exception { System.out.println("[DisposableBean] NormalBeanA"); }}17.ApplicationListener
org.springframework.context.ApplicationListener精确的说，这个应该不算spring&springboot当中的一个扩展点，ApplicationListener可以监听某个事故的event，触发机遇可以穿插在业务方法实验过程中，用户可以自界说某个业务事故。但是spring内部也有一些内置事故，这种事故，可以穿插在启动调用中。我们也可以使用这个特性，来本身做一些内置事故的监听器来到达和前面一些触发点大抵雷同的事故。
接下来摆列下spring告急的内置事故：
ContextRefreshedEvent
ApplicationContext 被初始化或革新时，该事故被发布。这也可以在ConfigurableApplicationContext接口中使用 refresh()方法来发生。此处的初始化是指：全部的Bean被乐成装载，后处置惩罚Bean被检测并激活，全部Singleton Bean 被预实例化，ApplicationContext容器已就绪可用。
ContextStartedEvent
当使用 ConfigurableApplicationContext （ApplicationContext子接口）接口中的 start() 方法启动 ApplicationContext时，该事故被发布。你可以观察你的数据库，大概你可以在担当到这个事故后重启任何制止的应用程序。
ContextStoppedEvent
当使用 ConfigurableApplicationContext接口中的 stop()制止ApplicationContext 时，发布这个事故。你可以在担当到这个事故后做须要的清算的工作
ContextClosedEvent
当使用 ConfigurableApplicationContext接口中的 close()方法关闭 ApplicationContext 时，该事故被发布。一个已关闭的上下文到达生命周期末端；它不能被革新或重启
RequestHandledEvent
这是一个 web-specific 事故，告诉全部 bean HTTP 哀求已经被服务。只能应用于使用DispatcherServlet的Web应用。在使用Spring作为前端的MVC控制器时，当Spring处置惩罚用户哀求竣事后，体系会主动触发该事故。 |
