再聊SpringBean的生命周期

Spring Bean的生命周期是Spring面试热点问题。这个问题即考察对Spring的微观了解&＃xff0c;又考察对Spring的宏观认识&＃xff0c;想要答好并不容易&＃xff01;本文希望能够从源码角度入手&＃xff0c;帮助面试者彻底搞定Spring Bean的生命周期。

简述bean的生命周期

实例化 -> 填充属性 -> 初始化 -> 销毁

SpringBean生命周期简单概括为4个阶段&＃xff1a;

1.实例化&＃xff0c;创建一个Bean对象

2.填充属性&＃xff0c;为属性赋值

3.初始化

• 如果实现了xxxAware接口&＃xff0c;通过不同类型的Aware接口拿到Spring容器的资源
• 如果实现了BeanPostProcessor接口&＃xff0c;则会回调该接口的postProcessBeforeInitialzation和postProcessAfterInitialization方法
• 如果配置了init-method方法&＃xff0c;则会执行init-method配置的方法

4.销毁

• 容器关闭后&＃xff0c;如果Bean实现了DisposableBean接口&＃xff0c;则会回调该接口的destroy方法
• 如果配置了destroy-method方法&＃xff0c;则会执行destroy-method配置的方法

是的&＃xff0c;Spring Bean的生命周期只有这四个阶段。把这四个阶段和每个阶段对应的扩展点糅合在一起虽然没有问题&＃xff0c;但是这样非常凌乱&＃xff0c;难以记忆。要彻底搞清楚Spring的生命周期&＃xff0c;首先要把这四个阶段牢牢记住。实例化和属性赋值对应构造方法和setter方法的注入&＃xff0c;初始化和销毁是用户能自定义扩展的两个阶段。在这四步之间穿插的各种扩展点&＃xff0c;稍后会讲。

主要逻辑都在doCreateBean()方法中&＃xff0c;逻辑很清晰&＃xff0c;就是顺序调用以下三个方法&＃xff0c;这三个方法与三个生命周期阶段一一对应&＃xff0c;非常重要&＃xff0c;在后续扩展接口分析中也会涉及。

1. createBeanInstance() -> 实例化
2. populateBean() -> 属性赋值
3. initializeBean() -> 初始化

源码如下&＃xff0c;能证明实例化&＃xff0c;属性赋值和初始化这三个生命周期的存在。关于本文的Spring源码都将忽略无关部分&＃xff0c;便于理解&＃xff1a;

// 忽略了无关代码
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final &＃64;Nullable Object[] args)throws BeanCreationException {// Instantiate the bean.BeanWrapper instanceWrapper &＃61; null;if (instanceWrapper &＃61;&＃61; null) {// 实例化阶段&＃xff01;instanceWrapper &＃61; createBeanInstance(beanName, mbd, args);}// Initialize the bean instance.Object exposedObject &＃61; bean;try {// 属性赋值阶段&＃xff01;populateBean(beanName, mbd, instanceWrapper);// 初始化阶段&＃xff01;exposedObject &＃61; initializeBean(beanName, exposedObject, mbd);}}


至于销毁&＃xff0c;是在容器关闭时调用的&＃xff0c;详见ConfigurableApplicationContext#close()

常用扩展点

Spring生命周期相关的常用扩展点非常多&＃xff0c;所以问题不是不知道&＃xff0c;而是记不住或者记不牢。其实记不住的根本原因还是不够了解&＃xff0c;这里通过源码&＃43;分类的方式帮大家记忆。

第一大类&＃xff1a;影响多个Bean的接口

实现了这些接口的Bean会切入到多个Bean的生命周期中。正因为如此&＃xff0c;这些接口的功能非常强大&＃xff0c;Spring内部扩展也经常使用这些接口&＃xff0c;例如自动注入以及AOP的实现都和他们有关。

• BeanPostProcessor
• InstantiationAwareBeanPostProcessor

这两兄弟可能是Spring扩展中最重要的两个接口&＃xff01;InstantiationAwareBeanPostProcessor作用于实例化阶段的前后&＃xff0c;BeanPostProcessor作用于初始化阶段的前后。正好和第一、第三个生命周期阶段对应。通过图能更好理解&＃xff1a;

InstantiationAwareBeanPostProcessor实际上继承了BeanPostProcessor接口&＃xff0c;严格意义上来看他们不是两兄弟&＃xff0c;而是两父子。但是从生命周期角度我们重点关注其特有的对实例化阶段的影响&＃xff0c;图中省略了从BeanPostProcessor继承的方法。

InstantiationAwareBeanPostProcessor extends BeanPostProcessor


InstantiationAwareBeanPostProcessor源码分析&＃xff1a;

• postProcessBeforeInstantiation调用点&＃xff0c;忽略无关代码&＃xff1a;

&＃64;Overrideprotected Object createBean(String beanName, RootBeanDefinition mbd, &＃64;Nullable Object[] args)throws BeanCreationException {try {// Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.// postProcessBeforeInstantiation方法调用点&＃xff0c;这里就不跟进了&＃xff0c;// 有兴趣的同学可以自己看下&＃xff0c;就是for循环调用所有的InstantiationAwareBeanPostProcessorObject bean &＃61; resolveBeforeInstantiation(beanName, mbdToUse);if (bean !&＃61; null) {return bean;}}try { // 上文提到的doCreateBean方法&＃xff0c;可以看到// postProcessBeforeInstantiation方法在创建Bean之前调用Object beanInstance &＃61; doCreateBean(beanName, mbdToUse, args);if (logger.isTraceEnabled()) {logger.trace("Finished creating instance of bean &＃39;" &＃43; beanName &＃43; "&＃39;");}return beanInstance;}}

可以看到&＃xff0c;postProcessBeforeInstantiation在doCreateBean之前调用&＃xff0c;也就是在bean实例化之前调用的&＃xff0c;英文源码注释解释道该方法的返回值会替换原本的Bean作为代理&＃xff0c;这也是Aop等功能实现的关键点。

• postProcessAfterInstantiation调用点&＃xff0c;忽略无关代码&＃xff1a;

protected void populateBean(String beanName, RootBeanDefinition mbd, &＃64;Nullable BeanWrapper bw) {// Give any InstantiationAwareBeanPostProcessors the opportunity to modify the// state of the bean before properties are set. This can be used, for example,// to support styles of field injection.boolean continueWithPropertyPopulation &＃61; true;// InstantiationAwareBeanPostProcessor#postProcessAfterInstantiation()// 方法作为属性赋值的前置检查条件&＃xff0c;在属性赋值之前执行&＃xff0c;能够影响是否进行属性赋值&＃xff01;if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {for (BeanPostProcessor bp : getBeanPostProcessors()) {if (bp instanceof InstantiationAwareBeanPostProcessor) {InstantiationAwareBeanPostProcessor ibp &＃61; (InstantiationAwareBeanPostProcessor) bp;if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {continueWithPropertyPopulation &＃61; false;break;}}}}// 忽略后续的属性赋值操作代码
}

可以看到该方法在属性赋值方法内&＃xff0c;但是在真正执行赋值操作之前。其返回值为boolean&＃xff0c;返回false时可以阻断属性赋值阶段&＃xff08;continueWithPropertyPopulation &＃61; false;&＃xff09;。

关于BeanPostProcessor执行阶段的源码穿插在下文Aware接口的调用时机分析中&＃xff0c;因为部分Aware功能的就是通过他实现的!只需要先记住BeanPostProcessor在初始化前后调用就可以了。

第二大类&＃xff1a;只调用一次的接口

这一大类接口的特点是功能丰富&＃xff0c;常用于用户自定义扩展。

第二大类中又可以分为两类&＃xff1a;

• Aware类型的接口
• 生命周期接口

无所不知的Aware

Aware类型的接口的作用就是让我们能够拿到Spring容器中的一些资源。基本都能够见名知意&＃xff0c;Aware之前的名字就是可以拿到什么资源&＃xff0c;例如BeanNameAware可以拿到BeanName&＃xff0c;以此类推。调用时机需要注意&＃xff1a;所有的Aware方法都是在初始化阶段之前调用的&＃xff01;

Aware接口众多&＃xff0c;这里同样通过分类的方式帮助大家记忆。

Aware接口具体可以分为两组&＃xff0c;至于为什么这么分&＃xff0c;详见下面的源码分析。如下排列顺序同样也是Aware接口的执行顺序&＃xff0c;能够见名知意的接口不再解释。

Aware Group1

1. BeanNameAware
2. BeanClassLoaderAware
3. BeanFactoryAware

Aware Group2

1. EnvironmentAware
2. EmbeddedValueResolverAware 这个知道的人可能不多&＃xff0c;实现该接口能够获取Spring EL解析器&＃xff0c;用户的自定义注解需要支持spel表达式的时候可以使用&＃xff0c;非常方便。
3. ApplicationContextAware(ResourceLoaderAware\ApplicationEventPublisherAware\MessageSourceAware) 这几个接口可能让人有点懵&＃xff0c;实际上这几个接口可以一起记&＃xff0c;其返回值实质上都是当前的ApplicationContext对象&＃xff0c;因为ApplicationContext是一个复合接口&＃xff0c;如下&＃xff1a;

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,MessageSource, ApplicationEventPublisher, ResourcePatternResolver {}

这里涉及到另一道面试题&＃xff0c;ApplicationContext和BeanFactory的区别&＃xff0c;可以从ApplicationContext继承的这几个接口入手&＃xff0c;除去BeanFactory相关的两个接口就是ApplicationContext独有的功能&＃xff0c;这里不详细说明。

Aware调用时机源码分析

详情如下&＃xff0c;忽略了部分无关代码。代码位置就是我们上文提到的initializeBean方法详情&＃xff0c;这也说明了Aware都是在初始化阶段之前调用的&＃xff01;

// 见名知意&＃xff0c;初始化阶段调用的方法protected Object initializeBean(final String beanName, final Object bean, &＃64;Nullable RootBeanDefinition mbd) {// 这里调用的是Group1中的三个Bean开头的AwareinvokeAwareMethods(beanName, bean);Object wrappedBean &＃61; bean;// 这里调用的是Group2中的几个Aware&＃xff0c;// 而实质上这里就是前面所说的BeanPostProcessor的调用点&＃xff01;// 也就是说与Group1中的Aware不同&＃xff0c;这里是通过BeanPostProcessor&＃xff08;ApplicationContextAwareProcessor&＃xff09;实现的。wrappedBean &＃61; applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);// 下文即将介绍的InitializingBean调用点invokeInitMethods(beanName, wrappedBean, mbd);// BeanPostProcessor的另一个调用点wrappedBean &＃61; applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);return wrappedBean;}


可以看到并不是所有的Aware接口都使用同样的方式调用。Bean××Aware都是在代码中直接调用的&＃xff0c;而ApplicationContext相关的Aware都是通过BeanPostProcessor#postProcessBeforeInitialization()实现的。感兴趣的可以自己看一下ApplicationContextAwareProcessor这个类的源码&＃xff0c;就是判断当前创建的Bean是否实现了相关的Aware方法&＃xff0c;如果实现了会调用回调方法将资源传递给Bean。

至于Spring为什么这么实现&＃xff0c;应该没什么特殊的考量。也许和Spring的版本升级有关。基于对修改关闭&＃xff0c;对扩展开放的原则&＃xff0c;Spring对一些新的Aware采用了扩展的方式添加。

BeanPostProcessor的调用时机也能在这里体现&＃xff0c;包围住invokeInitMethods方法&＃xff0c;也就说明了在初始化阶段的前后执行。

关于Aware接口的执行顺序&＃xff0c;其实只需要记住第一组在第二组执行之前就行了。每组中各个Aware方法的调用顺序其实没有必要记&＃xff0c;有需要的时候点进源码一看便知。

简单的两个生命周期接口

至于剩下的两个生命周期接口就很简单了&＃xff0c;实例化和属性赋值都是Spring帮助我们做的&＃xff0c;能够自己实现的有初始化和销毁两个生命周期阶段。

1. InitializingBean 对应生命周期的初始化阶段&＃xff0c;在上面源码的invokeInitMethods(beanName, wrappedBean, mbd);方法中调用。
   有一点需要注意&＃xff0c;因为Aware方法都是执行在初始化方法之前&＃xff0c;所以可以在初始化方法中放心大胆的使用Aware接口获取的资源&＃xff0c;这也是我们自定义扩展Spring的常用方式。
   除了实现InitializingBean接口之外还能通过注解或者xml配置的方式指定初始化方法&＃xff0c;至于这几种定义方式的调用顺序其实没有必要记。因为这几个方法对应的都是同一个生命周期&＃xff0c;只是实现方式不同&＃xff0c;我们一般只采用其中一种方式。

2. DisposableBean 类似于InitializingBean&＃xff0c;对应生命周期的销毁阶段&＃xff0c;以ConfigurableApplicationContext#close()方法作为入口&＃xff0c;实现是通过循环取所有实现了DisposableBean接口的Bean然后调用其destroy()方法 。感兴趣的可以自行跟一下源码。

扩展阅读&＃xff1a;BeanPostProcessor注册时机与执行顺序

注册时机

我们知道BeanPostProcessor也会注册为Bean&＃xff0c;那么Spring是如何保证BeanPostProcessor在我们的业务Bean之前初始化完成呢&＃xff1f;

请看我们熟悉的refresh()方法的源码&＃xff0c;省略部分无关代码&＃xff1a;

&＃64;Overridepublic void refresh() throws BeansException, IllegalStateException {synchronized (this.startupShutdownMonitor) {try {// Allows post-processing of the bean factory in context subclasses.postProcessBeanFactory(beanFactory);// Invoke factory processors registered as beans in the context.invokeBeanFactoryPostProcessors(beanFactory);// Register bean processors that intercept bean creation.// 所有BeanPostProcesser初始化的调用点registerBeanPostProcessors(beanFactory);// Initialize message source for this context.initMessageSource();// Initialize event multicaster for this context.initApplicationEventMulticaster();// Initialize other special beans in specific context subclasses.onRefresh();// Check for listener beans and register them.registerListeners();// Instantiate all remaining (non-lazy-init) singletons.// 所有单例非懒加载Bean的调用点finishBeanFactoryInitialization(beanFactory);// Last step: publish corresponding event.finishRefresh();}}

可以看出&＃xff0c;Spring是先执行registerBeanPostProcessors()进行BeanPostProcessors的注册&＃xff0c;然后再执行finishBeanFactoryInitialization初始化我们的单例非懒加载的Bean。

执行顺序

BeanPostProcessor有很多个&＃xff0c;而且每个BeanPostProcessor都影响多个Bean&＃xff0c;其执行顺序至关重要&＃xff0c;必须能够控制其执行顺序才行。关于执行顺序这里需要引入两个排序相关的接口&＃xff1a;PriorityOrdered、Ordered

1. PriorityOrdered是一等公民&＃xff0c;首先被执行&＃xff0c;PriorityOrdered公民之间通过接口返回值排序
2. Ordered是二等公民&＃xff0c;然后执行&＃xff0c;Ordered公民之间通过接口返回值排序
3. 都没有实现是三等公民&＃xff0c;最后执行

在以下源码中&＃xff0c;可以很清晰的看到Spring注册各种类型BeanPostProcessor的逻辑&＃xff0c;根据实现不同排序接口进行分组。优先级高的先加入&＃xff0c;优先级低的后加入。

// First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.// 首先&＃xff0c;加入实现了PriorityOrdered接口的BeanPostProcessors&＃xff0c;顺便根据PriorityOrdered排了序String[] postProcessorNames &＃61;beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);for (String ppName : postProcessorNames) {if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));processedBeans.add(ppName);}}sortPostProcessors(currentRegistryProcessors, beanFactory);registryProcessors.addAll(currentRegistryProcessors);invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);currentRegistryProcessors.clear();// Next, invoke the BeanDefinitionRegistryPostProcessors that implement Ordered.// 然后&＃xff0c;加入实现了Ordered接口的BeanPostProcessors&＃xff0c;顺便根据Ordered排了序postProcessorNames &＃61; beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);for (String ppName : postProcessorNames) {if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));processedBeans.add(ppName);}}sortPostProcessors(currentRegistryProcessors, beanFactory);registryProcessors.addAll(currentRegistryProcessors);invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);currentRegistryProcessors.clear();// Finally, invoke all other BeanDefinitionRegistryPostProcessors until no further ones appear.// 最后加入其他常规的BeanPostProcessorsboolean reiterate &＃61; true;while (reiterate) {reiterate &＃61; false;postProcessorNames &＃61; beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);for (String ppName : postProcessorNames) {if (!processedBeans.contains(ppName)) {currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));processedBeans.add(ppName);reiterate &＃61; true;}}sortPostProcessors(currentRegistryProcessors, beanFactory);registryProcessors.addAll(currentRegistryProcessors);invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);currentRegistryProcessors.clear();}


根据排序接口返回值排序&＃xff0c;默认升序排序&＃xff0c;返回值越低优先级越高。

/*** Useful constant for the highest precedence value.* &＃64;see java.lang.Integer#MIN_VALUE*/int HIGHEST_PRECEDENCE &＃61; Integer.MIN_VALUE;/*** Useful constant for the lowest precedence value.* &＃64;see java.lang.Integer#MAX_VALUE*/int LOWEST_PRECEDENCE &＃61; Integer.MAX_VALUE;


PriorityOrdered、Ordered接口作为Spring整个框架通用的排序接口&＃xff0c;在Spring中应用广泛&＃xff0c;也是非常重要的接口。

本文小结

Spring Bean的生命周期分为四个阶段和多个扩展点。扩展点又可以分为影响多个Bean和影响单个Bean。整理如下&＃xff1a;

四个阶段

1. 实例化 Instantiation
2. 属性赋值 Populate
3. 初始化 Initialization
4. 销毁 Destruction

多个扩展点

1. 影响多个Bean
2. 影响单个Bean

至此&＃xff0c;Spring Bean的生命周期介绍完毕。