SpringBoot SpringApplication构造函数解析：源码级深度剖析(32)

最新推荐文章于 2025-10-23 14:56:55 发布

Android 小码蜂

最新推荐文章于 2025-10-23 14:56:55 发布

阅读量668

点赞数 29

CC 4.0 BY-SA版权

分类专栏： SpringBoot框架详解文章标签： spring boot hive 后端 spring java restful

本文链接：https://blog.csdn.net/qq_28540861/article/details/148389202

SpringBoot框架详解专栏收录该内容

69 篇文章

订阅专栏

SpringBoot SpringApplication构造函数解析：源码级深度剖析

一、构造函数的核心定位与初始化流程

1.1 构造函数的重载设计与参数体系

SpringApplication提供了多个重载构造函数，形成了完整的参数体系：

基础构造函数接收Class<?>... primarySources，用于指定主配置类（如标注@SpringBootApplication的类）
扩展构造函数接收ResourceLoader，允许自定义资源加载机制
无参构造函数通过反射推断主配置类，体现"约定优于配置"原则

构造函数的参数处理逻辑遵循严格的优先级顺序：

优先使用显式传入的ResourceLoader
若未指定主配置类，则通过deduceMainApplicationClass()方法推断
所有参数最终被封装到SpringApplication实例的不可变字段中

1.2 初始化流程的阶段划分

构造函数的执行过程可分为三个核心阶段：

环境探测阶段：通过WebApplicationType.deduceFromClasspath()分析类路径，确定应用类型（Servlet/Reactive/非Web）
组件加载阶段：利用SpringFactoriesLoader加载初始化器（ApplicationContextInitializer）和监听器（ApplicationListener）
状态初始化阶段：设置资源加载器、主配置类集合，并推断主应用类

这三个阶段形成了清晰的初始化链条，确保后续run()方法能够基于完整的上下文环境启动。

二、Web应用类型的智能推断机制

2.1 类路径分析的核心算法

Web应用类型的推断基于类路径中关键类的存在性：

若存在org.springframework.web.reactive.DispatcherHandler且不存在org.springframework.web.servlet.DispatcherServlet，则判定为REACTIVE类型
若存在javax.servlet.Servlet和org.springframework.web.servlet.DispatcherServlet，则判定为SERVLET类型
否则判定为NONE类型（非Web应用）

这一算法通过ClassUtils.isPresent()方法实现，避免了类加载的开销：

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

2.2 应用类型对上下文的影响

不同的Web应用类型决定了后续创建的ApplicationContext类型：

SERVLET类型对应ServletWebServerApplicationContext
REACTIVE类型对应ReactiveWebServerApplicationContext
NONE类型对应AnnotationConfigApplicationContext

这种动态适配机制确保了应用上下文与运行环境的一致性，体现了SpringBoot的"自适应"设计理念。

三、初始化器与监听器的加载机制

3.1 SpringFactoriesLoader的工作原理

初始化器和监听器的加载依赖于SpringFactoriesLoader，这是Spring框架内置的SPI机制：

扫描所有依赖JAR包中的META-INF/spring.factories文件
解析文件中以接口全限定名作为键的实现类列表
使用反射实例化这些实现类

例如，加载ApplicationContextInitializer的代码：

private <T> Collection<T> getSpringFactoriesInstances(Class<T> type) {
    return getSpringFactoriesInstances(type, new Class<?>[] {});
}

private <T> Collection<T> getSpringFactoriesInstances(Class<T> type, Class<?>[] parameterTypes, Object... args) {
    ClassLoader classLoader = getClassLoader();
    // 使用SpringFactoriesLoader加载实现类
    Set<String> names = new LinkedHashSet<>(
        SpringFactoriesLoader.loadFactoryNames(type, classLoader));
    List<T> instances = createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names);
    AnnotationAwareOrderComparator.sort(instances);
    return instances;
}

3.2 初始化器的排序与执行策略

加载后的初始化器会通过AnnotationAwareOrderComparator进行排序，支持以下三种排序方式：

实现Ordered接口
使用@Order注解
实现PriorityOrdered接口（优先级最高）

初始化器的执行发生在run()方法的prepareContext()阶段，按照排序顺序依次调用initialize()方法，允许对ConfigurableApplicationContext进行定制。

四、主配置类的处理与存储

4.1 主配置类的核心作用

主配置类是SpringBoot应用的启动入口，通常包含以下关键注解：

@SpringBootApplication（组合了@Configuration、@EnableAutoConfiguration和@ComponentScan）
@Import（导入额外的配置类）
@ComponentScan（指定组件扫描路径）

构造函数将主配置类存储在primarySources集合中，该集合使用LinkedHashSet确保唯一性和顺序性。

4.2 主配置类的推断逻辑

当未显式指定主配置类时，构造函数通过以下逻辑推断：

获取当前线程的堆栈信息
遍历堆栈帧，查找包含main方法的类
使用反射获取该类的Class对象

这一机制在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;
}

五、资源加载器的配置与扩展

5.1 默认资源加载器的选择策略

构造函数中资源加载器的配置逻辑：

若用户通过构造函数参数传入ResourceLoader，则直接使用
否则创建默认的ClassPathResourceLoader
将资源加载器存储在resourceLoader字段中

默认的资源加载器实现为PathMatchingResourcePatternResolver，支持：

类路径资源加载（classpath:前缀）
通配符资源匹配（classpath*:前缀）
文件系统资源加载（file:前缀）

5.2 自定义资源加载器的应用场景

自定义资源加载器的典型场景包括：

从非标准位置加载配置文件（如网络路径）
实现资源加密/解密功能
定制资源缓存策略

通过构造函数传入自定义ResourceLoader后，后续的配置加载、自动配置扫描等操作都将使用该加载器，实现了资源加载的灵活定制。

六、构造函数与自动配置的关联

6.1 自动配置的触发条件

构造函数虽然不直接触发自动配置，但通过以下方式为自动配置奠定基础：

加载AutoConfigurationImportSelector（通过@EnableAutoConfiguration注解）
初始化Environment对象，用于条件注解评估
设置类加载器，确保自动配置类能够被正确加载

6.2 条件注解的预处理

构造函数中初始化的Environment对象包含了系统属性、环境变量等配置信息，这些信息在自动配置阶段用于评估@Conditional注解：

@ConditionalOnClass：检查类路径是否存在特定类
@ConditionalOnProperty：检查配置属性是否存在或具有特定值
@ConditionalOnWebApplication：检查应用类型

这种预处理机制确保了自动配置的选择性激活，提高了框架的灵活性和性能。

七、构造函数的异常处理机制

7.1 参数校验与断言

构造函数对关键参数进行严格校验：

主配置类集合不能为空
资源加载器必须实现ResourceLoader接口
初始化器和监听器列表不能包含null元素

这些校验通过Assert类实现，若校验失败则抛出IllegalArgumentException：

Assert.notNull(primarySources, "PrimarySources must not be null");
Assert.notNull(initializers, "Initializers must not be null");
Assert.notNull(listeners, "Listeners must not be null");

7.2 类加载异常的处理

在类路径扫描和反射实例化过程中，可能抛出以下异常：

ClassNotFoundException：类不存在
NoClassDefFoundError：类定义不可用
LinkageError：链接错误

构造函数通过捕获这些异常并记录警告日志，确保应用能够继续启动：

try {
    // 类加载操作
} catch (ClassNotFoundException | LinkageError ex) {
    logger.warn("Failed to load class: {}", ex.getMessage());
}

八、构造函数的扩展点与定制模式

8.1 自定义初始化器的注册

开发者可以通过以下方式注册自定义初始化器：

在META-INF/spring.factories中配置
在application.properties中指定
通过SpringApplication.addInitializers()方法添加

自定义初始化器可以实现以下功能：

修改应用上下文的配置
添加额外的属性源
注册自定义的BeanPostProcessor

8.2 监听器的事件处理机制

SpringApplication支持多种应用事件，如：

ApplicationStartingEvent：应用启动开始
ApplicationEnvironmentPreparedEvent：环境准备完成
ApplicationReadyEvent：应用就绪

自定义监听器可以实现ApplicationListener接口，监听特定事件并执行相应逻辑：

public class CustomApplicationListener implements ApplicationListener<ApplicationReadyEvent> {
    @Override
    public void onApplicationEvent(ApplicationReadyEvent event) {
        // 应用就绪后的处理逻辑
    }
}