前言

我们一说到spring，可能第一个想到的是 IOC（控制反转） 和 AOP（面向切面编程）。

没错，它们是spring的基石，得益于它们的优秀设计，使得spring能够从众多优秀框架中脱颖而出。

除此之外，我们在使用spring的过程中，有没有发现它的扩展能力非常强。由于这个优势的存在，让spring拥有强大的包容能力，让很多第三方应用能够轻松投入spring的怀抱。比如：rocketmq、mybatis、redis等。

今天跟大家一起聊聊，在Spring中最常用的11个扩展点。

1.自定义拦截器

spring mvc拦截器根spring拦截器相比，它里面能够获取HttpServletRequest和HttpServletResponse等web对象实例。

spring mvc拦截器的顶层接口是：HandlerInterceptor，包含三个方法：

• preHandle 目标方法执行前执行

• postHandle 目标方法执行后执行

• afterCompletion 请求完成时执行

为了方便我们一般情况会用HandlerInterceptor接口的实现类HandlerInterceptorAdapter类。

假如有权限认证、日志、统计的场景，可以使用该拦截器。

第一步，继承HandlerInterceptorAdapter类定义拦截器：

public class AuthInterceptor extends HandlerInterceptorAdapter {@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)throws Exception {String requestUrl = request.getRequestURI();if (checkAuth(requestUrl)) {return true;}return false;}private boolean checkAuth(String requestUrl) {System.out.println("===权限校验===");return true;}
}

第二步，将该拦截器注册到spring容器：

@Configuration
public class WebAuthConfig extends WebMvcConfigurerAdapter {@Beanpublic AuthInterceptor getAuthInterceptor() {return new AuthInterceptor();}@Overridepublic void addInterceptors(InterceptorRegistry registry) {registry.addInterceptor(new AuthInterceptor());}
}

第三步，在请求接口时spring mvc通过该拦截器，能够自动拦截该接口，并且校验权限。

2.获取Spring容器对象

在我们日常开发中，经常需要从Spring容器中获取Bean，但你知道如何获取Spring容器对象吗？

2.1 BeanFactoryAware接口

@Service
public class PersonService implements BeanFactoryAware {private BeanFactory beanFactory;@Overridepublic void setBeanFactory(BeanFactory beanFactory) throws BeansException {this.beanFactory = beanFactory;}public void add() {Person person = (Person) beanFactory.getBean("person");}
}

实现BeanFactoryAware接口，然后重写setBeanFactory方法，就能从该方法中获取到spring容器对象。

2.2 ApplicationContextAware接口

@Service
public class PersonService2 implements ApplicationContextAware {private ApplicationContext applicationContext;@Overridepublic void setApplicationContext(ApplicationContext applicationContext) throws BeansException {this.applicationContext = applicationContext;}public void add() {Person person = (Person) applicationContext.getBean("person");}
}

实现ApplicationContextAware接口，然后重写setApplicationContext方法，也能从该方法中获取到spring容器对象。

2.3 ApplicationListener接口

@Service
public class PersonService3 implements ApplicationListener {private ApplicationContext applicationContext;@Overridepublic void onApplicationEvent(ContextRefreshedEvent event) {applicationContext = event.getApplicationContext();}public void add() {Person person = (Person) applicationContext.getBean("person");}
}

3.全局异常处理

以前我们在开发接口时，如果出现异常，为了给用户一个更友好的提示，例如：

@RequestMapping("/test")
@RestController
public class TestController {@GetMapping("/add")public String add() {int a = 10 / 0;return "成功";}
}

如果不做任何处理请求add接口结果直接报错：

what？用户能直接看到错误信息？

这种交互方式给用户的体验非常差，为了解决这个问题，我们通常会在接口中捕获异常：

@GetMapping("/add")
public String add() {String result = "成功";try {int a = 10 / 0;} catch (Exception e) {result = "数据异常";}return result;
}

接口改造后，出现异常时会提示：“数据异常”，对用户来说更友好。

看起来挺不错的，但是有问题。。。

如果只是一个接口还好，但是如果项目中有成百上千个接口，都要加上异常捕获代码吗？

答案是否定的，这时全局异常处理就派上用场了：RestControllerAdvice。

@RestControllerAdvice
public class GlobalExceptionHandler {@ExceptionHandler(Exception.class)public String handleException(Exception e) {if (e instanceof ArithmeticException) {return "数据异常";}if (e instanceof Exception) {return "服务器内部异常";}retur nnull;}
}

只需在handleException方法中处理异常情况，业务接口中可以放心使用，不再需要捕获异常（有人统一处理了）。真是爽歪歪。

4.类型转换器

spring目前支持3中类型转换器：

• Converter：将 S 类型对象转为 T 类型对象

• ConverterFactory：将 S 类型对象转为 R 类型及子类对象

• GenericConverter：它支持多个source和目标类型的转化，同时还提供了source和目标类型的上下文，这个上下文能让你实现基于属性上的注解或信息来进行类型转换。

这3种类型转换器使用的场景不一样，我们以Converter为例。假如：接口中接收参数的实体对象中，有个字段的类型是Date，但是实际传参的是字符串类型：2021-01-03 10:20:15，要如何处理呢？

第一步，定义一个实体User：

@Data
public class User {private Long id;private String name;private Date registerDate;
}

第二步，实现Converter接口：

public class DateConverter implements Converter {private SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");@Overridepublic Date convert(String source) {if (source != null && !"".equals(source)) {try {simpleDateFormat.parse(source);} catch (ParseException e) {e.printStackTrace();}}return null;}
}

第三步，将新定义的类型转换器注入到spring容器中：

@Configuration
public class WebConfig extends WebMvcConfigurerAdapter {@Overridepublic void addFormatters(FormatterRegistry registry) {registry.addConverter(new DateConverter());}
}

第四步，调用接口

@RequestMapping("/user")
@RestController
public class UserController {@RequestMapping("/save")public String save(@RequestBody User user) {return "success";}
}

请求接口时User对象中registerDate字段会被自动转换成Date类型。

5.导入配置

有时我们需要在某个配置类中引入另外一些类，被引入的类也加到spring容器中。这时可以使用@Import注解完成这个功能。

如果你看过它的源码会发现，引入的类支持三种不同类型。

但是我认为最好将普通类和@Configuration注解的配置类分开讲解，所以列了四种不同类型：

5.1 普通类

这种引入方式是最简单的，被引入的类会被实例化bean对象。

public class A {
}@Import(A.class)
@Configuration
public class TestConfiguration {
}

通过@Import注解引入A类，spring就能自动实例化A对象，然后在需要使用的地方通过@Autowired注解注入即可：

@Autowired
private A a;

是不是挺让人意外的？不用加@Bean注解也能实例化bean。

5.2 配置类

这种引入方式是最复杂的，因为@Configuration注解还支持多种组合注解，比如：

• @Import

• @ImportResource

• @PropertySource等。

public class A {
}public class B {
}@Import(B.class)
@Configuration
public class AConfiguration {@Beanpublic A a() {return new A();}
}@Import(AConfiguration.class)
@Configuration
public class TestConfiguration {
}

通过@Import注解引入@Configuration注解的配置类，会把该配置类相关@Import、@ImportResource、@PropertySource等注解引入的类进行递归，一次性全部引入。

5.3 ImportSelector

这种引入方式需要实现ImportSelector接口：

public class AImportSelector implements ImportSelector {private static final String CLASS_NAME = "com.sue.cache.service.test13.A";public String[] selectImports(AnnotationMetadata importingClassMetadata) {return new String[]{CLASS_NAME};}
}@Import(AImportSelector.class)
@Configuration
public class TestConfiguration {
}

这种方式的好处是selectImports方法返回的是数组，意味着可以同时引入多个类，还是非常方便的。

5.4 ImportBeanDefinitionRegistrar

这种引入方式需要实现ImportBeanDefinitionRegistrar接口：

public class AImportBeanDefinitionRegistrar implements ImportBeanDefinitionRegistrar {@Overridepublic void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {RootBeanDefinition rootBeanDefinition = new RootBeanDefinition(A.class);registry.registerBeanDefinition("a", rootBeanDefinition);}
}@Import(AImportBeanDefinitionRegistrar.class)
@Configuration
public class TestConfiguration {
}

这种方式是最灵活的，能在registerBeanDefinitions方法中获取到BeanDefinitionRegistry容器注册对象，可以手动控制BeanDefinition的创建和注册。

6.项目启动时

有时候我们需要在项目启动时定制化一些附加功能，比如：加载一些系统参数、完成初始化、预热本地缓存等，该怎么办呢？

好消息是springboot提供了：

• CommandLineRunner

• ApplicationRunner

这两个接口帮助我们实现以上需求。

它们的用法还是挺简单的，以ApplicationRunner接口为例：

@Component
public class TestRunner implements ApplicationRunner {@Autowiredprivate LoadDataService loadDataService;public void run(ApplicationArguments args) throws Exception {loadDataService.load();}
}

实现ApplicationRunner接口，重写run方法，在该方法中实现自己定制化需求。

如果项目中有多个类实现了ApplicationRunner接口，他们的执行顺序要怎么指定呢？

答案是使用@Order(n)注解，n的值越小越先执行。当然也可以通过@Priority注解指定顺序。

7.修改BeanDefinition

Spring IOC在实例化Bean对象之前，需要先读取Bean的相关属性，保存到BeanDefinition对象中，然后通过BeanDefinition对象，实例化Bean对象。

如果想修改BeanDefinition对象中的属性，该怎么办呢？

答：我们可以实现BeanFactoryPostProcessor接口。

@Component
public class MyBeanFactoryPostProcessor implements BeanFactoryPostProcessor {@Overridepublic void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException {DefaultListableBeanFactory defaultListableBeanFactory = (DefaultListableBeanFactory) configurableListableBeanFactory;BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.genericBeanDefinition(User.class);beanDefinitionBuilder.addPropertyValue("id", 123);beanDefinitionBuilder.addPropertyValue("name", "苏三说技术");defaultListableBeanFactory.registerBeanDefinition("user", beanDefinitionBuilder.getBeanDefinition());}
}

在postProcessBeanFactory方法中，可以获取BeanDefinition的相关对象，并且修改该对象的属性。

8.初始化Bean前后

有时，你想在初始化Bean前后，实现一些自己的逻辑。

这时可以实现：BeanPostProcessor接口。

该接口目前有两个方法：

• postProcessBeforeInitialization 该在初始化方法之前调用。

• postProcessAfterInitialization 该方法再初始化方法之后调用。

例如：

@Component
public class MyBeanPostProcessor implements BeanPostProcessor {@Overridepublic Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {if (bean instanceof User) {((User) bean).setUserName("苏三说技术");}return bean;}
}

如果spring中存在User对象，则将它的userName设置成：苏三说技术。

其实，我们经常使用的注解，比如：@Autowired、@Value、@Resource、@PostConstruct等，是通过AutowiredAnnotationBeanPostProcessor和CommonAnnotationBeanPostProcessor实现的。

9.初始化方法

目前spring中使用比较多的初始化bean的方法有：

1. 使用@PostConstruct注解

2. 实现InitializingBean接口

9.1 使用@PostConstruct注解

@Service
public class AService {@PostConstructpublic void init() {System.out.println("===初始化===");}
}

在需要初始化的方法上增加@PostConstruct注解，这样就有初始化的能力。

9.2 实现InitializingBean接口

@Service
public class BService implements InitializingBean {@Overridepublic void afterPropertiesSet() throws Exception {System.out.println("===初始化===");}
}

实现InitializingBean接口，重写afterPropertiesSet方法，该方法中可以完成初始化功能。

10.关闭容器前

有时候，我们需要在关闭spring容器前，做一些额外的工作，比如：关闭资源文件等。

这时可以实现DisposableBean接口，并且重写它的destroy方法：

@Service
public class DService implements InitializingBean, DisposableBean {@Overridepublic void destroy() throws Exception {System.out.println("DisposableBean destroy");}@Overridepublic void afterPropertiesSet() throws Exception {System.out.println("InitializingBean afterPropertiesSet");}
}

这样spring容器销毁前，会调用该destroy方法，做一些额外的工作。

通常情况下，我们会同时实现InitializingBean和DisposableBean接口，重写初始化方法和销毁方法。

11.自定义作用域

我们都知道spring默认支持的Scope只有两种：

• singleton 单例，每次从spring容器中获取到的bean都是同一个对象。

• prototype 多例，每次从spring容器中获取到的bean都是不同的对象。

spring web又对Scope进行了扩展，增加了：

• RequestScope 同一次请求从spring容器中获取到的bean都是同一个对象。

• SessionScope 同一个会话从spring容器中获取到的bean都是同一个对象。

即便如此，有些场景还是无法满足我们的要求。

比如，我们想在同一个线程中从spring容器获取到的bean都是同一个对象，该怎么办？

这就需要自定义Scope了。

第一步实现Scope接口：

public class ThreadLocalScope implements Scope {private static final ThreadLocal THREAD_LOCAL_SCOPE = new ThreadLocal();@Overridepublic Object get(String name, ObjectFactory objectFactory) {Object value = THREAD_LOCAL_SCOPE.get();if (value != null) {return value;}Object object = objectFactory.getObject();THREAD_LOCAL_SCOPE.set(object);return object;}@Overridepublic Object remove(String name) {THREAD_LOCAL_SCOPE.remove();return null;}@Overridepublic void registerDestructionCallback(String name, Runnable callback) {}@Overridepublic Object resolveContextualObject(String key) {return null;}@Overridepublic String getConversationId() {return null;}
}

第二步将新定义的Scope注入到spring容器中：

@Component
public class ThreadLocalBeanFactoryPostProcessor implements BeanFactoryPostProcessor {@Overridepublic void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {beanFactory.registerScope("threadLocalScope", new ThreadLocalScope());}
}

第三步使用新定义的Scope：

@Scope("threadLocalScope")
@Service
public class CService {public void add() {}
}

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 {@Overridepublic void initialize(ConfigurableApplicationContext applicationContext) {System.out.println("[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 TestBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor {@Overridepublic void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {System.out.println("[BeanDefinitionRegistryPostProcessor] postProcessBeanDefinitionRegistry");}@Overridepublic void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {System.out.println("[BeanDefinitionRegistryPostProcessor] postProcessBeanFactory");}
}

5.BeanFactoryPostProcessor

org.springframework.beans.factory.config.BeanFactoryPostProcessor

这个接口是beanFactory的扩展接口，调用时机在spring在读取beanDefinition信息之后，实例化bean之前。

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

扩展方式为：

public class TestBeanFactoryPostProcessor implements BeanFactoryPostProcessor {@Overridepublic void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {System.out.println("[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 {@Overridepublic Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {System.out.println("[TestInstantiationAwareBeanPostProcessor] before initialization " + beanName);return bean;}@Overridepublic Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {System.out.println("[TestInstantiationAwareBeanPostProcessor] after initialization " + beanName);return bean;}@Overridepublic Object postProcessBeforeInstantiation(Class beanClass, String beanName) throws BeansException {System.out.println("[TestInstantiationAwareBeanPostProcessor] before instantiation " + beanName);return null;}@Overridepublic boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {System.out.println("[TestInstantiationAwareBeanPostProcessor] after instantiation " + beanName);return true;}@Overridepublic 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 {@Overridepublic Class predictBeanType(Class beanClass, String beanName) throws BeansException {System.out.println("[TestSmartInstantiationAwareBeanPostProcessor] predictBeanType " + beanName);return beanClass;}@Overridepublic Constructor[] determineCandidateConstructors(Class beanClass, String beanName) throws BeansException {System.out.println("[TestSmartInstantiationAwareBeanPostProcessor] determineCandidateConstructors " + beanName);return null;}@Overridepublic Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {System.out.println("[TestSmartInstantiationAwareBeanPostProcessor] getEarlyBeanReference " + beanName);return bean;}
}

8.BeanFactoryAware

org.springframework.beans.factory.BeanFactoryAware

这个类只有一个触发点，发生在bean的实例化之后，注入属性之前，也就是Setter之前。这个类的扩展点方法为setBeanFactory，可以拿到BeanFactory这个属性。

使用场景为，你可以在bean实例化之后，但还未初始化之前，拿到 BeanFactory，在这个时候，可以对每个bean作特殊化的定制。也或者可以把BeanFactory拿到进行缓存，日后使用。

扩展方式为：

public class TestBeanFactoryAware implements BeanFactoryAware {@Overridepublic void setBeanFactory(BeanFactory beanFactory) throws BeansException {System.out.println("[TestBeanFactoryAware] " + beanFactory.getBean(TestBeanFactoryAware.class).getClass().getSimpleName());}
}

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");}@Overridepublic 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");}@PostConstructpublic 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{@Overridepublic 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的形式

使用场景：用户可以扩展这个类，来为要实例化的bean作一个代理，比如为该对象的所有的方法作一个拦截，在调用前后输出一行log，模仿ProxyFactoryBean的功能。

扩展方式为：

public class TestFactoryBean implements FactoryBean {@Overridepublic TestFactoryBean.TestFactoryInnerBean getObject() throws Exception {System.out.println("[FactoryBean] getObject");return new TestFactoryBean.TestFactoryInnerBean();}@Overridepublic Class getObjectType() {return TestFactoryBean.TestFactoryInnerBean.class;}@Overridepublic boolean isSingleton() {return true;}public static class TestFactoryInnerBean{}
}

14.SmartInitializingSingleton

org.springframework.beans.factory.SmartInitializingSingleton

这个接口中只有一个方法afterSingletonsInstantiated，其作用是是 在spring容器管理的所有单例对象（非懒加载对象）初始化完成之后调用的回调接口。其触发时机为postProcessAfterInitialization之后。

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

扩展方式为：

public class TestSmartInitializingSingleton implements SmartInitializingSingleton {@Overridepublic void afterSingletonsInstantiated() {System.out.println("[TestSmartInitializingSingleton]");}
}

15.CommandLineRunner

org.springframework.boot.CommandLineRunner

这个接口也只有一个方法：run(String... args)，触发时机为整个项目启动完毕后，自动执行。如果有多个CommandLineRunner，可以利用@Order来进行排序。

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

扩展方式为：

public class TestCommandLineRunner implements CommandLineRunner {@Overridepublic 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 {@Overridepublic 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处理用户请求结束后，系统会自动触发该事件

18.最后

我们从这些spring&springboot的扩展点当中，大致可以窥视到整个bean的生命周期。在业务开发或者写中间件业务的时候，可以合理利用spring提供给我们的扩展点，在spring启动的各个阶段内做一些事情。以达到自定义初始化的目的。此篇总结，如果有错误或者疏漏的地方，恳请指正。

下一篇，应某位小伙伴要求，准备总结下在springboot启动过程中，我们如何控制bean的加载顺序的各种办法，让bean的加载顺序完全受你掌控。