关于后端:你绝对不知道的-SpringBoot-的外部化配置特性

作为 Java 程序员，置信大家都晓得，咱们日常的 SpringBoot 我的项目会有一个配置文件 application.properties 文件。

外面会配置很多参数，例如服务的端口等，这些都只是默认值，在不扭转配置文件外面内容的状况下，咱们能够通过在部署的时候，传递一个相应的参数来替换默认的参数。

那么问题来了，你有想过为什么能够这样吗？为什么 SpringBoot 部署时传递的启动配置会失效，而配置文件中的配置就不失效了呢？或者说这两者的优先级是什么样子的呢？

要解释下面的问题，咱们就须要晓得 SpringBoot 到底反对哪些配置模式，以及这些配置形式的优先级是什么样子的，只有搞清楚了这个，能力真正的解决配置的优先级问题。

在 SpringBoot 的官网文档中咱们能够看到这么一段形容

用了不起我高明的英语翻译一下，大略的意思就是：Spring Boot 提供了将配置文件内部化的性能，这样您就能够在不同环境下应用雷同的利用程序代码。您能够应用 properties 文件、YAML 文件、环境变量以及命令行参数来内部化配置文件。

通过 @Value 注解，属性值能够间接注入到 beans 中，通过 Environment abstraction（环境映射）能够拜访其余地位，或者应用 @ConfigurationProperties 绑定结构化对象。

既然下面提到了 SpringBoot 提供了内部化配置，那么 SpringBoot 提供了哪些配置呢？仍然是通过官网文档，咱们能够看到有如下配置列表

从上图能够看到 SpringBoot 总共内置了 17 种内部化配置办法，而且这 17 种的优先级是从上到下顺次优先的。这些形式中咱们罕用的有 4 命令行办法，9 Java 零碎环境变量，10 操作系统环境变量，以及 12 到 15 到配置文件的模式。

通过下面的程序咱们就能够解释为什么咱们通过命令行配置的参数会失效，而配置文件中的默认值就会疏忽了，从而达到了笼罩配置的目标。

下面的文档中也提到了，SpringBoot 次要是通过 PropertySource 机制来实现多样属性源的，SpringBoot 的 PropertySource 是一种机制，用于加载和解析配置属性，能够从多种起源获取这些属性，例如文件、零碎环境变量、JVM 零碎属性和命令行参数等。PropertySource 是 Spring 框架中的一个形象接口，它定义了如何读取属性源的办法。

通过 SpringBoot 的代码，咱们能够看到，org.springframework.core.env.PropertySource 是一个抽象类，实现在子类有很多，咱们下面提到的命令行 PropertySource 是 org.springframework.core.env.CommandLinePropertySource。整体的类图如下，涵盖的内容还是很多的，感兴趣的小伙伴能够好好钻研一番。

另外在 SpringBoot 中，咱们还能够应用 @PropertySource 注解来自定义指定要加载的属性文件。例如，能够在应用程序的主类上增加以下注解：

@SpringBootApplication
@PropertySource("classpath:customer.properties")
public class CustomerProperties {// ...}

这将通知 SpringBoot 在 classpath 下查找名为 customer.properties 的文件，并将其加载为属性源。而后，能够应用 @Value 注解将属性值注入到 bean 中，如下所示：

@Service
public class MyService {@Value("${my.property}")
   private String myProperty;
   // ...
}

这里的 ${my.property} 是从 customer.properties 文件中获取的属性值。如果找不到该属性，那么 SpringBoot 将应用默认值，这里因为是自定义的属性，是没有默认值的，就会报错，我的项目无奈启动。

具体实现是，SpringBoot 在启动时会主动加载和解析所有的 PropertySource，包含默认的 PropertySource 和自定义的 PropertySource。这些属性值被存储在 Spring 环境中，能够通过 Spring 的 Environment 对象拜访。当属性被注入到 bean 中时，Spring 会查找 Environment 对象并尝试解析属性的值。

总之，SpringBoot 的 PropertySource 提供了一种简略的办法来加载和解析应用程序的配置属性，这些属性能够从多个起源获取。它通过将属性值存储在 Spring 环境中，使其易于在应用程序的不同局部中应用。

为了验证下面说的命令行的参数配置要优先于配置文件，咱们创立一个 SpringBoot 我的项目，并且在 application.properties 文件中配置一个参数 name=JavaGeekTech，而在 IDEA 启动窗口中配置 name=JAVA_JIKEJUSHU，别离如下所示

在写一个简略的 HelloController 类，并且通过 @Value 注解注入 name 属性，接下来咱们就须要调试看下，SpringBoot 是如何将 name 属性赋值的。通过验证 name 会被赋值成 JAVA_JIKEJISHU 而不是 JavaGeekTech。

package com.example.demo.controller;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {@Value("${name}")
  private String name;

  @GetMapping(value = "/hello")
  public String hello() {return helloService.sayHello(name);
  }

}

接着咱们启动 debug，因为咱们是基于 SpringBoot 的，属性的赋值是在创立 bean 的时候，从 createBean，到 doCreateBean，再到 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#populateBean，因为每个 bean 都会通过很多 PostProcessor 的解决，属性赋值的 PostProcessor 是 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor#postProcessProperties

外面的 metadata.inject 会调用到 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.AutowiredFieldElement#inject，再到 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.AutowiredFieldElement#resolveFieldValue，

org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveDependency，

org.springframework.beans.factory.support.DefaultListableBeanFactory#doResolveDependency，

org.springframework.beans.factory.support.AbstractBeanFactory#resolveEmbeddedValue，

org.springframework.core.env.AbstractPropertyResolver#resolveRequiredPlaceholders，

org.springframework.core.env.PropertySourcesPropertyResolver#getPropertyAsRawString，

org.springframework.core.env.PropertySourcesPropertyResolver#getProperty(java.lang.String, java.lang.Class<T>, boolean)

整体调用链还是挺长的，不过只有跟着思路，在配合断点，还是能够看看看进去的。

在 getProperty 办法中，咱们能够看到如下的逻辑，依据 key 获取到的 value 值为 JAVA_JIKEJISHU。

持续跟踪 getProperty 办法，咱们能够看到这个办法 org.springframework.boot.context.properties.source.ConfigurationPropertySourcesPropertySource#findConfigurationProperty(org.springframework.boot.context.properties.source.ConfigurationPropertyName)，

其中的 getSource() 中就有咱们配置的两个属性源的数据，如下所示

依据代码逻辑，咱们也能够看到，在迭代的时候，如果找到了一个就间接返回了，所以失去的后果是 JAVA_JIKEJISHU。

明天了不起带大家钻研了一个 SpringBoot 的内部化配置，并且通过理论的一个 case 跟踪代码的调用链来给大家测试了一下，尽管说这个知识点咱们常常都在应用，然而没看到底层源码的时候咱们并不知道这样的一个性能底层是怎么的简单的。

这里还是要钦佩一下 SpringBoot 的开发者，同时也倡议大家，在日常的开发中咱们须要多看看底层的源码，通过一直的看源码，咱们能更好的了解个性的实现原理，从而增强咱们本身的能力。

关于后端:你绝对不知道的-SpringBoot-的外部化配置特性

内部化配置

有哪些内部配置

PropertySource

调试

总结