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

可能会出现三种结果:

  1. WebApplicationType.REACTIVE - 当类路径中存在REACTIVE_WEB_ENVIRONMENT_CLASS并且不存在MVC_WEB_ENVIRONMENT_CLASS时

  2. WebApplicationType.NONE - 也就是非Web型应用(Standard型),此时类路径中不包含WEB_ENVIRONMENT_CLASSES中定义的任何一个类时

  3. 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以及参数来准备环境

配置环境的方法:

所以这里实际上也包含了两个步骤:

  1. 配置Property Sources

  2. 配置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可以是两个接口的实现类:

  1. org.springframework.boot.ApplicationRunner

  2. org.springframework.boot.CommandLineRunner

这两个接口有什么区别呢:

其实没有什么不同之处,除了接口中的run方法接受的参数类型是不一样的以外。一个是封装好的ApplicationArguments类型,另一个是直接的String不定长数组类型。因此根据需要选择相应的接口实现即可。

至此,SpringApplication的run方法就分析完毕了。

3. 总结

本文分析了Spring Boot启动时的关键步骤,主要包含以下两个方面:

  1. SpringApplication实例的构建过程

    其中主要涉及到了初始化器(Initializer)以及监听器(Listener)这两大概念,它们都通过META-INF/spring.factories完成定义。

  2. SpringApplication实例run方法的执行过程

    其中主要有一个SpringApplicationRunListeners的概念,它作为Spring Boot容器初始化时各阶段事件的中转器,将事件派发给感兴趣的Listeners(在SpringApplication实例的构建过程中得到的)。这些阶段性事件将容器的初始化过程给构造起来,提供了比较强大的可扩展性。

如果从可扩展性的角度出发,应用开发者可以在Spring Boot容器的启动阶段,扩展哪些内容呢:

  1. 初始化器(Initializer)

  2. 监听器(Listener)

  3. 容器刷新后置Runners(ApplicationRunner或者CommandLineRunner接口的实现类)

  4. 启动期间在Console打印Banner的具体实现类

因此在下一篇文章中,将介绍如何对Spring Boot容器的启动过程进行扩展,实现对该过程的定制化。

参考

https://blog.csdn.net/dm_vincent/article/details/76735888

Last updated

Was this helpful?