乐趣区

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

学习方法之少废话:吹牛、装逼、叫大哥。
作者 :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-webspring-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 完成的加载 / 解析
  2. LoggingSystemShutdownListener:来自 SC。对 LogbackLoggingSystem 先清理,再重新初始化一次,效果同上个事件,相当于重新来了一次,毕竟现在有 Enviroment 环境里嘛
  3. 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 事件基础上进一步完成了初始化(上一步只是实例化)
  3. ClasspathLoggingApplicationListener:@since 2.0.0。用于把 classpath 路径以 log.debug() 输出,略

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

    • 这麽做的好处:可以通过属性文件外部化配置监听器,而不一定必须写在 spring.factories 里,更具弹性
    • 外部化配置的执行优先级,还是相对较低的,到这里才给与执行嘛
  6. 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 方式放进来的,一般不会使用到,留个印象即可
  3. LoggingApplicationListener:因为这时已经有 Bean 工厂了嘛,所以它做的事是:向工厂内放入 Bean

    • “springBootLoggingSystem” -> loggingSystem
    • “springBootLogFile” -> logFile
    • “springBootLoggerGroups” -> loggerGroups
  4. BackgroundPreinitializer:本事件达到时无动作
  5. RestartListener:SC 提供。把当前最新的上下文缓存起来而已,目前并未发现有实质性作用,可忽略
  6. 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 好用太多了
  5. BootstrapApplicationListener.CloseContextOnFailureApplicationListener:执行 context.close()

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


总结

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

文末彩蛋

福利继续。【BAT 的乌托邦】知识星球欢迎你的加入:

退出移动版