一文了解Spring Boot启动类SpringApplication

spring,boot,springapplication · 浏览次数 : 7

小编点评

本文主要介绍了Spring Boot启动过程中的源码分析和关键知识点。文章从Spring Boot启动类SpringApplication入手,逐步解析了SpringApplication的实例化过程、Web应用类型推断、BootstrapRegistryInitializer的加载、ApplicationContextInitializers的加载以及应用入口类的推断。 1. **Spring Boot启动过程**:文章首先介绍了Spring Boot应用程序的启动过程,通过查看SpringApplication的run方法源码,了解到SpringApplication实例化的主要步骤。 2. **SpringApplication的实例化**:接着,文章详细分析了SpringApplication的构造方法参数,包括ResourceLoader和primarySources,以及如何通过不同的方式启动Spring Boot项目。 3. **Web应用类型推断**:文章解释了SpringApplication如何根据类路径中的类来确定Web应用的类型,包括Servlet应用、Reactive应用等。 4. **BootstrapRegistryInitializer的加载**:文章讨论了BootstrapRegistryInitializer的作用和如何在Spring Boot启动时加载它。 5. **ApplicationContextInitializers的加载**:文章说明了如何加载ApplicationContextInitializers,以及它们在Spring容器启动时的作用。 6. **应用入口类的推断**:最后,文章介绍了SpringApplication如何推断应用入口类,以确保正确加载主类。 总的来说,本文通过对SpringApplication的源码分析,揭示了Spring Boot启动过程中的关键步骤和组件,帮助读者更好地理解Spring Boot的运行机制。

正文

本文分享自华为云社区《【Spring Boot 源码学习】初识 SpringApplication》,作者: Huazie。

引言

往期的博文,Huazie 围绕 Spring Boot 的核心功能,带大家从总整体上了解 Spring Boot 自动配置的原理以及自动配置核心组件的运作过程。这些内容大家需要重点关注,只有了解这些基础的组件和功能,我们在后续集成其他三方类库的 Starters 时,才能够更加清晰地了解它们都运用了自动配置的哪些功能。

在学习上述 Spring Boot 核心功能的过程中,相信大家可能都会尝试启动自己新建的 Spring Boot 的项目,并 Debug 看看具体的执行过程。本篇开始就将从 Spring Boot 的启动类 SpringApplication 上入手,带领大家了解 Spring Boot 启动过程中所涉及到的源码和知识点。

主要内容

1. Spring Boot 应用程序的启动

在 《【Spring Boot 源码学习】@SpringBootApplication 注解》这篇博文中,我们新建了一个基于 Spring Boot 的测试项目。

image.png

如上图中的 DemoApplication 就是我们这里 Spring Boot 项目的入口类。

同时,我们可以看到 DemoApplication 的 main 方法中,直接调用了 SpringApplication 的静态方法 run,用于启动整个 Spring Boot 项目。

先来看看 run 方法的源码:

public static ConfigurableApplicationContext run(Class<?> primarySource, String... args) {
    return run(new Class<?>[] { primarySource }, args);
}

public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) {
    return new SpringApplication(primarySources).run(args);
}

阅读上述 run 方法,我们可以看到实际上是 new 了一个SpringApplication 对象【其构造参数 primarySources 为加载的主要资源类,通常就是 SpringBoot 的入口类】,并调用其 run 方法【其参数 args 为传递给应用程序的参数信息】启动,然后返回一个应用上下文对象 ConfigurableApplicationContext 。

通过观察这个内部的 run 方法实现,我们也可以在自己的 Spring Boot 启动入口类中,像如下这样去写 :

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication springApplication = new SpringApplication(DemoApplication.class);
        // 这里可以调用 SpringApplication 提供的 setXX 或 addXX 方法来定制化设置
        springApplication.run(args);
    }

}

2. SpringApplication 的实例化

上面已经看到我们在实例化 SpringApplication 了,废话不多说,直接翻看其源码【Spring Boot 2.7.9】:

    public SpringApplication(Class<?>... primarySources) {
        this(null, primarySources);
    }

    @SuppressWarnings({ "unchecked", "rawtypes" })
    public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
        this.resourceLoader = resourceLoader;
        Assert.notNull(primarySources, "PrimarySources must not be null");
        this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources));
        // 推断web应用类型
        this.webApplicationType = WebApplicationType.deduceFromClasspath();
        // 加载并初始化 BootstrapRegistryInitializer及其实现类
        this.bootstrapRegistryInitializers = new ArrayList<>(
                getSpringFactoriesInstances(BootstrapRegistryInitializer.class));
        // 加载并初始化 ApplicationContextInitializer及其实现类
        setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));
        // 加载并初始化ApplicationListener及其实现类
        setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
        // 推断入口类
        this.mainApplicationClass = deduceMainApplicationClass();
    }

由上可知,SpringApplication 提供了两个构造方法,而其核心的逻辑都在第二个构造方法中实现。

2.1 构造方法参数

我们从上述源码可知,SpringApplication 的第二个构造方法有两个参数,分别是:

ResourceLoader resourceLoader :ResourceLoader 为资源加载的接口,它用于在Spring Boot 启动时打印对应的 banner 信息,默认采用的就是 DefaultResourceLoader。实操过程中,如果未按照 Spring Boot 的 “约定” 将 banner 的内容放置于 classpath 下,或者文件名不是 banner.* 格式,默认资源加载器是无法加载到对应的 banner 信息的,此时则可通过 ResourceLoader 来指定需要加载的文件路径【这个后面我们专门来实操一下,敬请期待】。

Class<?>... primarySources :主要的 bean 来源,该参数为可变参数,默认我们会传入 Spring Boot 的入口类【即 main 方法所在的类】,如上面我们的 DemoApplication 。如果作为项目的引导类,该类需要满足一个条件,就是被注解 @EnableAutoConfiguration 或其组合注解标注。在前面的《【Spring Boot 源码学习】@SpringBootApplication 注解》博文中,我们已经知道 @SpringBootApplication 注解中包含了 @EnableAutoConfiguration 注解,因此被 @SpringBootApplication 注解标注的类也可作为参数传入。当然,primarySources 也可传入其他普通类,但只有传入被@EnableAutoConfiguration 标注的类才能够开启 Spring Boot 的自动配置。

有些朋友,可能对 primarySources 这个可变参数的描述有点疑惑,下面我们就用实例来演示以其他引导类为入口类进行 Spring Boot 项目启动:

首先,我们在入口类 DemoApplication 的同级目录创建一个SecondApplication类,使用 @SpringBootApplication 进行注解。

@SpringBootApplication
public class SecondApplication {
}

然后,将 DemoApplication 修改成如下:

public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(SecondApplication.class, args);
    }
}

最后,我们来运行 DemoApplication 的 main 方法。

image.png

 从上图可以看出,我们的应用依然能正常启动,并完成自动配置。因此,决定 Spring Boot 启动的入口类并不是一定是 main 方法所在类,而是直接或间接被 @EnableAutoConfiguration 标注的类。

翻看 SpringApplication 的源码,我们在其中还能看到它提供了追加 primarySources 的方法,如下所示:

public void addPrimarySources(Collection<Class<?>> additionalPrimarySources) {
    this.primarySources.addAll(additionalPrimarySources);
}

如果采用 1 中最后的方式启动 Spring Boot ,我们就可以调用 addPrimarySources 方法来追加额外的 primarySources

我们继续回到 SpringApplication 的构造方法里,可以看到如下的代码:

this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources));

上述这里将 primarySources 参数转换为 LinkedHashSet 集合,并赋值给SpringApplication 的私有成员变量 Set<Class<?>> primarySources

知识点: LinkedHashSet 是 Java 集合框架中的类,它继承自 HashSet,因此具有哈希表的查找性能。这是一个同时使用链表和哈希表特性的数据结构,其中链表用于维护元素的插入顺序。也即是说,当你向 LinkedHashSet 添加元素时,元素将按照添加的顺序被存储,并且能够被遍历输出。

此外,LinkedHashSet 还确保了 元素的唯一性,即重复的元素在集合中只会存在一份。

如果需要频繁遍历集合,那么 LinkedHashSet 可能会比 HashSet 效率更高,因为其通过维护一个双向链表来记录元素的添加顺序,从而支持按照插入顺序排序的迭代。但需要注意的是,LinkedHashSet 是非线程安全的,如果有多个线程同时访问该集合容器,可能会引发并发问题。

2.2 Web 应用类型推断

我们继续往下翻看源码,这里调用了 WebApplicationType 的deduceFromClasspath 方法来进行 Web 应用类型的推断。

this.webApplicationType = WebApplicationType.deduceFromClasspath();

我们继续翻看 WebApplicationType 的源码:

public enum WebApplicationType {
    // 非Web应用类型
    NONE,
    // 基于Servlet的Web应用类型
    SERVLET,
    // 基于reactive的Web应用类型
    REACTIVE;

    private static final String[] SERVLET_INDICATOR_CLASSES = { "javax.servlet.Servlet",
            "org.springframework.web.context.ConfigurableWebApplicationContext" };

    private static final String WEBMVC_INDICATOR_CLASS = "org.springframework.web.servlet.DispatcherServlet";

    private static final String WEBFLUX_INDICATOR_CLASS = "org.springframework.web.reactive.DispatcherHandler";

    private static final String JERSEY_INDICATOR_CLASS = "org.glassfish.jersey.servlet.ServletContainer";

    static WebApplicationType deduceFromClasspath() {
        if (ClassUtils.isPresent(WEBFLUX_INDICATOR_CLASS, null) && !ClassUtils.isPresent(WEBMVC_INDICATOR_CLASS, null)
                && !ClassUtils.isPresent(JERSEY_INDICATOR_CLASS, null)) {
            return WebApplicationType.REACTIVE;
        }
        for (String className : SERVLET_INDICATOR_CLASSES) {
            if (!ClassUtils.isPresent(className, null)) {
                return WebApplicationType.NONE;
            }
        }
        return WebApplicationType.SERVLET;
    }
}

WebApplicationType 是一个定义了可能的Web应用类型的枚举类,该枚举类中包含了三块逻辑:

枚举类型 :非 Web 应用、基于 Servlet 的 Web 应用和基于 reactive 的 Web 应用。

用于下面推断的常量

推断类型的方法 deduceFromClasspath :

当 DispatcherHandler 存在,并且 DispatcherServlet 和 ServletContainer 都不存在,则返回类型为 WebApplicationType.REACTIVE

当 Servlet 或 ConfigurableWebApplicationContext 任何一个不存在时,则说明当前应用为非 Web 应用,返回 WebApplicationType.NONE

当应用不为 reactive Web 应用,并且 Servlet 和ConfigurableWebApplicationContext 都存在的情况下,则返回 WebApplicationType.SERVLET

在上述的 deduceFromClasspath 方法中,我们可以看到,在判断的过程中使用到了 ClassUtils 的 isPresent 方法。该工具类方法就是通过反射创建指定的类,根据在创建过程中是否抛出异常来判断该类是否存在。

image.png

2.3 加载 BootstrapRegistryInitializer

this.bootstrapRegistryInitializers = new ArrayList<>(
        getSpringFactoriesInstances(BootstrapRegistryInitializer.class));

上述逻辑用于加载并初始化 BootstrapRegistryInitializer 及其相关的类。

BootstrapRegistryInitializer 是 Spring Cloud Config 的组件之一,它的作用是在应用程序启动时初始化 Spring Cloud Config 客户端。

在 Spring Cloud Config 中,客户端通过向配置中心(Config Server)发送请求来获取应用程序的配置信息。而 BootstrapRegistryInitializer 就是负责将配置中心的相关信息注册到 Spring 容器中的。

由于篇幅有限,有关 BootstrapRegistryInitializer 更详细的内容,笔者后续专门讲解。

2.4 加载 ApplicationContextInitializer

setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));

上述代码用于加载并初始化 ApplicationContextInitializer 及其相关的类。

ApplicationContextInitializer 是 Spring 框架中的一个接口,它的主要作用是在Spring容器刷新之前初始化 ConfigurableApplicationContext。这个接口的实现类可以被视为回调函数,它们的 onApplicationEvent 方法会在Spring 容器启动时被自动调用,从而允许开发人员在容器刷新之前执行一些自定义的操作。

例如,我们可能需要在这个时刻加载一些配置信息,或者对某些 bean 进行预处理等。通过实现 ApplicationContextInitializer 接口并重写其onApplicationEvent 方法,就可以完成这些定制化的需求。

由于篇幅有限,有关 ApplicationContextInitializer 更详细的内容,笔者后续专门讲解。

2.5 加载 ApplicationListener

setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));

上述代码用于加载并初始化 ApplicationListener 及其相关的类。

ApplicationListener 是 Spring 框架提供的一个事件监听机制,它是Spring 应用内部的事件驱动机制,通常被用于监控应用内部的运行状况。其实现的原理是 观察者设计模式,该设计模式的初衷是为了实现系统业务逻辑之间的解耦,从而提升系统的可扩展性和可维护性。

我们可以通过自定义一个类来实现 ApplicationListener 接口,然后在这个类中定义需要监听的事件处理方法。当被监听的事件发生时,Spring 会自动调用这个方法来处理事件。例如,在一个 Spring Boot 项目中,我们可能想要在容器启动时执行一些特定的操作,如加载配置等,就可以通过实现 ApplicationListener 接口来完成。

由于篇幅有限,有关 ApplicationListener 更详细的内容,笔者后续专门讲解。

2.6 推断应用入口类

最后一步,调用 SpringApplication 的 deduceMainApplicationClass 方法来进行入口类的推断:

private Class<?> deduceMainApplicationClass() {
    try {
        StackTraceElement[] stackTrace = new RuntimeException().getStackTrace();
        for (StackTraceElement stackTraceElement : stackTrace) {
            if ("main".equals(stackTraceElement.getMethodName())) {
                return Class.forName(stackTraceElement.getClassName());
            }
        }
    } catch (ClassNotFoundException ex) {
        // 这里捕获异常,并继续执行后续逻辑
    }
    return null;
}

上述代码的思路就是:

  • 首先,创建一个运行时异常,并获得其堆栈数组。
  • 接着,遍历数组,判断类的方法中是否包含 main 方法。第一个被匹配的类会通过Class.forName 方法创建对象,并将其被返回。
  • 最后,将上述创建的 Class 对象赋值给 SpringApplication 的成员变量 mainApplicationClass

总结

本篇 Huazie 带大家初步了解了 SpringApplication 的实例化过程,当然由于篇幅受限,还有些内容暂时无法详解,Huazie 将在后续的博文中继续深入分析。

只有了解 Spring Boot 在启动时都做了些什么,我们才能在后续的实践的过程中更好地理解其运行机制,以便遇到问题能更快地定位和排查,使我们应用能够更容易、更方便地接入 Spring Boot 。

 

点击关注,第一时间了解华为云新鲜技术~

 

与一文了解Spring Boot启动类SpringApplication相似的内容:

一文了解Spring Boot启动类SpringApplication

只有了解 Spring Boot 在启动时都做了些什么,我们才能在后续的实践的过程中更好地理解其运行机制,以便遇到问题能更快地定位和排查。

[转帖]记录一次spring-boot程序内存泄露排查

现象 spring boot项目jvm启动配置-Xms4g -Xmx4g,然而很不幸的是程序所占的内存越来越高,都达到了12个多G,只能临时重启服务 常用命令 jstat -class PIDjstat -compiler PIDjstat -gc PIDjstat -gccapacity PIDj

[转帖]Spring Boot中Tomcat是怎么启动的

https://zhuanlan.zhihu.com/p/208318177 Spring Boot一个非常突出的优点就是不需要我们额外再部署Servlet容器,它内置了多种容器的支持。我们可以通过配置来指定我们需要的容器。 本文以我们平时最常使用的容器Tomcat为列来介绍以下两个知识点: Spr

[转帖]总结:SpringBoot启动参数配置

一、背景 由于项目中加了bootstrap.properties文件,且文件中有变量,如spring.cloud.config.profile=${spring.profiles.active},而bootstrap.properties读取的优先级高于application.properties,

Springboot下micrometer+prometheus+grafana进行JVM监控的操作过程

Springboot下micrometer+prometheus+grafana进行JVM监控的操作过程 背景 同事今天提交了一个补丁. 给基于Springboot的产品增加了micrometer等收集jvm信息的工具 但是这边springboot的版本比较高,导致有异常. 启动直接失败了. 晚上九

SpringBoot内置tomcat启动过程及原理

作者:李岩科 1 背景 SpringBoot 是一个框架,一种全新的编程规范,他的产生简化了框架的使用,同时也提供了很多便捷的功能,比如内置 tomcat 就是其中一项,他让我们省去了搭建 tomcat 容器,生成 war,部署,启动 tomcat。因为内置了启动容器,应用程序可以直接通过 Mave

聊聊Mybatis的实现原理

### 使用示例 平时我们使用的一般是集成了Spring或是Spring Boot的Mybatis,封装了一层,看源码不直接;如下,看看原生的Mybatis使用示例 ![image](https://img2023.cnblogs.com/blog/971683/202305/971683-2023

Spring Boot虚拟线程与Webflux在JWT验证和MySQL查询上的性能比较

早上看到一篇关于Spring Boot虚拟线程和Webflux性能对比的文章,觉得还不错。内容较长,我就不翻译了,抓重点给大家介绍一下这篇文章的核心内容,方便大家快速阅读。 测试场景 作者采用了一个尽可能贴近现实操作的场景: 从授权头信息中提取JWT 验证JWT并从中提取用户的Email 使用用户的

Spring Boot应用中如何动态指定数据库,实现不同用户不同数据库的场景

当在 Spring Boot 应用程序中使用Spring Data JPA 进行数据库操作时,配置Schema名称是一种常见的做法。然而,在某些情况下,模式名称需要是动态的,可能会在应用程序运行时发生变化。比如:需要做数据隔离的SaaS应用。 所以,这篇博文将帮助您解决了在 Spring Boot

Spring Boot中发送邮件时,如何让发件人显示别名

之前,我们通过一系列文章,介绍了如何在Spring Boot中发送邮件: 发送邮件 添加附件 引用静态资源 邮件模版 已经包含了大部分的应用场景。但最近DD在做YouTube中文配音的时候,碰到一个问题: 如上图所示,收件人在客户端收到的时候,显示的名称是邮箱的前缀,而不是我们的产品名称,也就是邮箱