java配置文件属性更改

目录

前言

配置文件加载顺序

配置文件生效顺序

---

前言

日常我们开发过程中，由于配置文件很多，常常会导致配置混乱。

最常见的问题就是：为什么我明明配置了属性，但项目启动怎么都不生效呢？

所以搞清楚配置文件的读取和生效顺序，对日常我们开发工作非常重要。

SpringBoot版本：3.0.2

配置文件加载顺序

从官方文档可以看出，SpringBoot加载配置文件时，会从以下五个位置进行加载：

https://docs.spring.io/spring-boot/docs/3.0.2/reference/pdf/spring-boot-reference.pdf

本章节就结合源码补充说明下。

我们先来看下ConfigDataImporter.resolveAndLoad()方法。

Map<ConfigDataResolutionResult, ConfigData> resolveAndLoad(ConfigDataActivationContext activationContext, ConfigDataLocationResolverContext locationResolverContext, ConfigDataLoaderContext loaderContext, List<ConfigDataLocation> locations) {
        try {
            Profiles profiles = activationContext != null ? activationContext.getProfiles() : null;
            List<ConfigDataResolutionResult> resolved = this.resolve(locationResolverContext, profiles, locations);
            return this.load(loaderContext, resolved);
        } catch (IOException var7) {
            throw new IllegalStateException("IO error on loading imports from " + locations, var7);
        }
    }

进入resolveAndLoad()方法的入参locations，表示从哪个位置进行加载：

第一进入的需要加载位置是：

file:./;optional:file:./config/;optional:file:./config/*/

接着在该目录locations下开始解析配置文件和加载配置文件。

涉及到两个方法：resolve() 和 load()，而load()中for循环则决定了配置文件的加载顺序（candidates顺序的反向加载），candidates的入参是resolve()方法返回的。

private Map<ConfigDataResolutionResult, ConfigData> load(ConfigDataLoaderContext loaderContext,
      List<ConfigDataResolutionResult> candidates) throws IOException {
    Map<ConfigDataResolutionResult, ConfigData> result = new LinkedHashMap<>();
    for (int i = candidates.size() - 1; i >= 0; i--) {
      ConfigDataResolutionResult candidate = candidates.get(i);
      ConfigDataLocation location = candidate.getLocation();
      ConfigDataResource resource = candidate.getResource();
      if (resource.isOptional()) {
        this.optionalLocations.add(location);
      }
      if (this.loaded.contains(resource)) {
        this.loadedLocations.add(location);
      }
      else {
        try {
          ConfigData loaded = this.loaders.load(loaderContext, resource);
          if (loaded != null) {
            this.loaded.add(resource);
            this.loadedLocations.add(location);
            result.put(candidate, loaded);
          }
        }
        catch (ConfigDataNotFoundException ex) {
          handle(ex, location, resource);
        }
      }
    }
    return Collections.unmodifiableMap(result);
  }

接下来我们一起看下resolve()方法中的candidates是如何构造的。

这里涉及到两个方法：

1、ConfigDataLocationResolvers.resolve()

其中返回值resolved，就是我们寻找的candidates，而candidates集合的顺序又取决于入参resolveAction，那么resolveAction是怎么来的？

引出我们的第二个方法StandardConfigDataLocationResolver.resolve()，resoveAction是该方法的返回值。

2、StandardConfigDataLocationResolver.resolve()

从本地debug返回的references的值，可以看到不同路径下的配置文件以及它们在list集合中的顺序，

0 = {StandardConfigDataReference@5891} "file:./application.yaml"
1 = {StandardConfigDataReference@5892} "file:./application.yml"
2 = {StandardConfigDataReference@5893} "file:./application.properties"
3 = {StandardConfigDataReference@5894} "file:./application.json"
4 = {StandardConfigDataReference@5895} "file:./application.xml"
5 = {StandardConfigDataReference@5896} "file:./config/application.yaml"
6 = {StandardConfigDataReference@5897} "file:./config/application.yml"
7 = {StandardConfigDataReference@5898} "file:./config/application.properties"
8 = {StandardConfigDataReference@5899} "file:./config/application.json"
9 = {StandardConfigDataReference@5900} "file:./config/application.xml"
10 = {StandardConfigDataReference@5901} "file:./config/*/application.yaml"
11 = {StandardConfigDataReference@5902} "file:./config/*/application.yml"
12 = {StandardConfigDataReference@5903} "file:./config/*/application.properties"
13 = {StandardConfigDataReference@5904} "file:./config/*/application.json"
14 = {StandardConfigDataReference@5905} "file:./config/*/application.xml"

这里边有个点，并不是我们看到的所有的referenecs都会进入到ConfigDataImporter.load()加载阶段，第251行会根据不同的路径判断是否存在资源，然后返回存在资源的数据，也就是最终的resolved。

第一次进入ConfigDataImporter.resolveAndLoad()，在load()方法执行完之后，开始第二次进入：

进入resolveAndLoad()方法的入参locations：

classpath:/;optional:classpath:/config/

参考之前resolveAndLoad()的逻辑分析，我们直接在StandardConfigDataLocationResolver.resolve()方法上打上断点，看下解析出来的配置文件顺序如何。

0 = {StandardConfigDataReference@6024} "classpath:/application.yaml"
1 = {StandardConfigDataReference@6025} "classpath:/application.yml"
2 = {StandardConfigDataReference@6026} "classpath:/application.properties"
3 = {StandardConfigDataReference@6027} "classpath:/application.json"
4 = {StandardConfigDataReference@6028} "classpath:/application.xml"
5 = {StandardConfigDataReference@6029} "classpath:/config/application.yaml"
6 = {StandardConfigDataReference@6030} "classpath:/config/application.yml"
7 = {StandardConfigDataReference@6031} "classpath:/config/application.properties"
8 = {StandardConfigDataReference@6032} "classpath:/config/application.json"
9 = {StandardConfigDataReference@6033} "classpath:/config/application.xml"

通过以上结合源码的分析，小伙伴们是否清楚配置文件的加载顺序了呢？

它是和references里边的顺序相反的，我们来总结下（以我们常用的配置文件举例）：

• • 2、file:./config/*/application.yml
• 3、file:./config/application.properties
• 4、file:./config/application.yml
• 5、file:./application.properties
• 6、file:./application.yml
• 7、classpath:/config/application.properties
• 8、classpath:/config/application.yml
• 9、classpath:/application.properties
• 10、classpath:/application.yml

我发现不同的springBoot版本配置加载顺序可能还会存在不同，具体要以版本为准。

以上的内容，我们是基于application的配置文件做的讲解说明，那如果说我们的配置文件中存在以bootstrap开头的呢？bootstrap的配置文件和application的配置文件，谁先加载？

答案是：bootstrap早于application配置文件加载。为什么呢？

我们在处理application配置文件的时候，使用的是EnvironmentPostProcessorApplicationListener监听器。

而bootstrap配置文件的处理是在BootstrapConfigFileApplicationListener。

从源码中分析，bootstrap的监听处理要早于application的监听。

bootstrap的配置文件加载的过程，它的主要的处理类和方法是：

1、BootstrapConfigFileApplicationListener.load()：配置文件加载

2、BootstrapConfigFileApplicationListener.getSearchLocations()：获取加载配置文件的目录

3、BootstrapConfigFileApplicationListener.getSearchNames()：获取配置文件的名称

4、BootstrapConfigFileApplicationListener.loadForFileExtension()：拼接location+name+fileExtension 循环的获取配置文件内容。

其他内容，在此不做详细概述，感兴趣的小伙伴可自行研究。

配置文件生效顺序

什么是生效？生效是指配置文件中的属性值在初始化bean的过程中，被加载运用的过程。

有小伙伴就问了，如果有相同的属性，那是不是越早加载的配置文件优先级会高，会覆盖后加载的配置文件属性？

在网上查阅资料的时候，我也发现有文章是这样描述的。

但实际上，配置文件生效顺序和加载顺序是没有必然联系的。先加载的属性未必生效，后加载的属性也未必会覆盖先加载的属性值。

我们举个简单的demo，以classpath:config/applicaion.yml 和classpath:/applicaion.yml 为例。

1、classpath:/applicaion.yml

spring:
  application:
    name: demo1

2、classpath:config/applicaion.yml

spring:
  application:
    name: demo2

启动SpringBoot项目，我们来看下spring.application.name属性值的获取。

-->SpringApplication.prepareContext()
  -->SpringApplication.applyInitializers()
    --> ContextIdApplicationContextInitializer.initialize()
      -->ContextIdApplicationContextInitializer.getContextId()
        -->ContextIdApplicationContextInitializer.getApplicationId()

从以上源码中我们可以看到spring.applicaiton.name属性值的获取，主要在enviroment.getProperty()方法中。

进入enviroment.getProperty()方法中，其中我们enviroment中的propertyResolver的类是ConfigurationPropertySourcesPropertyResolver，继续深入。

发现ConfigurationPropertySourcesPropertyResolver.getProperty()调用的是findPropertyValue()方法，继续往下。

findPropertyValue()方法的主要逻辑是：

1、getAttached():先通过getAttached()方法从propertyResolver的propertySourceList中获取是否有name为configurationProperties的数据，有则匹配返回，然后通过attached.findConfigurationProperty(name)获取属性值。

2、如果attached为空，则调用defaultRsover类中的getPorperty获取属性值。

由于我们的spring.applicaion.name的属性值获取是第一种情况，所以我们进入attached.findConfigurationProperty(name)方法，看下具体实现逻辑。

从源码中可以看到，这是一个for循环，从getSource中解析出来的数据，依次匹配，一旦匹配到数据，直接return。

这说明获取到属性值是给getSource里边解析出来的数据的顺序有关系。

那getSource()的for循环，解析的数据到底是什么呢？那就不得不看下这个for循环编译过后的class是什么样子了。

• 1、this.getSource().iterator()方法：解析要遍历的数据集合
• 2、var2.next()方法：获取下一个要遍历的数据
  

我们先来看下this.getSource().iterator()方法。

因为我们的this.getSource()是SpringConfigurationPropertySources，所以我们在该类的iterator()方法上打上断点。

发现它最终解析的是propertySourceList集合中的数据。

到这里，小伙伴是不是就以为，那明白了，配置文件的生效顺序，按照propertySourceList里边的顺序，依次返回configurationPorpertySource，然后寻找匹配的属性字段，返回属性值。

这样描述也对，但是有些细节还还需要补充，并不是propertySourceList的元素都会比对，是过滤掉一部分的数据集合。

具体细节，我们来看var2.next()方法，看configurationPorpertySource数据是如何解析获取的。

其主要的处理逻辑在SpringConfigurationPropertySources.fetchNext()方法中。

fetchNext里边的解析顺序，是按照propertySourceList里边的顺序进行，但是并不是集合中所有的元素都会被retrun。

第一种如果candidate.getSource的类型是ConfigurableEnviroment的，会被忽略。

if (candidate.getSource() instanceof ConfigurableEnvironment configurableEnvironment) {
          push(configurableEnvironment);
          return fetchNext();
        }

第二种如果candidate 类型匹配StubPropertySource或者ConfigurationPropertySourcesPropertySource，也会被忽略。

private boolean isIgnored(PropertySource<?> candidate) {
      return (candidate instanceof StubPropertySource
          || candidate instanceof ConfigurationPropertySourcesPropertySource);
    }

然后剩下的满足条件的数据，还需要通过this.adapter.apply(candidate)方法进行匹配。

此处的cache是我们getSource()方法解析里边的属性，最终匹配成功并且返回的是cache里边的数据值。

我们继续回到findConfigurationProperty()方法中，我们获取到了configurationPorpertySource数据。

接下来，我们通过configurationPorpertySource.getConfigurationProperty(name)解析属性值。

• mapper.map(name)：是从mapper的lastMappedConfigurationPropertyName中获取mapping获取集合。
  
• getPropertySource().getProperty()：循环集合，根据mapping里获取的值，从source的propertySource的source中获取value值。

源码位置如上图所示，至此我们熟知了属性值的获取流程。

我们总结下：

1、先按照propertySourceList里边的顺序(iterator())遍历，过滤出来符合条件的PropertySource。

2、然后通过PropertySource获取到属性对应的属性值。

3、匹配到value，就直接返回。

因为我们的classpath:config/applicaion.yml在propertySourceList的顺序是在classpath:/applicaion.yml之前的。匹配到classpath:config/applicaion.yml的数据，直接返回，所以我们最终获取到的spring.application.name 为demo2。

有关影响propertySourceList中元素顺序的，其实是这几个方法：

1、MutablePropertySources.addFirst()
2、MutablePropertySources.addLast（）
3、MutablePropertySources.addBefore（）
4、MutablePropertySources.addAfter（）

我们在这几个方法上打上断点，就可以看到我们的配置文件到底是放到了propertySourceList的哪个位置。