springboot配置注入增强（二）属性注入的原理

一 原理

对原理不感兴趣的可以直接使用框架https://blog.csdn.net/cjc000/article/details/134021209?spm=1001.2014.3001.5501 

1 配置的存储

springboot在启动的时候会后构建一个org.springframework.core.env.Environment类型的对象，这个对象就是用于存储配置，如图springboot会在启动的最开始创建一个Environment对象

这个webApplicationType的枚举是在new SpringApplication()时候指定的

• 如果org.springframework.web.reactive.DispatcherHandler存在并且可加载（他本身或其依赖项之一不存在或无法加载），并且org.springframework.web.servlet.DispatcherServlet不存在或不可加载，并且org.glassfish.jersey.servlet.ServletContainer不存在或不可加载，那么就会使用WebApplicationType.REACTIVE，构建ApplicationReactiveWebEnvironment类型的Environment对象，即Spring WebFlux框架
• 如果javax.servlet.Servlet，org.springframework.web.context.ConfigurableWebApplicationContext中任何一个不存在或不可加载，那么就会使用WebApplicationType.NONE，构建ApplicationEnvironment类型的Environment对象，即普通spring非web框架
• 否则就会使用WebApplicationType.SERVLET，构建ApplicationServletEnvironment类型的Environment对象，即Servlet也就是spring mvc框架

我们以常用的spring mvc为例，先看下ApplicationServletEnvironment类的数据结构（都大同小异）

本质是一个PropertyResolver接口，核心是能提供一个根据配置中某个属性的key获取对应属性值的方法和跟据某个规则解析属性值的方法，他所有的子类都是在对其做一些扩张，让其使用更方便，比如ConfigurableEnvironment增加的MutablePropertySources getPropertySources()方法，就是为了能获取到全部的配置内容

其实springboot的这三种Environment都是StandardEnvironment的子类，而StandardEnvironment的父类AbstractEnvironment使用了MutablePropertySources作为数据源集合的类型，当然它也是根据其实现接口ConfigurableEnvironment中的MutablePropertySources getPropertySources()方法来确定数据源集合的类型。

可以看出来这个类对比原始的PropertyResolver接口多一个数据源集合，springboot的配置原理简单来说就是将不同来源的配置组装成不同数据源类型的数据源对象，然后放到MutablePropertySources中根据名称和数据源对象进行key-value存储，使用的时候遍历MutablePropertySources中所有的数据源的value，从中找到第一个符合条件的值，找到之后再进行解析，比如${xxxx}这种。这个使用的逻辑即PropertyResolver接口的全部实现是由PropertySourcesPropertyResolver对象代理的（在AbstractEnvironment的构造方法中会new一个PropertySourcesPropertyResolver对象）

MutablePropertySources中有一个List> propertySourceList成员变量，这个就是上面说的数据源集合

PropertySource就是具体的配置了，其实也就两个变量，name：数据源名称，source：具体的数据源。这个实现类有很多，我们也可以自己定义，比如自己创建一个类用做source，然后实现PropertySource那几个根据source查询值的方法

2 配置的来源

其实这个配置的来源可以任何时候添加到Environment对象中，只不过如果想让springboot在启动过程中加载bean时使用到我们的数据源，我们应该在PropertySourcesPlaceholderConfigurer的postProcessBeanFactory()方法执行前加进Environment中，低版本的springboot用的是PropertyPlaceholderConfigurer，不过这个早就已经弃用了所以也就不用管他了，下面我们介绍下PropertySourcesPlaceholderConfigurer

可以看到他是一个BeanFactoryPostProcessor实现类，这个类会在启动的refresh阶段执行postProcessBeanFactory()方法

可以看到，这里会新建一个数据源集合，并且把environment和localProperties加进去，这个localProperties就是我们手动构建PropertySourcesPlaceholderConfigurer时指定的配置文件路径

  @Bean
  public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() {
    PropertySourcesPlaceholderConfigurer configurer = new PropertySourcesPlaceholderConfigurer();
    configurer.setLocation(new ClassPathResource("config.properties"));
    return configurer;
  }

之后会将这个数据源集合封装为一个StringValueResolver用于解析属性

可以看到这个先被用于解析bean的属性如这种的${xx}，其实我感觉这个也是为了兼容老代码，毕竟最早的spring也只有在配置文件里注入的这种方式

<bean id="cacheService" class="my.user.UserImpl">
        <property name="name" value="${user.123.name}"/>
    </bean>

然后可以看到执行了beanFactoryToProcess.addEmbeddedValueResolver(valueResolver)方法，这个方法只是将这个valueResolver解析器存了起来，现在还没用。

会等到解析@value时候在AutowiredAnnotationBeanPostProcessor用到，下面介绍几个系统配置的常用的数据源        

2.1 系统的环境变量和java启动时的启动参数

StandardEnvironment在初始化时会由父类执行StandardEnvironment的customizePropertySources方法创建两个数据源放到数据源集合，这两个数据源我们也很熟悉，就是系统的环境变量和java启动时的启动参数即System.getenv()和System.getProperties()

2.2 application.yml

旧版本是由ConfigFileApplicationListener作为启动监听器，在监听到ApplicationEnvironmentPreparedEvent事件也就是创建完Environment后会发的一个事件中加载的

可以看到他也实现了EnvironmentPostProcessor接口，并把自身和其他spring.factories文件中配置的org.springframework.boot.env.EnvironmentPostProcessor=xxxx，合并一起执行对应的postProcessEnvironment()方法，而他本身的postProcessEnvironment方法会加载application.yml文件

新版本是用ConfigDataEnvironmentPostProcessor加载的，同时ConfigFileApplicationListener被废弃了，改为由EnvironmentPostProcessorApplicationListener来执行EnvironmentPostProcessor的方法，职责单一更清晰了些

2.3 PropertySources/PropertySource

PropertySources其实就是PropertySource的集合，是由ConfigurationClassPostProcessor将PropertySource路径的配置文件内容添加到environment中

可以看到这个路径甚至还支持${xxx}这种动态路径（environment.resolveRequiredPlaceholders会将${xxx}从environment对象中获取真正的值），然后将多个location解析后的propertySource组合起来形成一个CompositePropertySource对象

3 配置的使用

3.1 BeanDefinition 的属性注入

上面介绍过，通常就是对BeanDefinition的propertyValues进行解析，在PropertySourcesPlaceholderConfigurer里

<bean id="cacheService" class="my.user.UserImpl">
        <property name="name" value="${user.123.name}"/>
    </bean>

3.2 @Value

上面也介绍过在AutowiredAnnotationBeanPostProcessor会进行解析

    @Value("${user.123.name}")
    private String user123Name;

3.3 @ConfigurationProperties

@Data
@Component
@ConfigurationProperties(prefix = "user.123")
public class UserConfiguration {
    /**
     * 姓名
     */
    private String name;
 
    /**
     * 性别
     */
    private String sex;
}

他是由ConfigurationPropertiesBindingPostProcessor的postProcessBeforeInitialization(Object bean, String beanName)来进行绑定的

可以看到实际上执行的是Binder的bind()方法，这个方法可以将以某个相同前缀的属性绑定到对应对象的属性上，主要关注Binder构造器的前两个参数Iterable sources, PlaceholdersResolver placeholdersResolver，可以看到都是用propertySources作为数据源来进行查找和解析的，而这个propertySources是ConfigurationPropertiesBinder.register(registry)方法中调用ConfigurationPropertiesBinder.Factory#create()方法中生成的

可以看到如果只有一个PropertySourcesPlaceholderConfigurer类型的bean时，这个数据源就是我们上面说的那个和3.1和3.2所用的一样的数据源PropertySourcesPlaceholderConfigurer的appliedPropertySources。否则就会用Environment作为数据源

3.4 environment

这个就简单了，直接从environment对象取即可

• environment.getProperty("user.123.name")
• environment.resolvePlaceholders("${user.123.name}")
• environment.resolveRequiredPlaceholders("${user.123.name}") 如果解析不到会报错