学习方法之少废话：吹牛、装逼、叫大哥。

作者：A 哥（YourBatman）

公众号：BAT 的乌托邦（ID：BAT-utopia）

文末是否有彩蛋：有

前言

各位小伙伴大家好，我是 A 哥。本文属总结性文章，对总览Spring Boot生命周期很是重要，建议点在看、转发“造福”更多小伙伴。

我最近不是在写 Spring Cloud 深度剖析的相关专栏麽，最近有收到小伙伴发过来一些问题，通过这段时间收集到的反馈，总结了一下有一个问题非常集中：那便是对 Spring Boot 应用SpringApplication的生命周期、事件的理解。有句话我不是经常挂嘴边说的麽，你对 Spring Framework 有多了解决定了你对 Spring Boot 有多了解，你对 Spring Boot 的了解深度又会制约你去了解 Spring Cloud，一环扣一环。因此此问题反馈比较集中是在清理之中的~

为何在 Spring Boot 中生命周期事件机制如此重要？缘由很简单：Spring Cloud 父容器是由该生命周期事件机制来驱动的，而它仅仅是一个典型代表。Spring Cloud 构建在 Spring Boot 之上，它在此基础上构建并添加了一些“Cloud”功能。应用程序事件ApplicationEvent以及监听ApplicationListener是 Spring Framework 提供的扩展点，Spring Boot 对此扩展点利用得非常充分和深入，并且还衍生出了非常多“子”事件类型，甚至**自成体系**。从ApplicationEvent衍生出来的子事件类型非常多，例如JobExecutionEvent、RSocketServerInitializedEvent、AuditApplicationEvent...

本文并不会对每个子事件分别介绍（也并无必要），而是集中火力主攻 Spring Boot 最为重要的一套事件机制：SpringApplication 生命周期的事件体系。

正文

本文将以SpringApplication的启动流程/生命周期各时期发出的 Event 事件为主线，结合每个生命周期内完成的大事记介绍，真正实现一文让你总览 Spring Boot 的全貌，这对你深入理解 Spring Boot，以及整合进 Spring Cloud 都将非常重要。

为表诚意，本文一开始便把SpringApplication生命周期事件流程图附上，然后再精细化讲解各个事件的详情。

话外音：赶时间的小伙伴可以拿图走人😁，但不建议白嫖哟

生命周期事件流程图

版本说明：

由于不同版本、类路径下存在不同包时结果会存在差异，不指明版本的文章都是不够负责任的。因此对导包/版本情况作出如下说明：

• Spring Boot：2.2.2.RELEASE。有且仅导入spring-boot-starter-web和spring-boot-starter-actuator
  

• Spring Cloud：Hoxton.SR1。有且仅导入spring-cloud-context（注意：并非 spring-cloud-starter，并不含有 spring-cloud-commons 哦）

总的来说：本例导包是非常非常“干净”的，这样在流程上才更有说服力嘛~

SpringApplicationEvent

它是和SpringApplication生命周期有关的所有事件的父类，@since 1.0.0。

public abstract class SpringApplicationEvent extends ApplicationEvent {	private final String[] args;		public SpringApplicationEvent(SpringApplication application, String[] args) {		super(application);		this.args = args;	}	public SpringApplication getSpringApplication() {		return (SpringApplication) getSource();	}	public final String[] getArgs() {		return this.args;	}}

它是抽象类，扩展自 Spring Framwork 的ApplicationEvent，确保了事件和应用实体SpringApplication产生关联（当然还有String[] args）。它有如下实现子类（7 个）：

每个事件都代表着 SpringApplication 不同生命周期所处的位置，下面分别进行讲解。

ApplicationStartingEvent：开始启动中

@since 1.5.0，并非 1.0.0 就有的哦。不过现在几乎没有人用 1.5 以下的版本了，所以可当它是标准事件。

完成的大事记

• SpringApplication实例已实例化：new SpringApplication(primarySources)
  

- 它在实例化阶段完成了如下几件“大”事：

- 推断出应用类型webApplicationType、main 方法所在类

- 给字段 initializers 赋值：拿到 SPI 方式配置的ApplicationContextInitializer上下文初始化器

- 给字段 listeners 赋值：拿到 SPI 方式配置的ApplicationListener应用监听器

- 注意：在此阶段(早期阶段)不要过多地使用它的内部状态，因为它可能在生命周期的后期被修改（话外音：使用时需谨慎）

• 此时，SpringApplicationRunListener已实例化：它通过 SPI 方式指定org.springframework.boot.SpringApplicationRunListener=org.springframework.boot.context.event.EventPublishingRunListener。

- 若你有自己的运行时应用监听器，使用相同方式配置上即可，均会生效

• 由于EventPublishingRunListener已经实例化了，因此在后续的事件发送中，均能够触发对应的监听器的执行

• ==发送 ApplicationStartingEvent 事件，触发对应的监听器的执行==

监听此事件的监听器们

默认情况下，有 4 个监听器监听ApplicationStartingEvent事件：

1. LoggingApplicationListener：@since 2.0.0。对日志系统抽象LoggingSystem执行实例化以及初始化之前的操作，默认使用的是基于 Logback 的LogbackLoggingSystem
   

2. BackgroundPreinitializer：启动一个后台进行对一些类进行**预热**。如ValidationInitializer、JacksonInitializer...，因为这些组件有第一次惩罚的特点（并且首次初始化均还比较耗时），所以使用后台线程先预热效果更佳

3. DelegatingApplicationListener：它监听的是ApplicationEvent，而实际上只会ApplicationEnvironmentPreparedEvent到达时生效，所以此处忽略

4. LiquibaseServiceLocatorApplicationListener：略

总结：此事件节点结束时，SpringApplication完成了一些实例化相关的动作：本实例实例化、本实例属性赋值、日志系统实例化等。

ApplicationEnvironmentPreparedEvent：环境已准备好

@since 1.0.0。该事件节点是最为重要的一个节点之一，因为对于 Spring 应用来说，环境抽象Enviroment简直太重要了，它是最为基础的元数据，决定着程序的构建和走向，所以构建的时机是比较早的。

完成的大事记

• 封装命令行参数（main 方法的 args）到ApplicationArguments里面

• 创建出一个环境抽象实例ConfigurableEnvironment的实现类，并且填入值：Profiles 配置和 Properties 属性，默认内容如下（注意，这只是初始状态，后面还会改变、添加属性源，实际见最后的截图）：

• ==发送 ApplicationEnvironmentPreparedEvent 事件，触发对应的监听器的执行==

- 对环境抽象 Enviroment 的填值，均是由监听此事件的监听器去完成，见下面的监听器详解

• 
  

• bindToSpringApplication(environment)：把环境属性中spring.main.xxx = xxx绑定到当前的 SpringApplication 实例属性上，如常用的spring.main.allow-bean-definition-overriding=true会被绑定到当前SpringApplication实例的对应属性上

监听此事件的监听器们

默认情况下，有 9 个监听器监听ApplicationEnvironmentPreparedEvent事件：

1. BootstrapApplicationListener：来自 SC。优先级最高，用于启动/创建 Spring Cloud 的应用上下文。需要注意的是：到此时 SB 的上下文ApplicationContext还并没有创建哦。这个流程“嵌套”特别像 Bean 初始化流程：初始化 Bean A 时，遇到了 Bean B，就需要先去完成 Bean B 的初始化，再回头来继续完成 Bean A 的步骤。

- 说明：在创建 SC 的应用的时候，使用的也是SpringApplication#run()完成的（非 web），因此也会走下一整套 SpringApplication 的生命周期逻辑，所以请你务必区分。

- 特别是这种 case 会让“绝大多数”初始化器、监听器等执行多次，若你有那种只需要执行一次的需求（比如只想让 SB 容器生命周期内执行，SC 生命周期不执行），请务必自行处理，否则会被执行多次而带来不可预知的结果

- SC 应用上下文读取的外部化配置文件名默认是：bootstrap，使用的也是ConfigFileApplicationListener完成的加载/解析

1. LoggingSystemShutdownListener：来自 SC。对LogbackLoggingSystem先清理，再重新初始化一次，效果同上个事件，相当于重新来了一次，毕竟现在有 Enviroment 环境里嘛

2. ConfigFileApplicationListener：@since 1.0.0。它也许是最重要的一个监听器。做了如下事情：

- 加载 SPI 配置的所有的EnvironmentPostProcessor实例，并且排好序。需要注意的是：ConfigFileApplicationListener也是个EnvironmentPostProcessor，会参与排序哦

- 排好序后，分别一个个的执行EnvironmentPostProcessor（@since 1.3.0，并非一开始就有），介绍如下：

- SystemEnvironmentPropertySourceEnvironmentPostProcessor：@since 2.0.0。把SystemEnvironmentPropertySource替换为其子类OriginAwareSystemEnvironmentPropertySource（属性值带有 Origin 来源），仅此而已

- SpringApplicationJsonEnvironmentPostProcessor：@since 1.3.0。把环境中spring.application.json=xxx值解析成为一个MapPropertySource属性源，然后放进环境里面去（属性源的位置是做了处理的，一般不用太关心）

- 可以看到，SB 是直接支持 JSON 串配置的哦。Json 解析参见：JsonParser

- CloudFoundryVcapEnvironmentPostProcessor：@since 1.3.0。略

- ConfigFileApplicationListener：@since 1.0.0（它比 EnvironmentPostProcessor 先出现的哦）。加载application.properties/yaml等外部化配置，解析好后放进环境里（这应该是最为重要的）。

- 外部化配置默认的优先级为："classpath:/,classpath:/config/,file:./,file:./config/"。当前工程下的 config 目录里的 application.properties 优先级最高，当前工程类路径下的 application.properties 优先级最低

- 值得强调的是：bootstrap.xxx 也是由它负责加载的，处理规则一样

- DebugAgentEnvironmentPostProcessor：@since 2.2.0。处理和reactor测试相关，略

1. AnsiOutputApplicationListener：@since 1.2.0。让你的终端（可以是控制台、可以是日志文件）支持 Ansi 彩色输出，使其更具可读性。当然前提是你的终端支持 ANSI 显示。参考类：AnsiOutput。你可通过spring.output.ansi.enabled = xxx配置，可选值是：DETECT/ALWAYS/NEVER，一般不动即可。另外，针对控制台可以单独配置：spring.output.ansi.console-available = true/false
   

2. LoggingApplicationListener：@since 2.0.0。根据 Enviroment 环境完成initialize()初始化动作：日志等级、日志格式模版等

- 值得注意的是：它这步相当于在 ApplicationStartingEvent 事件基础上进一步完成了初始化（上一步只是实例化）

1. ClasspathLoggingApplicationListener：@since 2.0.0。用于把 classpath 路径以log.debug()输出，略

1. 值得注意的是：classpath 类路径是有 N 多个的Arrays.toString(((URLClassLoader) classLoader).getURLs())，也就是说每个.jar 里都属于 classpath 的范畴

2. 当然喽，你需要注意 Spring 在处理类路径时：*classpath 和 classpath 的区别**~，这属于基础知识

1. BackgroundPreinitializer：本事件达到时无动作

2. DelegatingApplicationListener：执行通过外部化配置context.listener.classes = xxx,xxx的监听器们，然后把该事件广播给他们，关心此事件的监听器执行

- 这麽做的好处：可以通过属性文件外部化配置监听器，而不一定必须写在spring.factories里，更具弹性

- 外部化配置的执行优先级，还是相对较低的，到这里才给与执行嘛

1. FileEncodingApplicationListener：检测当前系统环境的 file.encoding 和 spring.mandatory-file-encoding 设置的值是否一样,如果不一样则抛出异常如果不配置 spring.mandatory-file-encoding 则不检查

总结：此事件节点结束时，Spring Boot 的环境抽象 Enviroment 已经准备完毕，但此时其上下文ApplicationContext还没有创建，但是 Spring Cloud 的应用上下文（引导上下文）已经全部初始化完毕哦，所以 SC 管理的外部化配置也应该都进入到了 SB 里面。如下图所示（这是基本上算是 Enviroment 的最终态了）：

小提示：SC 配置的优先级是高于 SB 管理的外部化配置的。例如针对spring.application.name这个属性，若 bootstrap 里已配置了值，再在 application.yaml 里配置其实就无效了，因此生产上建议不要写两处。

ApplicationContextInitializedEvent：上下文已实例化

@since 2.1.0，非常新的一个事件。当 SpringApplication 的上下文ApplicationContext准备好后，对单例 Bean 们实例化之前，发送此事件。所以此事件又可称为：contextPrepared事件。

完成的大事记

• printBanner(environment)：打印 Banner 图，默认打印的是 Spring Boot 字样

- spring.main.banner-mode = xxx来控制 Banner 的输出，可选值为CONSOLE/LOG/OFF，一般默认就好

- 默认在类路径下放置一个banner.txt文件，可实现自定义 Banner。关于更多自定义方式，如使用图片、gif 等，本处不做过多介绍

- 小建议：别花里胡哨搞个佛祖在那。让它能自动打印输出当前应用名，这样才是最为实用，最高级的（但需要你定制化开发，并且支持可配置，最好对使用者无感，属于一个 common 组件）

• 根据是否是 web 环境、是否是 REACTIVE 等，用空构造器创建出一个ConfigurableApplicationContext上下文实例（因为使用的是空构造器，所以不会立马“启动”上下文）

- SERVLET -> AnnotationConfigServletWebServerApplicationContext

- REACTIVE -> AnnotationConfigReactiveWebServerApplicationContext

- 非 web 环境 -> AnnotationConfigApplicationContext（SC 应用的容器就是使用的它）

• 既然上下文实例已经有了，那么就开始对它进行一些参数的设置：

- 首先最重要的便是把已经准备好的环境 Enviroment 环境设置给它

- 设置些 beanNameGenerator、resourceLoader、ConversionService 等组件

- 实例化所有的ApplicationContextInitializer上下文初始化器，并且排序好后挨个执行它（这个很重要），默认有如下截图这些初始化器此时要执行：

下面对这些初始化器分别做出简单介绍：

1. BootstrapApplicationListener.AncestorInitializer：来自 SC。用于把 SC 容器设置为 SB 容器的父容器。当然实际操作委托给了此方法：new ParentContextApplicationContextInitializer(this.parent).initialize(context)去完成

2. BootstrapApplicationListener.DelegatingEnvironmentDecryptApplicationInitializer：来自 SC。代理了下面会提到的EnvironmentDecryptApplicationInitializer，也就是说在此处就会先执行，用于提前解密 Enviroment 环境里面的属性，如相关 URL 等

3. PropertySourceBootstrapConfiguration：来自 SC。重要，和配置中心相关，若想自定义配置中心必须了解它。主要作用是PropertySourceLocator属性源定位器，我会把它放在配置中心章节详解

4. EnvironmentDecryptApplicationInitializer：来自 SC。属性源头通过上面加载回来了，通过它来实现解密

- 值得注意的是：它被执行了两次哦~

5. DelegatingApplicationContextInitializer：和上面的DelegatingApplicationListener功能类似，支持外部化配置context.initializer.classes = xxx,xxx

6. SharedMetadataReaderFactoryContextInitializer：略

7. ContextIdApplicationContextInitializer：@since 1.0.0。设置应用 ID -> applicationContext.setId()。默认取值为spring.application.name，再为 application，再为自动生成

8. ConfigurationWarningsApplicationContextInitializer：@since 1.2.0。对错误的配置进行警告（不会终止程序），以 warn()日志输出在控制台。默认内置的只有对包名的检查：若你扫包含有"org.springframework"/"org"这种包名就警告

- 若你想自定义检查规则，请实现Check接口，然后...

9. RSocketPortInfoApplicationContextInitializer：@since 2.2.0。暂略

10. ServerPortInfoApplicationContextInitializer：@since 2.0.0。将自己作为一个监听器注册到上下文ConfigurableApplicationContext里，专门用于监听WebServerInitializedEvent事件（非 SpringApplication 的生命周期事件）

- 该事件有两个实现类：ServletWebServerInitializedEvent和ReactiveWebServerInitializedEvent。发送此事件的时机是WebServer已启动完成，所以已经有了监听的端口号

- 该监听器做的事有两个：

- "local." + getName(context.getServerNamespace()) + ".port"作为 key（默认值是local.server.port），value 是端口值。这样可以通过 @Value 来获取到本机端口了（但貌似端口写 0 的时候，SB 在显示上有个小 bug）

- 作为一个属性源MapPropertySource放进环境里，属性源名称为：server.ports（因为一个 server 是可以监听多个端口的，所以这里用复数）

- ConditionEvaluationReportLoggingListener：将ConditionEvaluationReport报告（自动配置中哪些匹配了，哪些没匹配上）写入日志，当然只有LogLevel#DEBUG时才会输出（注意：这不是日志级别哦，应该叫报告级别）。如你配置debug=true就开启了此自动配置类报告

- 槽点：它明明是个初始化器，为毛命名为 Listener？

• ==发送 ApplicationContextInitializedEvent 事件，触发对应的监听器的执行==

监听此事件的监听器们

默认情况下，有 2 个监听器监听ApplicationContextInitializedEvent事件：

1. BackgroundPreinitializer：本事件达到时无动作

2. DelegatingApplicationListener：本事件达到时无动作

总结：此事件节点结束时，完成了应用上下文 ApplicationContext 的准备工作，**并且执行所有注册的上下文初始化器ApplicationContextInitializer**。但是此时，单例 Bean 是仍旧还没有初始化，并且 WebServer 也还没有启动

----

ApplicationPreparedEvent：上下文已准备好

@since 1.0.0。截止到上个事件ApplicationContextInitializedEvent，应用上下文 ApplicationContext 充其量叫实例化好了，但是还剩下很重要的事没做，这便是本周期的内容。

完成的大事记

• 把 applicationArguments、printedBanner 等都作为一个 Bean 放进 Bean 工厂里（因此你就可以 @Autowired 注入的哦）

- 比如：有了 Banner 这个 Bean，你可以在你任何想要输出的地方输出一个 Banner，而不仅仅是启动时只会输出一次了

• 若lazyInitialization = true延迟初始化，那就向 Bean 工厂放一个：new LazyInitializationBeanFactoryPostProcessor()
  

- 该处理器 @since 2.2.0。该处理器的作用是：对所有的 Bean（通过LazyInitializationExcludeFilter接口指定的排除在外）全部.setLazyInit(true);延迟初始化

• 根据 primarySources 和 allSources，交给BeanDefinitionLoader（SB 提供的实现）实现加载 Bean 的定义信息，它支持 4 种加载方式（4 种源）：

- AnnotatedBeanDefinitionReader -> 基于注解

- XmlBeanDefinitionReader -> 基于 xml 配置

- GroovyBeanDefinitionReader -> Groovy 文件

- ClassPathBeanDefinitionScanner -> classpath 中加载

- (不同的源使用了不同的 load 加载方式)

• ==发送 ApplicationPreparedEvent 事件，触发对应的监听器的执行==

监听此事件的监听器们

默认情况下，有 6 个监听器监听ApplicationContextInitializedEvent事件：

1. CloudFoundryVcapEnvironmentPostProcessor：略

2. ConfigFileApplicationListener：向上下文注册一个new PropertySourceOrderingPostProcessor(context)。它的作用是：Bean 工厂结束后对环境里的属性源进行重排序 -> 把名字叫defaultProperties的属性源放在最末位

- 该属性源是通过SpringApplication#setDefaultProperties API 方式放进来的，一般不会使用到，留个印象即可

1. LoggingApplicationListener：因为这时已经有 Bean 工厂了嘛，所以它做的事是：向工厂内放入 Bean

- "springBootLoggingSystem" -> loggingSystem

- "springBootLogFile" -> logFile

- "springBootLoggerGroups" -> loggerGroups

1. BackgroundPreinitializer：本事件达到时无动作

2. RestartListener：SC 提供。把当前最新的上下文缓存起来而已，目前并未发现有实质性作用，可忽略

3. DelegatingApplicationListener：本事件达到时无动作

总结：此事件节点结束时，应用上下文 ApplicationContext 初始化完成，该赋值的赋值了，Bean 定义信息也已全部加载完成。但是，单例 Bean 还没有被实例化，web 容器依旧还没启动。

----

ApplicationStartedEvent：应用成功启动

@since 2.0.0。截止到此，应用已经准备就绪，并且通过监听器、初始化器等完成了非常多的工作了，但仍旧剩下被认为最为重要的初始化单例 Bean 动作还没做、web 容器（如 Tomcat）还没启动，这便是这个周期所要做的事。

完成的大事记

• 启动 Spring 容器：AbstractApplicationContext#refresh()，这个步骤会做很多事，比如会实例化单例 Bean

- 该步骤属于 Spring Framework 的核心内容范畴，做了很多事，请参考 Spring 核心技术内容章节

- 在 Spring 容器 refresh()启动完成后，WebServer也随之完成启动，成功监听到对应端口(们)

• 输出启动成功的日志：Started Application in xxx seconds (JVM running for xxx)
  

• ==发送 ApplicationStartedEvent 事件，触发对应的监听器的执行==

• 
  

• callRunners()：依次执行容器内配置的ApplicationRunner/CommandLineRunner的 Bean 实现类，支持 sort 排序

- ApplicationRunner：@since 1.3.0，入参是ApplicationArguments，先执行（推荐使用）

- CommandLineRunner：@since 1.0.0，入参是String... args，后执行（不推荐使用）

监听此事件的监听器们

默认情况下，有 3 个监听器监听ApplicationStartedEvent事件：

1. 前两个不用再解释了吧：本事件达到时无动作

2. TomcatMetricsBinder：@since 2.1.0。和监控相关：将你的 tomcat 指标信息TomcatMetrics绑定到MeterRegistry，从而就能收集到相关指标了

总结：此事件节点结束时，SpringApplication的生命周期到这一步，正常的启动流程就全部完成了。也就说 Spring Boot 应用可以正常对对外提供服务了。

ApplicationReadyEvent：应用已准备好

@since 1.3.0。该事件所处的生命周期可认为基本同ApplicationStartedEvent，仅是在其后执行而已，两者中间并无其它特别的动作，但是监听此事件的监听器们还是蛮重要的。

完成的大事记

同上。

监听此事件的监听器们

默认情况下，有 4 个监听器监听ApplicationStartedEvent事件：

1. SpringApplicationAdminMXBeanRegistrar：当此事件到达时，告诉 Admin Spring 应用已经 ready，可以使用啦。

2. 中间这两个不用再解释了吧：本事件达到时无动作

3. RefreshEventListener：当此事件到达时，告诉 Spring 应用已经 ready 了，接下来便可以执行ContextRefresher.refresh()喽

总结：此事件节点结束时，应用已经完完全全的准备好了，并且也已经完成了相关组件的周知工作。

异常情况

SpringApplication是有可能在启动的时候失败（如端口号已被占用），当然任何一步骤遇到异常时交给SpringApplication#handleRunFailure()方法来处理，这时候也会有对应的事件发出。

ApplicationFailedEvent：应用启动失败

当SpringApplication在启动时抛出异常：可能是端口绑定、也可能是你自定义的监听器你写了个 bug 等，就会“可能”发送此事件。

完成的大事记

• 得到异常的退出码 ExitCode，然后发送ExitCodeEvent事件（非生命周期事件）

• 发送ApplicationFailedEvent事件，触发对应的监听器的执行

监听此事件的监听器们

默认情况下，有 6 个监听器监听ApplicationStartedEvent事件：

1. LoggingApplicationListener：执行loggingSystem.cleanUp()清理资源

2. ClasspathLoggingApplicationListener：输出一句 debug 日志：Application failed to start with classpath: ...
   

3. 中间这两个不用再解释了吧：本事件达到时无动作

4. ConditionEvaluationReportLoggingListener：自动配置输出报告，输出错误日志呗：特别方便你查看和错误定位

- 不得不夸：SB 对错误定位这块才真叫智能，比 Spring Framework 好用太多了

1. BootstrapApplicationListener.CloseContextOnFailureApplicationListener：执行 context.close()

总结：此事件节点结束时，会做一些释放资源的操作。一般情况下：我们并不需要监听到此事件

----

总结

关于SpringApplication的生命周期体系的介绍就到这了，相信通过此“万字长文”你能体会到 A 哥的用心。翻了翻市面上的相关文章，本文 Almost 可以保证是总结得最到位的，让你通过一文便可从大的方面基本掌握 Spring Boot，这不管是你使用 SB，还是后续自行扩展、精雕细琢 SB，以及去深入了解 Spring Cloud 均由非常重要的意义，希望对你有帮助，谢谢你的三连。