前言
最近使用容器部署应用，Spring应用，会注入一些环境变量，然而这些环境变量的大小写和真实的取值差异很大，而且也不是xxx.xxx，而是xxx_xxx，非常奇怪，代码里也没发现原因。通过分析Spring源码发现，原理就是Spring的特殊处理，以及Spring的设计。
1.注入系统环境变量
随意写一个demo
import org.junit.jupiter.api.Test;
import org.springframework.core.env.SystemEnvironmentPropertySource;
import java.util.HashMap;
import java.util.Map;
public class EnvPropertiesTest {
@Test
public void getProperties(){
Map<String, Object> map = new HashMap<>();
map.put("SPRING_DEF_DEMO", "hi, I`m a demo");
map.put("SPRING-DEF-DEMO", "hi, I`m a demo2222");
map.put("spring.def.demo", "hi, I`m a demo2222333");
SystemEnvironmentPropertySource propertySource = new SystemEnvironmentPropertySource("sysEnv", map);
System.out.println(propertySource.getProperty("spring.def.demo"));
}
}运行后可以得出
?
?跟我们想的一致，那么现在实现特殊操作，把
map.put("spring.def.demo", "hi, I`m a demo2222333");
注释掉
?懵了，为啥获取spring.def.demo，却拿到了SPRING_DEF_DEMO
另外通过SPRING-DEF-DEMO也可以读取到?SPRING_DEF_DEMO的值。这就是容器注入大写下划线，而通过常规方式读取到的现象，实际上大写加下划线可以认为常量定义。
2.源码分析原理
原理实际上可以看到是Spring自己处理了。那么Spring是怎么处理的呢，Spring读取环境变量实际上和系统变量是有区别的。
org.springframework.core.env.StandardEnvironment
定义在Spring-core包中
protected void customizePropertySources(MutablePropertySources propertySources) {
propertySources.addLast(
new PropertiesPropertySource(SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME, getSystemProperties()));
propertySources.addLast(
new SystemEnvironmentPropertySource(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME, getSystemEnvironment()));
}上面的是系统变量，下面是环境变量
System.getenv()
System.getProperties()
上面的demo，之所以使用
SystemEnvironmentPropertySource
就是这里Spring定义决定的，关键在于getProperty方法
public Object getProperty(String name) {
String actualName = resolvePropertyName(name);
if (logger.isDebugEnabled() && !name.equals(actualName)) {
logger.debug("PropertySource '" + getName() + "' does not contain property '" + name +
"', but found equivalent '" + actualName + "'");
}
return super.getProperty(actualName);
}核心在于
String actualName = resolvePropertyName(name);
真实名称，这就是Spring的环境变量的设计?
protected final String resolvePropertyName(String name) {
Assert.notNull(name, "Property name must not be null");
// 拿到替换了. -为_的name读取，前提是name不能直接取到值数据
String resolvedName = checkPropertyName(name);
if (resolvedName != null) {
return resolvedName;
}
//大写处理，注入大写之所以可以读取，根源就是这里
String uppercasedName = name.toUpperCase();
if (!name.equals(uppercasedName)) { //严谨处理，毕竟eq就没必要进一步处理了
resolvedName = checkPropertyName(uppercasedName); //大写进一步看是否有大写属性值
if (resolvedName != null) {
return resolvedName;
}
}
return name;
}继续
private String checkPropertyName(String name) {
// Check name as-is 如果能直接取到属性，就不转义
if (containsKey(name)) {
return name;
}
// Check name with just dots replaced
// 替换.为_
String noDotName = name.replace('.', '_');
if (!name.equals(noDotName) && containsKey(noDotName)) {
return noDotName;
}
// Check name with just hyphens replaced
// 同理替换中划线
String noHyphenName = name.replace('-', '_');
if (!name.equals(noHyphenName) && containsKey(noHyphenName)) {
return noHyphenName;
}
// Check name with dots and hyphens replaced
// 替换.后替换中划线，即2种同时存在
String noDotNoHyphenName = noDotName.replace('-', '_');
if (!noDotName.equals(noDotNoHyphenName) && containsKey(noDotNoHyphenName)) {
return noDotNoHyphenName;
}
// Give up 牛逼注释
return null;
}
private boolean containsKey(String name) {
return (isSecurityManagerPresent() ? this.source.keySet().contains(name) : this.source.containsKey(name));
}至此，就知道了容器或者虚拟机注入环境变量，但是spring读取却可以使用常规xxx.xxx小写读取到的原理，Spring充当了转义器的角色。
?
总结
因为框架有定制，笔者一开始并不知道为啥能读取成功，而实际上却神奇的读取到环境变量了，翻遍定制代码都没发现哪里处理的，开始怀疑Spring干的，而Spring读取环境变量的代码就是org.springframework.core.env.SystemEnvironmentPropertySource，刚好就找到处理的代码了，明白原理。