作为 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 到配置文件的形式。
通过上面的顺序我们就可以解释为什么我们通过命令行配置的参数会生效,而配置文件中的默认值就会忽略了,从而达到了覆盖配置的目的。
PropertySource
上面的文档中也提到了,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
整体调用链还是挺长的,不过只要跟着思路,在配合断点,还是可以看看看出来的。
在 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
的开发者,同时也建议大家,在日常的开发中我们需要多看看底层的源码,通过不断的看源码,我们能更好的理解特性的实现原理,从而加强我们自身的能力。
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net