学习方法之少废话：吹牛、装逼、叫大哥。
作者：A哥（YourBatman）
文末是否有彩蛋：有

前言

各位小伙伴大家好，我是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事件：

LoggingApplicationListener：@since 2.0.0。对日志系统抽象LoggingSystem执行实例化以及初始化之前的操作，默认使用的是基于Logback的LogbackLoggingSystem
BackgroundPreinitializer：启动一个后台进行对一些类进行预热。如ValidationInitializer、JacksonInitializer...，因为这些组件有第一次惩罚的特点（并且首次初始化均还比较耗时），所以使用后台线程先预热效果更佳
DelegatingApplicationListener：它监听的是ApplicationEvent，而实际上只会ApplicationEnvironmentPreparedEvent到达时生效，所以此处忽略
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事件：

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完成的加载/解析

LoggingSystemShutdownListener：来自SC。对LogbackLoggingSystem先清理，再重新初始化一次，效果同上个事件，相当于重新来了一次，毕竟现在有Enviroment环境里嘛
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测试相关，略

AnsiOutputApplicationListener：@since 1.2.0。让你的终端（可以是控制台、可以是日志文件）支持Ansi彩色输出，使其更具可读性。当然前提是你的终端支持ANSI显示。参考类：AnsiOutput。你可通过spring.output.ansi.enabled = xxx配置，可选值是：DETECT/ALWAYS/NEVER，一般不动即可。另外，针对控制台可以单独配置：spring.output.ansi.console-available = true/false
LoggingApplicationListener：@since 2.0.0。根据Enviroment环境完成initialize()初始化动作：日志等级、日志格式模版等

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

ClasspathLoggingApplicationListener：@since 2.0.0。用于把classpath路径以log.debug()输出，略
值得注意的是：classpath类路径是有N多个的Arrays.toString(((URLClassLoader) classLoader).getURLs())，也就是说每个.jar里都属于classpath的范畴
当然喽，你需要注意Spring在处理类路径时：classpath和classpath*的区别~，这属于基础知识
BackgroundPreinitializer：本事件达到时无动作
DelegatingApplicationListener：执行通过外部化配置context.listener.classes = xxx,xxx的监听器们，然后把该事件广播给他们，关心此事件的监听器执行

这麽做的好处：可以通过属性文件外部化配置监听器，而不一定必须写在spring.factories里，更具弹性
外部化配置的执行优先级，还是相对较低的，到这里才给与执行嘛

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
1. SharedMetadataReaderFactoryContextInitializer：略
2. ContextIdApplicationContextInitializer：@since 1.0.0。设置应用ID -> applicationContext.setId()。默认取值为spring.application.name，再为application，再为自动生成
3. ConfigurationWarningsApplicationContextInitializer：@since 1.2.0。对错误的配置进行警告（不会终止程序），以warn()日志输出在控制台。默认内置的只有对包名的检查：若你扫包含有"org.springframework"/"org"这种包名就警告
- 若你想自定义检查规则，请实现Check接口，然后…
  9. RSocketPortInfoApplicationContextInitializer：@since 2.2.0。暂略
1. 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事件：

BackgroundPreinitializer：本事件达到时无动作
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事件：

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

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

LoggingApplicationListener：因为这时已经有Bean工厂了嘛，所以它做的事是：向工厂内放入Bean
- “springBootLoggingSystem” -> loggingSystem
- “springBootLogFile” -> logFile
- “springBootLoggerGroups” -> loggerGroups
BackgroundPreinitializer：本事件达到时无动作
RestartListener：SC提供。把当前最新的上下文缓存起来而已，目前并未发现有实质性作用，可忽略
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事件：

前两个不用再解释了吧：本事件达到时无动作
TomcatMetricsBinder：@since 2.1.0。和监控相关：将你的tomcat指标信息TomcatMetrics绑定到MeterRegistry，从而就能收集到相关指标了

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

ApplicationReadyEvent：应用已准备好

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

完成的大事记

同上。

监听此事件的监听器们

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

SpringApplicationAdminMXBeanRegistrar：当此事件到达时，告诉Admin Spring应用已经ready，可以使用啦。
中间这两个不用再解释了吧：本事件达到时无动作
RefreshEventListener：当此事件到达时，告诉Spring应用已经ready了，接下来便可以执行ContextRefresher.refresh()喽

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

异常情况

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

ApplicationFailedEvent：应用启动失败

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

完成的大事记

得到异常的退出码ExitCode，然后发送ExitCodeEvent事件（非生命周期事件）
发送ApplicationFailedEvent事件，触发对应的监听器的执行

监听此事件的监听器们

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

LoggingApplicationListener：执行loggingSystem.cleanUp()清理资源
ClasspathLoggingApplicationListener：输出一句debug日志：Application failed to start with classpath: ...
中间这两个不用再解释了吧：本事件达到时无动作
ConditionEvaluationReportLoggingListener：自动配置输出报告，输出错误日志呗：特别方便你查看和错误定位

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

BootstrapApplicationListener.CloseContextOnFailureApplicationListener：执行context.close()

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

总结

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

不懂SpringApplication生命周期事件？那就等于不会Spring Boot嘛原创

前言

正文

生命周期事件流程图

版本说明：

SpringApplicationEvent

ApplicationStartingEvent：开始启动中

完成的大事记

监听此事件的监听器们

ApplicationEnvironmentPreparedEvent：环境已准备好

完成的大事记

监听此事件的监听器们

ApplicationContextInitializedEvent：上下文已实例化

完成的大事记

监听此事件的监听器们

ApplicationPreparedEvent：上下文已准备好

完成的大事记

监听此事件的监听器们

ApplicationStartedEvent：应用成功启动

完成的大事记

监听此事件的监听器们

ApplicationReadyEvent：应用已准备好

完成的大事记

监听此事件的监听器们

异常情况

ApplicationFailedEvent：应用启动失败

完成的大事记

监听此事件的监听器们

总结