《SpringBoot揭秘：快速构建微服务体系》—第3章3.3节SpringApplication：SpringBoot程序启动的一站式解决方案

本节书摘来自华章出版社《springboot揭秘：快速构建微服务体系》一书中的第3章，第3.3节springapplication：springboot程序启动的一站式解决方案，作者王福强，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.3　springapplication：springboot程序启动的一站式解决方案

如果非说springboot微框架提供了点儿自己特有的东西，在核心类层面（各种场景下的自动配置一站式插拔模块，我们下一章再重点介绍），也就是springapplication了。

springapplication将一个典型的spring应用启动的流程“模板化”（这里是动词），在没有特殊需求的情况下，默认模板化后的执行流程就可以满足需求了；但有特殊需求也没关系，springapplication在合适的流程结点开放了一系列不同类型的扩展点，我们可以通过这些扩展点对springboot程序的启动和关闭过程进行扩展。

最“肤浅”的扩展或者配置是springapplication通过一系列设置方法（setters）开放的定制方式，比如，我们之前的启动类的main方法中只有一句：

springapplication.run(demoapplication.class, args);

但如果我们想通过springapplication的一系列设置方法来扩展启动行为，则可以用如下方式进行：

**提示：

设置自定义banner最简单的方式其实是把ascii art字符画放到一个资源文件，然后通过resourcebanner来加载：bootstrap.setbanner(new resourcebanner(new classpathresource("banner.txt")));**

大部分情况下，springapplication已经提供了很好的默认设置，所以，我们不再对这些表层进行探究了，因为对表层之下的东西进行探究才是我们的最终目的。

3.3.1　深入探索springapplication执行流程

springapplication的run方法的实现是我们本次旅程的主要线路， 该方法的主要流程大体可以归纳如下：

1）如果我们使用的是springapplication的静态run方法，那么，这个方法里面首先需要创建一个springapplication对象实例，然后调用这个创建好的springapplication的实例run方法。在springapplication实例初始化的时候，它会提前做几件事情：

根据classpath里面是否存在某个特征类（org.springframework.web.context.configurablewebapplicationcontext）来决定是否应该创建一个为web应用使用的applicationcontext类型，还是应该创建一个标准standalone应用使用的applicationcontext类型。

使用springfactoriesloader在应用的classpath中查找并加载所有可用的applicationcontextinitializer。

使用springfactoriesloader在应用的classpath中查找并加载所有可用的applicationlistener。

推断并设置main方法的定义类。

2）springapplication实例初始化完成并且完成设置后，就开始执行run方法的逻辑了，方法执行伊始，首先遍历执行所有通过springfactoriesloader可以查找到并加载的springapplicationrunlistener，调用它们的started()方法，告诉这些springapplicationrunlistener，“嘿，springboot应用要开始执行咯！”。

3）创建并配置当前springboot应用将要使用的environment（包括配置要使用的propertysource以及profile）。

4）遍历调用所有springapplicationrunlistener的environmentprepared()的方法，告诉它们：“当前springboot应用使用的environment准备好咯！”。

5）如果springapplication的showbanner属性被设置为true，则打印banner（springboot 1.3.x版本，这里应该是基于banner.mode决定banner的打印行为）。这一步的逻辑其实可以不关心，我认为唯一的用途就是“好玩”（just for fun）。

6）根据用户是否明确设置了applicationcontextclass类型以及初始化阶段的推断结果，决定该为当前springboot应用创建什么类型的applicationcontext并创建完成，然后根据条件决定是否添加shutdownhook，决定是否使用自定义的beannamegenerator，决定是否使用自定义的resourceloader，当然，最重要的，将之前准备好的environment设置给创建好的applicationcontext使用。

7）applicationcontext创建好之后，springapplication会再次借助spring-factoriesloader，查找并加载classpath中所有可用的applicationcontext-initializer，然后遍历调用这些applicationcontextinitializer的initialize (applicationcontext)方法来对已经创建好的applicationcontext进行进一步的处理。

8）遍历调用所有springapplicationrunlistener的contextprepared()方法， 通知它们：“springboot应用使用的applicationcontext准备好啦！”

9）最核心的一步，将之前通过@enableautoconfiguration获取的所有配置以及其他形式的ioc容器配置加载到已经准备完毕的applicationcontext。

10）遍历调用所有springapplicationrunlistener的contextloaded()方法，告知所有springapplicationrunlistener，applicationcontext"装填完毕"!

11）调用applicationcontext的refresh()方法，完成ioc容器可用的最后一道工序。

12）查找当前applicationcontext中是否注册有commandlinerunner，如果有，则遍历执行它们。

13）正常情况下，遍历执行springapplicationrunlistener的finished()方法，告知它们：“搞定！”。（如果整个过程出现异常，则依然调用所有springapplicationrunlistener的finished()方法，只不过这种情况下会将异常信息一并传入处理）。

至此，一个完整的springboot应用启动完毕！

整个过程看起来冗长无比，但其实很多都是一些事件通知的扩展点，如果我们将这些逻辑暂时忽略，那么，其实整个springboot应用启动的逻辑就可以压缩到极其精简的几步，如图3-2所示。

前后对比我们就可以发现，其实springapplication提供的这些各类扩展点近乎“喧宾夺主”，占据了一个spring应用启动逻辑的大部分“江山”，除了初始化并准备好applicationcontext，剩下的大部分工作都是通过这些扩展点完成的，所以，我们有必要对各类扩展点进行逐一剖析，以便在需要的时候可以信手拈来，为我所用。

3.3.2　springapplicationrunlistener

springapplicationrunlistener是一个只有springboot应用的main方法执行过程中接收不同执行时点事件通知的监听者：

对于我们来说，基本没什么常见的场景需要自己实现一个spring-applicationrunlistener，即使springboot默认也只是实现了一个org.spring-framework.boot.context.event.eventpublishingrunlistener，用于在springboot启动的不同时点发布不同的应用事件类型（applicationevent），如果有哪些applicationlistener对这些应用事件感兴趣，则可以接收并处理。（还记得springapplication实例初始化的时候加载了一批applicationlistener，但是在run方法执行流程中却没有被使用的丝毫痕迹吗？eventpublishingrunlistener就是答案！）

假设我们真的有场景需要自定义一个springapplicationrunlistener实现，那么有一点需要注意，即任何一个springapplicationrunlistener实现类的构造方法（constructor）需要有两个构造参数，一个构造参数的类型就是我们的org.springframework.boot.springapplication，另外一个就是args参数列表的string[]：

之后，我们可以通过springfactoriesloader立下的规矩，在当前springboot应用的classpath下的meta-inf/spring.factories文件中进行类似如下的配置：

org.springframework.boot.springapplicationrunlistener=\

com.keevol.springboot.demo.demospringapplicationrunlistener

然后springapplication就会在运行的时候调用它啦！

3.3.3　applicationlistener

applicationlistener其实是老面孔，属于spring框架对java中实现的监听者模式的一种框架实现，这里唯一值得着重强调的是，对于初次接触springboot，但对spring框架本身又没有过多接触的开发者来说，可能会将这个名字与springapplicationrunlistener混淆。

关于applicationlistener我们就不做过多介绍了，如果感兴趣，请参考spring框架相关的资料和书籍。

如果我们要为springboot应用添加自定义的applicationlistener，有两种方式：

1）通过springapplication.addlisteners(..)或者springapplication.setlisteners(..)方法添加一个或者多个自定义的applicationlistener；

2）借助springfactoriesloader机制，在meta-inf/spring.factories文件中添加配置（以下代码是为springboot默认注册的applicationlistener配置）：

关于applicationlistener，我们就说这些。

3.3.4　applicationcontextinitializer

applicationcontextinitializer也是spring框架原有的概念，这个类的主要目的就是在configurableapplicationcontext类型（或者子类型）的applicationcontext做refresh之前，允许我们对configurableapplicationcontext的实例做进一步的设置或者处理。

实现一个applicationcontextinitializer很简单，因为它只有一个方法需要实现：

不过，一般情况下我们基本不会需要自定义一个applicationcontext-initializer，即使springboot框架默认也只是注册了三个实现：

如果我们真的需要自定义一个applicationcontextinitializer，那么只要像上面这样，通过springfactoriesloader机制进行配置，或者通过springapplication.addinitializers(..)设置即可。

3.3.5　commandlinerunner

commandlinerunner不是spring框架原有的“宝贝”，它属于springboot应用特定的回调扩展接口：

commandlinerunner需要大家关注的其实就两点：

1）所有commandlinerunner的执行时点在springboot应用的application-context完全初始化开始工作之后（可以认为是main方法执行完成之前最后一步）。

2）只要存在于当前springboot应用的applicationcontext中的任何command-linerunner，都会被加载执行（不管你是手动注册这个commandlinerunner到ioc容器，还是自动扫描进去的）。

与其他几个扩展点接口类型相似，建议commandlinerunner的实现类使用@org.springframework.core.annotation.order进行标注或者实现org.springframework.core.ordered接口，便于对它们的执行顺序进行调整，这其实十分重要，我们不希望顺序不当的commandlinerunner实现类阻塞了后面其他commandlinerunner的执行。

commandlinerunner是很好的扩展接口，大家可以重点关注，我们在后面的扩展和微服务实践章节会再次遇到它。