SpringBoot启动过程源码分析
关于Spring Boot,已经有很多介绍其如何使用的文章了,本文从源代码(基于Spring-boot 1.5.6)的角度来看看Spring Boot的启动过程到底是怎么样的,为何以往纷繁复杂的配置到如今可以这么简便。
1. 入口类
package com.example.demo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class DemoApplication {
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
}以上的代码就是通过Spring Initializr配置生成的一个最简单的Web项目(只引入了Web功能)的入口方法。这个想必只要是接触过Spring Boot都会很熟悉。简单的方法背后掩藏的是Spring Boot在启动过程中的复杂性,本文的目的就是一探这里面的究竟。
1.1 注解@SpringBootApplication
而在看这个方法的实现之前,需要看看@SpringBootApplication这个注解的功能:
很明显的,这个注解就是三个常用在一起的注解@SpringBootConfiguration,@EnableAutoConfiguration以及@ComponentScan的组合,并没有什么高深的地方。
1.1.1 @SpringBootConfiguration
这个注解实际上和@Configuration有相同的作用,配备了该注解的类就能够以JavaConfig的方式完成一些配置,可以不再使用XML配置。
1.1.2 @ComponentScan
顾名思义,这个注解完成的是自动扫描的功能,相当于Spring XML配置文件中的:
可以使用basePackages属性指定要扫描的包,以及扫描的条件。如果不设置的话默认扫描@ComponentScan注解所在类的同级类和同级目录下的所有类,所以对于一个Spring Boot项目,一般会把入口类放在顶层目录中,这样就能够保证源码目录下的所有类都能够被扫描到。
1.1.3 @EnableAutoConfiguration
这个注解是让Spring Boot的配置能够如此简化的关键性注解。目前知道这个注解的作用就可以了,关于自动配置不再本文讨论范围内,后面如果有机会另起文章专门分析这个自动配置的实现原理。
2. 入口方法
2.1 SpringApplication的实例化
介绍完了入口类,下面开始分析关键方法:
相应实现:
它实际上会构造一个SpringApplication的实例,然后运行它的run方法:
在构造函数中,主要做了4件事情:
2.1.1 推断应用类型是Standard还是Web
可能会出现三种结果:
WebApplicationType.REACTIVE - 当类路径中存在REACTIVE_WEB_ENVIRONMENT_CLASS并且不存在MVC_WEB_ENVIRONMENT_CLASS时
WebApplicationType.NONE - 也就是非Web型应用(Standard型),此时类路径中不包含WEB_ENVIRONMENT_CLASSES中定义的任何一个类时
WebApplicationType.SERVLET - 类路径中包含了WEB_ENVIRONMENT_CLASSES中定义的所有类型时
2.1.2 设置初始化器(Initializer)
这里出现了一个新的概念 - 初始化器。
先来看看代码,再来尝试解释一下它是干嘛的:
这里面首先会根据入参type读取所有的names(是一个String集合),然后根据这个集合来完成对应的实例化操作:
这个方法会尝试从类路径的META-INF/spring.factories处读取相应配置文件,然后进行遍历,读取配置文件中Key为:org.springframework.context.ApplicationContextInitializer的value。以spring-boot-autoconfigure这个包为例,它的META-INF/spring.factories部分定义如下所示:
因此这两个类名会被读取出来,然后放入到集合中,准备开始下面的实例化操作:
初始化步骤很直观,没什么好说的,类加载,确认被加载的类确实是org.springframework.context.ApplicationContextInitializer的子类,然后就是得到构造器进行初始化,最后放入到实例列表中。
因此,所谓的初始化器就是org.springframework.context.ApplicationContextInitializer的实现类,这个接口是这样定义的:
根据类文档,这个接口的主要功能是:
在Spring上下文被刷新之前进行初始化的操作。典型地比如在Web应用中,注册Property Sources或者是激活Profiles。Property Sources比较好理解,就是配置文件。Profiles是Spring为了在不同环境下(如DEV,TEST,PRODUCTION等),加载不同的配置项而抽象出来的一个实体。
ApplicationContextInitializer是一个回调接口,它会在ConfigurableApplicationContext的refresh()方法调用之前被调用,做一些容器的初始化工作。这一点我们也可以通过SpringApplication的实例run方法的实现代码得到验证,为了说明问题,再次贴一下这段代码,注意下标红的代码和注释就自然理解了。
SpringBoot默认情况下提供了6个initializer,分别由2个jar提供:
spring-boot-1.5.2.RELEASE.jar
org.springframework.boot.context.ConfigurationWarningsApplicationContextInitializer,
org.springframework.boot.context.ContextIdApplicationContextInitializer,
org.springframework.boot.context.config.DelegatingApplicationContextInitializer,
org.springframework.boot.context.embedded.ServerPortInfoApplicationContextInitializer
spring-boot-autoconfigure-1.5.2.RELEASE.jar
org.springframework.boot.autoconfigure.SharedMetadataReaderFactoryContextInitializer,
org.springframework.boot.autoconfigure.logging.AutoConfigurationReportLoggingInitializer
2.1.3. 设置监听器(Listener)
设置完了初始化器,下面开始设置监听器:
同样地,监听器也是一个新概念,还是从代码入手:
可以发现,这个加载相应的类名,然后完成实例化的过程和上面在设置初始化器时如出一辙,同样,还是以spring-boot-autoconfigure这个包中的spring.factories为例,看看相应的Key-Value:
至于ApplicationListener接口,它是Spring框架中一个相当基础的接口了,代码如下:
这个接口基于JDK中的EventListener接口,实现了观察者模式。对于Spring框架的观察者模式实现,它限定感兴趣的事件类型需要是ApplicationEvent类型的子类,而这个类同样是继承自JDK中的EventObject类。
2.1.4. 推断应用入口类
这个方法的实现有点意思:
它通过构造一个运行时异常,通过异常栈中方法名为main的栈帧来得到入口类的名字。
至此,对于SpringApplication实例的初始化过程就结束了。
2.2 SpringApplication.run方法
完成了实例化,下面开始调用run方法:
这个run方法包含的内容也是有点多的,根据上面列举出的关键步骤逐个进行分析:
2.2.1 第一步 - 获取所谓的run listeners:
这里仍然利用了getSpringFactoriesInstances方法来获取实例:
所以这里还是故技重施,从META-INF/spring.factories中读取Key为org.springframework.boot.SpringApplicationRunListener的Values:
比如在spring-boot包中的定义的spring.factories:
我们来看看这个EventPublishingRunListener是干嘛的:
从类文档可以看出,它主要是负责发布SpringApplicationEvent事件的,它会利用一个内部的ApplicationEventMulticaster在上下文实际被刷新之前对事件进行处理。至于具体的应用场景,后面用到的时候再来分析。
2.2.2 第二步 - 根据SpringApplicationRunListeners以及参数来准备环境
配置环境的方法:
所以这里实际上也包含了两个步骤:
配置Property Sources
配置Profiles
具体实现这里就不展开了,代码也比较直观。
对于Web应用而言,得到的environment变量是一个StandardServletEnvironment的实例。得到实例后,会调用前面RunListeners中的environmentPrepared方法:
在这里,定义的广播器就派上用场了,它会发布一个ApplicationEnvironmentPreparedEvent事件。
那么有发布就有监听,在构建SpringApplication实例的时候不是初始化过一些ApplicationListeners嘛,其中的Listener就可能会监听ApplicationEnvironmentPreparedEvent事件,然后进行相应处理。
所以这里SpringApplicationRunListeners的用途和目的也比较明显了,它实际上是一个事件中转器,它能够感知到Spring Boot启动过程中产生的事件,然后有选择性的将事件进行中转。为何是有选择性的,看看它的实现就知道了:
它的contextPrepared方法实现为空,没有利用内部的initialMulticaster进行事件的派发。因此即便是外部有ApplicationListener对这个事件有兴趣,也是没有办法监听到的。
那么既然有事件的转发,是谁在监听这些事件呢,在这个类的构造器中交待了:
前面在构建SpringApplication实例过程中设置的监听器在这里被逐个添加到了initialMulticaster对应的ApplicationListener列表中。所以当initialMulticaster调用multicastEvent方法时,这些Listeners中定义的相应方法就会被触发了。
2.2.3 第三步 - 创建Spring上下文
这个上下文类型的类图如下所示:
这也是相当复杂的一个类图了,如果能把这张图中的各个类型的作用弄清楚,估计也是一个Spring大神了 :)
对于我们的Web应用,上下文类型就是DEFAULT_WEB_CONTEXT_CLASS。
2.2.4 第四步 - Spring上下文前置处理
关键步骤:
配置Bean生成器以及资源加载器(如果它们非空):
调用初始化器
这里终于用到了在创建SpringApplication实例时设置的初始化器了,依次对它们进行遍历,并调用initialize方法。
2.2.5 第五步 - Spring上下文刷新
注册关闭容器时的钩子函数的默认实现是在AbstractApplicationContext类中:
如果没有提供自定义的shutdownHook,那么会生成一个默认的,并添加到Runtime中。默认行为就是调用它的doClose方法,完成一些容器销毁时的清理工作。
2.2.6 第六步 - Spring上下文后置处理
所谓的后置操作,就是在容器完成刷新后,依次调用注册的Runners。Runners可以是两个接口的实现类:
org.springframework.boot.ApplicationRunner
org.springframework.boot.CommandLineRunner
这两个接口有什么区别呢:
其实没有什么不同之处,除了接口中的run方法接受的参数类型是不一样的以外。一个是封装好的ApplicationArguments类型,另一个是直接的String不定长数组类型。因此根据需要选择相应的接口实现即可。
至此,SpringApplication的run方法就分析完毕了。
3. 总结
本文分析了Spring Boot启动时的关键步骤,主要包含以下两个方面:
SpringApplication实例的构建过程
其中主要涉及到了初始化器(Initializer)以及监听器(Listener)这两大概念,它们都通过META-INF/spring.factories完成定义。
SpringApplication实例run方法的执行过程
其中主要有一个SpringApplicationRunListeners的概念,它作为Spring Boot容器初始化时各阶段事件的中转器,将事件派发给感兴趣的Listeners(在SpringApplication实例的构建过程中得到的)。这些阶段性事件将容器的初始化过程给构造起来,提供了比较强大的可扩展性。
如果从可扩展性的角度出发,应用开发者可以在Spring Boot容器的启动阶段,扩展哪些内容呢:
初始化器(Initializer)
监听器(Listener)
容器刷新后置Runners(ApplicationRunner或者CommandLineRunner接口的实现类)
启动期间在Console打印Banner的具体实现类
因此在下一篇文章中,将介绍如何对Spring Boot容器的启动过程进行扩展,实现对该过程的定制化。
参考
Last updated
Was this helpful?