Spring Boot 外部化配置（一）- Environment、ConfigFileApplicationListener

目录

• 前言
• 1、起源
• 2、外部化配置的资源类型
• 3、外部化配置的核心
  • 3.1 Environment
    • 3.1.1、ConfigFileApplicationListener
    • 3.1.2、关联 SpringConfigurationPropertySources

前言

        最近在学习Spring Boot相关的课程，过程中以笔记的形式记录下来，方便以后回忆，同时也在这里和大家探讨探讨，文章中有漏的或者有补充的、错误的都希望大家能够及时提出来，本人在此先谢谢了！

开始之前呢，希望大家带着几个问题去学习：

1、Spring Boot 外部化配置是什么？

2、整体流程或结构是怎样的？

3、核心部分是什么？

4、怎么实现的？

这是对自我的提问，我认为带着问题去学习，是一种更好的学习方式，有利于加深理解。好了，接下来进入主题。

1、起源

        这篇文章我们就来讨论 Spring Boot 的外部化配置功能，该功能主要是通过外部的配置资源实现与代码的相互配合，来避免硬编码，提供应用数据或行为变化的灵活性。相信小伙伴们在日常工作中都有使用过，如在 properties 或者 YAML 文件中定义好key value格式的数据后，就可在程序中通过 @Value 注解获取该value值。还可以定义一些同外部组件约定好的key，如以 spring 或 redis 等组件名为前缀的key，之后相应的组件就可读取到该value值进行工作。当然，这只是外部化配置的一小部分内容，接下来进行详细讨论。

注：本篇文章所用到的 Spring Boot版本是 2.1.6.BUILD-SNAPSHOT

2、外部化配置的资源类型

        先来看看外部化配置的几种资源类型，除了 properties 和 YAML 外，还有环境变量、系统属性、启动参数等。所有的资源类型将近二十种，这里只介绍我们比较熟悉的：

1. properties ：这个应该都知道，就是在以 .properties 为后缀的文件中定义key value格式数据。
2. YAML：文件格式是以 .yml 为后缀，文件中的数据也是key value格式，如下：

user:
  name: loong
  age: 10

这里的key就是 user.name 、 user.age 。

3. 环境变量：这是通过 System.getenv() 方式获取的默认配置，也是key value格式，下面列出部分配置，其它的还请自行了解，如下：

名称	Key
Java安装目录	JAVA_HOME
classpath环境变量	CLASSPATH
用户临时文件目录	TEMP
计算机名	COMPUTERNAME
用户名	USERNAME

1. 系统属性：这是通过 System.getProperties() 方式获取的默认配置，也是key value格式，下面列出部分配置，其它的还请自行了解，如下：

名称	Key
运行时环境版本	java.version Java
Java安装目录	java.home
要使用的 JIT编译器的名称	java.compiler
操作系统的架构	os.arch
操作系统的版本	os.version

1. 启动参数：这个在 《Spring Boot SpringApplication 启动类（二）》这篇文章中讨论过。一种是在 jar 包运行时行时传递的参数，如：java -jar xxx.jar name=张三 pwa=123 ，还有一种是在 IDEA 的 Program arguments 中输入数据：

可以看到，外部化配置中的数据都是key value 格式。这里还要注意它们的加载顺序，当key相同时，会出现覆盖的情况。

3、外部化配置的核心

        接下来，我们的重心来围绕 properties 和 YAML 配置文件，这两者也是我们日常工作中常用的。首先来看取值方式，在 Spring 时代有 Environment 、 @Value 、 XML 三种方式，在 Spring Boot 时代则是 @ConfigurationProperties 方式。其中，涉及到了一个核心类，它就是 Environment ，该对象不仅可以获取所有的外部化配置数据，就连另外几种取值方式的数据来源也是从该类中获取。这里，主要对 Environment 和 @ConfigurationProperties 进行详细讨论，笔者认为 Environment 和 @ConfigurationProperties 才是 Spring Boot 外部化配置的核心所在。

3.1 Environment

该类在 《Spring Boot SpringApplication启动类（二）》 的 2.3 章节有简要说明过，这里我们展开详细讨论。首先回顾一下代码：

public class SpringApplication {

    ...

    public ConfigurableApplicationContext run(String... args) {
		...

		try {
			...

			ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);

		...

	}
	...
}

在 SpringApplication 运行阶段的 run 方法中通过 prepareEnvironment 方法了创建 ConfigurableEnvironment 的实现类对象，ConfigurableEnvironment 是一个接口，且继承了 Environment 。进入创建方法：

private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners,
			ApplicationArguments applicationArguments) {
	ConfigurableEnvironment environment = getOrCreateEnvironment();
	configureEnvironment(environment, applicationArguments.getSourceArgs());
	listeners.environmentPrepared(environment);
	bindToSpringApplication(environment);
	if (!this.isCustomEnvironment) {
		environment = new EnvironmentConverter(getClassLoader()).convertEnvironmentIfNecessary(environment,
				deduceEnvironmentClass());
	}
	ConfigurationPropertySources.attach(environment);
	return environment;
}

首先看第一行，通过 getOrCreateEnvironment 方法创建 ConfigurableEnvironment 对象：

private ConfigurableEnvironment getOrCreateEnvironment() {
	if (this.environment != null) {
		return this.environment;
	}
	switch (this.webApplicationType) {
	case SERVLET:
		return new StandardServletEnvironment();
	case REACTIVE:
		return new StandardReactiveWebEnvironment();
	default:
		return new StandardEnvironment();
	}
}

在 《Spring Boot SpringApplication 启动类（二）》 的 2.3 章节说过， webApplicationType 存储的是应用的类型，有 Reactive、Servlet 等，是在 SpringApplication 准备阶段推导出来的，而本项目推导出来是 Servlet 类型，所以实例化的是 StandardServletEnvironment 对象：

public class StandardServletEnvironment extends StandardEnvironment implements ConfigurableWebEnvironment {

	public static final String SERVLET_CONTEXT_PROPERTY_SOURCE_NAME = "servletContextInitParams";

	public static final String SERVLET_CONFIG_PROPERTY_SOURCE_NAME = "servletConfigInitParams";

	public static final String JNDI_PROPERTY_SOURCE_NAME = "jndiProperties";

	@Override
	protected void customizePropertySources(MutablePropertySources propertySources) {
		propertySources.addLast(new StubPropertySource(SERVLET_CONFIG_PROPERTY_SOURCE_NAME));
		propertySources.addLast(new StubPropertySource(SERVLET_CONTEXT_PROPERTY_SOURCE_NAME));
		if (JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable()) {
			propertySources.addLast(new JndiPropertySource(JNDI_PROPERTY_SOURCE_NAME));
		}
		super.customizePropertySources(propertySources);
	}

	...

}

而该类又继承了 StandardEnvironment 类。且重写了 customizePropertySources 方法，并调用了父类的 customizePropertySources 方法。我们继续往下深入：

public class StandardEnvironment extends AbstractEnvironment {

	public static final String SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME = "systemEnvironment";

	public static final String SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME = "systemProperties";

	@Override
	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()));
	}

}

继续看它的 AbstractEnvironment 父抽象类：

public abstract class AbstractEnvironment implements ConfigurableEnvironment {

    ...

    private final MutablePropertySources propertySources = new MutablePropertySources();

    ...

    public AbstractEnvironment() {
		customizePropertySources(this.propertySources);
	}
	...
}

可以看到，最终会有一个 AbstractEnvironment 抽象类。在 StandardServletEnvironment 初始化时，会调用 AbstractEnvironment 的构造方法，里面调用了子类重写的 customizePropertySources 方法，且入参是 MutablePropertySources 对象，该对象是 Environment 的一个属性，是底层真正存储外部化配置的。之后， StandardServletEnvironment 和 StandardEnvironment 的 customizePropertySources 方法相继执行，主要是往 MutablePropertySources 对象中添加外部化配置。其中我们前面所说的环境变量和系统属性是在 StandardEnvironment 重写的方法中进行加载。

我们回到外面的 prepareEnvironment 方法，继续往下走。接着执行的是 configureEnvironment 方法，该方法主要是把启动参数加入到 MutablePropertySources 中。之后，我们断点看看有多少种外部化配置：

有五种，且真正存储数据的是 MutablePropertySources 中的 PropertySource 实现类集合。

这里简要介绍一下 PropertySource ，我们将其称之为配置源，官方定义它是外部化配置的API描述方式，是外部化配置的一个媒介。 用我们的话来说，它是一个抽象类，提供了统一存储外部化配置数据的功能，而每种外部化配置有具体的实现类，主要提供不同的基础操作，如 get、contains 等 。我们来看看 PropertySource 对象的数据格式，一般包含:

name : 外部化配置的名称

source : 存储配置中的数据，底层一般数据格式都是key value

我们继续往下走，接着调用了 SpringApplicationRunListeners 的 environmentPrepared 方法。在上篇文章

《Spring Boot SpringApplication 启动类（二）》 的 2.1 小节讲过，当 Spring Boot 执行到某一阶段时，会通过 Spring 的 SimpleApplicationEventMulticaster 事件广播器进行事件广播，之后 ，相应监听器就会监听到该事件，执行调监听器的 onApplicationEvent 方法。这里表示 Spring Boot 到了 ConfigurableEnvironment 构建完成时阶段。我们进入该方法：

class SpringApplicationRunListeners {

    ...

    private final List<SpringApplicationRunListener> listeners;

    public void environmentPrepared(ConfigurableEnvironment environment) {
		for (SpringApplicationRunListener listener : this.listeners) {
			listener.environmentPrepared(environment);
		}
	}
	...
}

真正调用的是 SpringApplicationRunListener 集合中的 environmentPrepared 方法。 SpringApplicationRunListener 是一个接口，它具有唯一实现类 EventPublishingRunListener ：

public class EventPublishingRunListener implements SpringApplicationRunListener, Ordered {

    ...

    private final SimpleApplicationEventMulticaster initialMulticaster;

    @Override
	public void environmentPrepared(ConfigurableEnvironment environment) {
		this.initialMulticaster
				.multicastEvent(new ApplicationEnvironmentPreparedEvent(this.application, this.args, environment));
	}
	...
}

可以看到，最终通过 SimpleApplicationEventMulticaster 的 multicastEvent 方法发布 ApplicationEnvironmentPreparedEvent 事件。上面说过， Spring Boot 监听器会监听到该事件，其中一个名为 ConfigFileApplicationListener 的监听器，监听到该事件后会进行加载 application 和 YAML 配置文件的操作，接下来，我们具体的来看一看该类实现。

3.1.1、ConfigFileApplicationListener

        我们直接进入该类：

public class ConfigFileApplicationListener implements EnvironmentPostProcessor, SmartApplicationListener, Ordered {

    ...

    private static final String DEFAULT_SEARCH_LOCATIONS = "classpath:/,classpath:/config/,file:./,file:./config/";

    public static final String CONFIG_NAME_PROPERTY = "spring.config.name";

	public static final String CONFIG_LOCATION_PROPERTY = "spring.config.location";

    public static final String CONFIG_ADDITIONAL_LOCATION_PROPERTY = "spring.config.additional-location";

    private static final String DEFAULT_NAMES = "application";

    @Override
	public void onApplicationEvent(ApplicationEvent event) {
	    // 1、通过 instanceof 判断事件的类型，如果是 ApplicationEnvironmentPreparedEvent 事件，则执行 onApplicationEnvironmentPreparedEvent 方法
		if (event instanceof ApplicationEnvironmentPreparedEvent) {
			onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent) event);
		}
		...
	}

	private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
		// 2、调用 loadPostProcessors 方法，返回 Environment 的后置处理器集合，我们跳到 2.1 查看方法实现
		List<EnvironmentPostProcessor> postProcessors = loadPostProcessors();

		// 2.2、把自己也加入该集合
		postProcessors.add(this);
		AnnotationAwareOrderComparator.sort(postProcessors);

		// 2.3、遍历 EnvironmentPostProcessor 集合，执行它们的 postProcessEnvironment 方法，我们跳到 3 查看当前类的该方法实现
		for (EnvironmentPostProcessor postProcessor : postProcessors) {
			postProcessor.postProcessEnvironment(event.getEnvironment(), event.getSpringApplication());
		}
	}

	// 2.1 是我们比较熟悉的 loadFactories 方法，在 Spring Boot 自动装配（二） 的 2.1.2 小节讲过，loadFactories 方法是从 spring.factories 文件中加载 key 为 EnvironmentPostProcessor 的实现类集合
	List<EnvironmentPostProcessor> loadPostProcessors() {
		return SpringFactoriesLoader.loadFactories(EnvironmentPostProcessor.class, getClass().getClassLoader());
	}

	// 3、 执行到该方法时，会调用 addPropertySources 方法，入参是上文加载 ConfigurableEnvironment 对象
	@Override
	public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
		addPropertySources(environment, application.getResourceLoader());
	}

	protected void addPropertySources(ConfigurableEnvironment environment, ResourceLoader resourceLoader) {
		RandomValuePropertySource.addToEnvironment(environment);

		// 4、 我们主要关注这里，通过 Loader 的构造方法创建该对象，并调用它的 load 方法
		new Loader(environment, resourceLoader).load();
	}

	private class Loader {

	    private final ConfigurableEnvironment environment;

	    private final List<PropertySourceLoader> propertySourceLoaders;

	    // 4.1、 构造方法中会初始化一些属性
	    Loader(ConfigurableEnvironment environment, ResourceLoader resourceLoader) {
			...
			this.environment = environment;

			// 又是我们比较熟悉的 loadFactories 方法，在 Spring Boot 自动装配（二） 的 2.1.2 小节讲过，loadFactories 方法是从 spring.factories 文件中加载 key 为 PropertySourceLoader 的实现类集合。这里加载的是 PropertiesPropertySourceLoader 和 YamlPropertySourceLoader 两个实现类，看类名可初步断定是处理 properties 和 YAML 文件的
			this.propertySourceLoaders = SpringFactoriesLoader.loadFactories(PropertySourceLoader.class,getClass().getClassLoader());
		}

		public void load() {
			...
			// 5、这里会继续调用它重载的 load 方法
			load(null, this::getNegativeProfileFilter, addToLoaded(MutablePropertySources::addFirst, true));
			...

			// 9、这是最后一步，将当前类中的 MutablePropertySources 中的 PropertySource 对象，全部塞到 ConfigurableEnvironment 的 MutablePropertySources 对象中。我们跳到 9.1 进行查看
			addLoadedPropertySources();
		}

		private void load(Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) {

			// 5.1、首先执行 getSearchLocations 方法，看方法名大致能猜出是获取搜索路径的，我们跳到 5.1.1 查看该方法的实现
			getSearchLocations().forEach((location) -> {

			    // 5.2、开始遍历该集合，先判断该路径是否是以反斜杠结尾，是的话则该路径为文件夹；不是的话，则该路径为文件的完整路径，类似于 classPath:/application.properties
				boolean isFolder = location.endsWith("/");

				// 5.3、 如果是文件夹路径，则通过 getSearchNames 获取文件的名称，不是则返回空集合，我们跳到 5.3.1 查看 getSearchNames 方法
				Set<String> names = isFolder ? getSearchNames() : NO_SEARCH_NAMES;

				// 5.4、再调用 load 的重载方法，这里，location 是路径名，name是文件名，我们跳到 6 进行查看
				names.forEach((name) -> load(location, name, profile, filterFactory, consumer));
			});
		}

		// 5.1.1、这个方法就是获取加载 application 和 YAML 文件路径的
		private Set<String> getSearchLocations() {

		    //  可以看到 CONFIG_LOCATION_PROPERTY 的值为 spring.config.location，也就是说，先判断我们有没有手动设置搜索路径，有的话直接返回该路径。该值一般通过启动参数的方式设置
			if (this.environment.containsProperty(CONFIG_LOCATION_PROPERTY)) {
				return getSearchLocations(CONFIG_LOCATION_PROPERTY);
			}

			// 该 CONFIG_ADDITIONAL_LOCATION_PROPERTY 变量的值为 spring.config.additional-location，这也是用于手动设置搜索路径，不过和上面不同的是，不会覆盖 接下来默认的搜索路径
			Set<String> locations = getSearchLocations(CONFIG_ADDITIONAL_LOCATION_PROPERTY);

			// 这里就是获取默认的搜索路径，通过 DEFAULT_SEARCH_LOCATIONS 变量的值 classpath:/,classpath:/config/,file:./,file:./config/，将该值用逗号分隔，加入集合并返回。到这一步，我们至少获取到了4个加载 application 和 YAML 文件的路径
			locations.addAll(asResolvedSet(ConfigFileApplicationListener.this.searchLocations, DEFAULT_SEARCH_LOCATIONS));
			return locations;
		}

		// 5.3.1
		private Set<String> getSearchNames() {

		    // CONFIG_LOCATION_PROPERTY 变量值为 spring.config.name ，同样先判断有没有手动设置文件名称，有的话，直接返回
			if (this.environment.containsProperty(CONFIG_NAME_PROPERTY)) {
				String property = this.environment.getProperty(CONFIG_NAME_PROPERTY);
				return asResolvedSet(property, null);
			}

			// 如果没有，则通过 DEFAULT_NAMES 变量值返回默认的文件名，变量值为 application
			return asResolvedSet(ConfigFileApplicationListener.this.names, DEFAULT_NAMES);
		}

		// 6、
		private void load(String location, String name, Profile profile, DocumentFilterFactory filterFactory,
				DocumentConsumer consumer) {

			// 6.1、 上面 5.2 说过 name 为空时，表示 location 是完整的文件路径。之后进入这个 if
			if (!StringUtils.hasText(name)) {

			    // 6.1.1、propertySourceLoaders 属性是在 4.1 处被初始化的，存储的是 PropertiesPropertySourceLoader 和 YamlPropertySourceLoader 两个类。这里对这两个类进行遍历
				for (PropertySourceLoader loader : this.propertySourceLoaders) {

				    // 我们跳到 6.1.2 查看 canLoadFileExtension 方法实现，入参 location 是文件的完整路径
					if (canLoadFileExtension(loader, location)) {

						// 这里又是一个 load 重载方法，我们跳到 7 进行查看
						load(loader, location, profile, filterFactory.getDocumentFilter(profile), consumer);
						return;
					}
				}
			}
			Set<String> processed = new HashSet<>();
			for (PropertySourceLoader loader : this.propertySourceLoaders) {

			    // 6.2 这里和 6.1.3 类似，获取文件扩展名
				for (String fileExtension : loader.getFileExtensions()) {
					if (processed.add(fileExtension)) {

						// 进入 6.3、查看该方法实现。关注重点的两个参数：一个是路径名 + 文件名，还有一个 “.” +文件扩展名
						loadForFileExtension(loader, location + name, "." + fileExtension, profile, filterFactory,
								consumer);
					}
				}
			}
		}

		// 6.1.2、 该方法作用是 判断 name 完整路径名是否以指定的文件扩展名结尾
		private boolean canLoadFileExtension(PropertySourceLoader loader, String name) {

		    // 6.1.3、调用 PropertySourceLoader 的 getFileExtensions 方法。当你的实现类是 PropertiesPropertySourceLoader 时，该方法返回 properties、xml；如果是 YamlPropertySourceLoader 则返回 yml、yaml。从这里可以看出，能被处理的文件格式有这四种
			return Arrays.stream(loader.getFileExtensions())
					.anyMatch((fileExtension) -> StringUtils.endsWithIgnoreCase(name, fileExtension));
		}

		// 6.3 到了这里，prefix 和 fileExtension 都是进行拼接好的值，如 prefix = classpath:/applicarion，fileExtension = .properties
		private void loadForFileExtension(PropertySourceLoader loader, String prefix, String fileExtension,
				Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) {

			...

			// 这里同样调用节点 7 的重载方法，通过 prefix + fileExtension 形成完整的文件路径名，通过入参进行传递。如 classpath:/applicarion.properties
			load(loader, prefix + fileExtension, profile, profileFilter, consumer);
		}

		// 7、
		private void load(PropertySourceLoader loader, String location, Profile profile, DocumentFilter filter,
				DocumentConsumer consumer) {
			try {

			    // 这里调用 ResourceLoader 的 getResource 方法，通过 location 文件路径，读取获取该文件资源，之后就好办了
				Resource resource = this.resourceLoader.getResource(location);

				...

				// 具体解析在过程 loadDocuments 中，这里就不继续跟踪了，大致是以流的方式解析文件。解析之后会生成一个 PropertySource 对象，该对象在上面说过，表示一个外部化配置源对象，存储配置中的数据。之后，会将该对象封装到 Document 中
				List<Document> documents = loadDocuments(loader, name, resource);

				...

				if (!loaded.isEmpty()) {

				    // 遍历 documents 集合，当执行 consumer.accept 时会进入 addToLoaded 方法，这是 Java8 的写法。consumer 对象参数来自节点 5 。我们跳到 8 查看 addToLoaded 实现
					loaded.forEach((document) -> consumer.accept(profile, document));
					if (this.logger.isDebugEnabled()) {
						StringBuilder description = getDescription("Loaded config file ", location, resource, profile);
						this.logger.debug(description);
					}
				}
			}
			catch (Exception ex) {
				throw new IllegalStateException("Failed to load property " + "source from location '" + location + "'",
						ex);
			}
		}

		// 8、BiConsumer 是 JAVA8 的函数接口，表示定义一个带有两个参数且不返回结果的操作，通过节点 5 我们知道，这个操作是 MutablePropertySources::addFirst 。
		private DocumentConsumer addToLoaded(BiConsumer<MutablePropertySources, PropertySource<?>> addMethod,
				boolean checkForExisting) {
			return (profile, document) -> {
				if (checkForExisting) {
					for (MutablePropertySources merged : this.loaded.values()) {
						if (merged.contains(document.getPropertySource().getName())) {
							return;
						}
					}
				}
				MutablePropertySources merged = this.loaded.computeIfAbsent(profile,
						(k) -> new MutablePropertySources());

				// 当调用 BiConsumer 的 accept 方法时，定义的操作会执行，两个入参分别是 MutablePropertySources 对象和配置文件源对象 PropertySource。该操作会调用 MutablePropertySources 的 addFirst 方法把该配置文件源对象添加至其中。最后我们去看看前面 load 方法中的最后一步 9
				addMethod.accept(merged, document.getPropertySource());
			};
		}

		// 9.1
		private void addLoadedPropertySources() {

		    // 获取当前上下文环境中的 MutablePropertySources 对象
			MutablePropertySources destination = this.environment.getPropertySources();

			// 获取当前类中的 MutablePropertySources 集合
			List<MutablePropertySources> loaded = new ArrayList<>(this.loaded.values());
			Collections.reverse(loaded);
			String lastAdded = null;
			Set<String> added = new HashSet<>();

			// 遍历 loaded 集合及其中所有的 PropertySource ，也就是 application 或 YAML 配置文件源对象
			for (MutablePropertySources sources : loaded) {
				for (PropertySource<?> source : sources) {
					if (added.add(source.getName())) {

					    // 我们进入 9.2 查看该方法，主要参数是上下文环境中的 MutablePropertySources 对象和配置文件源对象
						addLoadedPropertySource(destination, lastAdded, source);
						lastAdded = source.getName();
					}
				}
			}
		}

        // 9.2
		private void addLoadedPropertySource(Mutab lePropertySources destination, String lastAdded,
				PropertySource<?> source) {
			if (lastAdded == null) {
				if (destination.contains(DEFAULT_PROPERTIES)) {
					destination.addBefore(DEFAULT_PROPERTIES, source);
				}
				else {
					destination.addLast(source);
				}
			}
			else {

			    // 最后通过将 source 添加到 environment 中的 MutablePropertySources 对象中。
				destination.addAfter(lastAdded, source);
			}
		}

		// 至此，properties 和 YAML 配置文件就被加载到了上下文环境共享的 Environment 中，之后如 @Value 等获取值都是从该对象中获取
	}
}

可以看到，ConfigFileApplicationListener 主要功能就是将 properties 和 YAML 文件加载到 Environment 中。另外还存在一个 @PropertySource 注解，也是加载指定的配置文件到 Environment 中。

3.1.2、关联 SpringConfigurationPropertySources

我们回到最外面的 prepareEnvironment 方法，来看看执行完监听方法时 ConfigurableEnvironment 中加载了多少种外部化配置：



有七种，包括新增的 properties 配置文件。

之后还有一个操作，通过 ConfigurationPropertySources.attach 关联 SpringConfigurationPropertySources 类，该类主要是做一个适配器的工作，将 MutablePropertySources 转换为 ConfigurationPropertySource，下一小节将会用到对象。我们进入 attach 方法查看：

public final class ConfigurationPropertySources {

    private static final String ATTACHED_PROPERTY_SOURCE_NAME = "configurationProperties";

    public static void attach(Environment environment) {
        Assert.isInstanceOf(ConfigurableEnvironment.class, environment);

        // 获取 ConfigurableEnvironment 中的 MutablePropertySources
        MutablePropertySources sources = ((ConfigurableEnvironment) environment).getPropertySources();

        // 获取名为 configurationProperties 的外部化配置源对象
        PropertySource<?> attached = sources.get(ATTACHED_PROPERTY_SOURCE_NAME);

        // 如果存在，则把该对象移除
        if (attached != null && attached.getSource() != sources) {
        	sources.remove(ATTACHED_PROPERTY_SOURCE_NAME);
        	attached = null;
        }

        // 不存在，则添加一个配置源对象，具体对象类型为 ConfigurationPropertySourcesPropertySource，源对象中的数据为 SpringConfigurationPropertySources
        if (attached == null) {
        	sources.addFirst(new ConfigurationPropertySourcesPropertySource(ATTACHED_PROPERTY_SOURCE_NAME,
        			new SpringConfigurationPropertySources(sources)));
        }
    }
}

到这里，ConfigurableEnvironment 又新增了一个 ConfigurationPropertySourcesPropertySource 类型的配置源对象。我们主要来关注 SpringConfigurationPropertySources 对象，可以看到，这里是通过它的带参构造器创建该对象，参数 sources 是从 ConfigurableEnvironment 中获取的 MutablePropertySources 对象。我们进入 SpringConfigurationPropertySources 类中查看：

class SpringConfigurationPropertySources implements Iterable<ConfigurationPropertySource> {

    ...

    private final Iterable<PropertySource<?>> sources;

    SpringConfigurationPropertySources(Iterable<PropertySource<?>> sources) {
		Assert.notNull(sources, "Sources must not be null");
		this.sources = sources;
	}

	...
}

可以看到，外部 ConfigurableEnvironment 的 MutablePropertySources 关联到了该类中的 Iterable （继承关系） 对象，这就是在进行适配工作。

至此， Environment 的创建过程及加载外部化配置的过程就到这里结束，我们简要回顾一下该流程：

1. 首先 Environment 是一个较为特殊的类，术语称之为应用运行时的环境。它存储了所有的外部化配置，可以通过它获取任意配置数据，并且 @Value、 @ConfigurationProperties 等其它获取配置数据的方式都依赖于该类。
2. 通过判断应用的类型，来创建不同环境的 Environment ，有 Servlet、Reactive、非 Web 类型。
3. 之后会相继添加外部化配置到该类中，每种外部化配置都对应了一个 PropertySource 配置源对象。
4. 重点介绍了加载 properties 和 YAML 的方式。主要是通过回调 Spring Boot 的监听器 ConfigFileApplicationListener 进行处理。

加载完之后，就可以在应用中通过 @Autowired 注入该对象，获取任意外部化配置属性。

接下来要讨论的是在 Spring Boot 时代是如何通过 @ConfigurationProperties 来获取配置属性的。因篇幅过长， @ConfigurationProperties 内容另起一章。