发布日期: 2022-11-24

文章字数: 5.5k

阅读时长: 23 分

阅读次数:

Spring Boot 源码阅读——配置文件加载

开头

在 SpringBoot 中，配置文件是环境的一部分

“环境”，有一个专属的类—— Environment

里面包含了各种应用程序中重要的角色：配置文件、JVM 系统属性、系统环境变量、JNDI、servlet 上下文参数等等

这篇文章只对其中配置文件的部分进行解读，一些关系不大的代码用注释 // .. 替代，节省篇幅

找到 Environment

SpringBoot 的启动，是从一个 run 方法开始的

@SpringBootApplication
public class SpringbootTestApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringbootTestApplication.class, args);
    }
}

从这个 run 方法，一步一步点进去，就来到了下面这个方法

为了方便阅读，我省略了与本文无关的代码

SpringApplication.java

public ConfigurableApplicationContext run(String... args) {
    // ...
    try {
        // ...
        ConfigurableEnvironment environment = prepareEnvironment(listeners, bootstrapContext, applicationArguments);
        // ...
    }
    catch (Throwable ex) {
        // ...
    }
    // ...
    return context;
}

上面这段代码中，我只保留了一行代码

这是 run 方法中 Environment 对象的第一次出现，同时，也是环境初始化的地方：prepareEnvironment

环境初始化

创建实例

SpringApplication.java

private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners,
                                                   DefaultBootstrapContext bootstrapContext, ApplicationArguments applicationArguments) {
    // 根据应用程序类型，创建对应的 Environment 实例，并进行一些基本配置
    ConfigurableEnvironment environment = getOrCreateEnvironment();
    configureEnvironment(environment, applicationArguments.getSourceArgs());
    ConfigurationPropertySources.attach(environment);
    // 这里开始，正式对环境进行初始化
    listeners.environmentPrepared(bootstrapContext, environment);
    // ...
    return environment;
}

初始化——广播事件

这里的调用链比较长，满满往深处走，我们要找到事件广播到最后，被处理的地方

SpringApplicationRunListeners.java

void environmentPrepared(ConfigurableBootstrapContext bootstrapContext, ConfigurableEnvironment environment) {
    doWithListeners("spring.boot.application.environment-prepared",
                    (listener) -> listener.environmentPrepared(bootstrapContext, environment));
}

EventPublishingRunListener.java

@Override
public void environmentPrepared(ConfigurableBootstrapContext bootstrapContext,
                                ConfigurableEnvironment environment) {
    this.initialMulticaster.multicastEvent(
        new ApplicationEnvironmentPreparedEvent(bootstrapContext, this.application, this.args, environment));
}

SimpleApplicationEventMulticaster.java

@Override
public void multicastEvent(ApplicationEvent event) {
    multicastEvent(event, resolveDefaultEventType(event));
}

SimpleApplicationEventMulticaster.java

@Override
public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
    ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
    Executor executor = getTaskExecutor();
    for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {
        if (executor != null) {
            executor.execute(() -> invokeListener(listener, event));
        }
        else {
            invokeListener(listener, event);
        }
    }
}

SimpleApplicationEventMulticaster.java

protected void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
    ErrorHandler errorHandler = getErrorHandler();
    if (errorHandler != null) {
        try {
            doInvokeListener(listener, event);
        }
        catch (Throwable err) {
            errorHandler.handleError(err);
        }
    }
    else {
        doInvokeListener(listener, event);
    }
}

SimpleApplicationEventMulticaster.java

private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) {
    try {
        // 走到这就到底了，由各个事件监听器来执行相关操作
        listener.onApplicationEvent(event);
    }
    catch (ClassCastException ex) {
        // ..
    }
}

SpringBoot 自带的事件监听器有非常非常多，我们这里触发的时间是环境准备（environment-prepared），那么理所当然的，相关操作肯定在 EnvironmentPostProcessorApplicationListener 里面

EnvironmentPostProcessorApplicationListener.java

@Override
public void onApplicationEvent(ApplicationEvent event) {
    // 可以看到这个监听器只对三个事件进行了处理，正好有我们触发的这个事件
    if (event instanceof ApplicationEnvironmentPreparedEvent) {
        onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent) event);
    }
    if (event instanceof ApplicationPreparedEvent) {
        onApplicationPreparedEvent();
    }
    if (event instanceof ApplicationFailedEvent) {
        onApplicationFailedEvent();
    }
}

EnvironmentPostProcessorApplicationListener.java

private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
    ConfigurableEnvironment environment = event.getEnvironment();
    SpringApplication application = event.getSpringApplication();
    // 这个循环就是环境初始化的关键了，程序中有很多的后置处理器，包括我们的配置文件加载也在其中
    for (EnvironmentPostProcessor postProcessor : getEnvironmentPostProcessors(application.getResourceLoader(),
                                                                               event.getBootstrapContext())) {
        postProcessor.postProcessEnvironment(environment, application);
    }
}

SpringBoot 提供了两个配置文件处理器，其中 ConfigFileApplicationListener 是旧版本中的处理器，在新版本已废弃，并被 ConfigDataEnvironmentPostProcessor 取代

找到了配置文件的处理器，那么接下来就可以开始阅读源码了

ConfigDataEnvironmentPostProcessor.java

void postProcessEnvironment(ConfigurableEnvironment environment, ResourceLoader resourceLoader, Collection<String> additionalProfiles) {
    try {
        this.logger.trace("Post-processing environment to add config data");
        resourceLoader = (resourceLoader != null) ? resourceLoader : new DefaultResourceLoader();
        // getConfigDataEnvironment 是对环境的一层封装，对配置文件的读取是后面的那个方法：processAndApply()
        getConfigDataEnvironment(environment, resourceLoader, additionalProfiles).processAndApply();
    }
    catch (UseLegacyConfigProcessingException ex) {
        // ...
    }
}

ConfigDataEnvironment.java

void processAndApply() {
    // importer 是一个很关键的对象，包含了扫描的目录、扫描到的文件
    // 当然这里只是进行了实例化，还没有任何数据
    ConfigDataImporter importer = new ConfigDataImporter(this.logFactory, this.notFoundAction, this.resolvers,
                                                         this.loaders);
    registerBootstrapBinder(this.contributors, null, DENY_INACTIVE_BINDING);
    // processInitial 就是最核心的方法了，里面对所有 SpringBoot 约定的配置进行了扫描和加载
    // 下面会着重看这一部分代码
    ConfigDataEnvironmentContributors contributors = processInitial(this.contributors, importer);
    // 创建上下文环境
    ConfigDataActivationContext activationContext = createActivationContext(
        contributors.getBinder(null, BinderOption.FAIL_ON_BIND_TO_INACTIVE_SOURCE));
    // process 开头的方法，内部逻辑与 processInitial 相似，所以下面几行就不讲了
    // 区别就像方法名一样，processInitial 是初始化，这两个与激活相关
    contributors = processWithoutProfiles(contributors, importer, activationContext);
    activationContext = withProfiles(contributors, activationContext);
    contributors = processWithProfiles(contributors, importer, activationContext);
    // 这一步将配置文件应用进环境
    applyToEnvironment(contributors, activationContext, importer.getLoadedLocations(),
                       importer.getOptionalLocations());
}

ConfigDataEnvironment.java

private ConfigDataEnvironmentContributors processInitial(ConfigDataEnvironmentContributors contributors, ConfigDataImporter importer) {
    // ..
    // 调用处理器的方法
    contributors = contributors.withProcessedImports(importer, null);
    // ..
    return contributors;
}

从 processAndApply 方法可以看出，SpringBoot 的配置文件环境初始化包含三个步骤：

扫描
加载
应用

其中，扫描和加载由配置文件处理器来完成，而应用在这个方法的最后

配置文件处理器

ConfigDataEnvironmentContributors.java

ConfigDataEnvironmentContributors withProcessedImports(ConfigDataImporter importer,
                                                       ConfigDataActivationContext activationContext) {
    // 日志以及对象创建
    // ..
    while (true) {
        // 依次获取所有的 contributor
        ConfigDataEnvironmentContributor contributor = getNextToProcess(result, activationContext, importPhase);
        if (contributor == null) {
            this.logger.trace(LogMessage.format("Processed imports for of %d contributors", processed));
            return result;
        }
        // 一些对象的创建
       	// ..
        // 从 contributor 获取扫描目录
        List<ConfigDataLocation> imports = contributor.getImports();
        this.logger.trace(LogMessage.format("Processing imports %s", imports));
        // resolveAndload 就是加载配置文件
        // resolve 是扫描，需要知道这里是一个循环，不同的 contributor 内含的扫描目录是不同的，其也有各自的含义，debug 时我们只需要看配置文件的扫描即可
        // load 是加载，不同类型的配置文件有不同的加载器，后面会看到的
        Map<ConfigDataResolutionResult, ConfigData> imported = importer.resolveAndLoad(activationContext,
		// ...
    }
}

ConfigDataImporter.java

Map<ConfigDataResolutionResult, ConfigData> resolveAndLoad(ConfigDataActivationContext activationContext, ConfigDataLocationResolverContext locationResolverContext, ConfigDataLoaderContext loaderContext, List<ConfigDataLocation> locations) {
    try {
        Profiles profiles = (activationContext != null) ? activationContext.getProfiles() : null;
        // 扫描
        List<ConfigDataResolutionResult> resolved = resolve(locationResolverContext, profiles, locations);
        // 加载
        return load(loaderContext, resolved);
		}
		catch (IOException ex) {
			// ..
		}
	}

扫描

扫描——in

我们先来看扫描，扫描进行了非常多层的封装，要有耐心的一步步深入

ConfigDataImporter.java

/** 
 * 扫描代码片段1
 */
private List<ConfigDataResolutionResult> resolve(ConfigDataLocationResolverContext locationResolverContext, Profiles profiles, List<ConfigDataLocation> locations) {
    List<ConfigDataResolutionResult> resolved = new ArrayList<>(locations.size());
    for (ConfigDataLocation location : locations) {
        // 将所有扫描结果加入集合，从这里的 resolve 方法去看扫描代码片段2
        resolved.addAll(resolve(locationResolverContext, profiles, location));
    }
    return Collections.unmodifiableList(resolved);
}

ConfigDataImporter.java

/** 
 * 扫描代码片段2
 */
private List<ConfigDataResolutionResult> resolve(ConfigDataLocationResolverContext locationResolverContext, Profiles profiles, ConfigDataLocation location) {
    try {
        // 进入扫描代码片段3
        return this.resolvers.resolve(locationResolverContext, location, profiles);
    }
    catch (ConfigDataNotFoundException ex) {
        // ..
    }
}

ConfigDataImporter.java

/** 
 * 扫描代码片段3
 */
List<ConfigDataResolutionResult> resolve(ConfigDataLocationResolverContext context, ConfigDataLocation location, Profiles profiles) {
    if (location == null) {
        return Collections.emptyList();
    }
    for (ConfigDataLocationResolver<?> resolver : getResolvers()) {
        if (resolver.isResolvable(context, location)) {
            // 进入扫描代码片段4
            return resolve(resolver, context, location, profiles);
        }
    }
    throw new UnsupportedConfigDataLocationException(location);
}

ConfigDataImporter.java

/** 
 * 扫描代码片段4
 */
private List<ConfigDataResolutionResult> resolve(ConfigDataLocationResolver<?> resolver, ConfigDataLocationResolverContext context, ConfigDataLocation location, Profiles profiles) {
    // 这里的 debug 会复杂一点，因为传入了一个 Supplier 函数
    // 如下面的扫描代码片段5，内部执行了 Supplier 函数的 get 方法，也就是这里的 lambda 表达式中的 resolve 方法
    List<ConfigDataResolutionResult> resolved = resolve(location, false, () -> resolver.resolve(context, location));
    if (profiles == null) {
        return resolved;
    }
    List<ConfigDataResolutionResult> profileSpecific = resolve(location, true, () -> resolver.resolveProfileSpecific(context, location, profiles));
    return merge(resolved, profileSpecific);
}

/** 
 * 扫描代码片段5
 */
private List<ConfigDataResolutionResult> resolve(ConfigDataLocation location, boolean profileSpecific, Supplier<List<? extends ConfigDataResource>> resolveAction) {
    // 前面4个代码片段，不管是中间变量还是 return 的结果，都是 List<ConfigDataResolutionResult>
    // 而这里出现了 List<ConfigDataResource>，显而易见，这一句代码是真正执行扫描的入口
    // 上面的几段代码只是对结果集的封装与处理
    // 代码片段4中提到，这个 get 就是 resolve，所以我们进入扫描代码片段6
    List<ConfigDataResource> resources = nonNullList(resolveAction.get());
    List<ConfigDataResolutionResult> resolved = new ArrayList<>(resources.size());
    for (ConfigDataResource resource : resources) {
        resolved.add(new ConfigDataResolutionResult(location, resource, profileSpecific));
    }
    return resolved;
}