SpringBoot 源码分析(三) 监听器分析以及属性文件加载分析

前言

在创建SpringBoot项目的时候会在对应的application.properties或者application.yml文件中添加对应的属性信息，这些属性文件是什么时候被加载的？如果要实现自定义的属性文件怎么来实现？在讲属性加载之前先讲下监听器分析。

一、监听器分析

1、SpringBoot源码之监听器设计

1.1 观察者模式

监听器的设计会使用到Java设计模式中的观察者模式。

观察者模式又称为发布/订阅(Publish/Subscribe)模式,在对象之间定义了一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象会收到通知并自动更新。

在java.util包中包含有基本的Observer接口和Observable抽象类.功能上和Subject接口和Observer接口类似.不过在使用上,就方便多了,因为许多功能比如说注册,删除,通知观察者的那些功能已经内置好了.

1.2 SpringBoot中监听器的设计

然后我们来看下SpringBoot启动这涉及到的监听器这块是如何实现的。

2.1 初始化操作

在SpringApplication的构造方法中会加载所有声明在spring.factories中的监听器。
在springboot的监听器有如下两类：

# Run Listeners
#事件发布运行监听器，是springboot中配置的唯一一个应用运行监听器，
作用是通过一个多路广播器，将springboot运行状态的变化，构建成事件，并广播给各个监听器
org.springframework.boot.SpringApplicationRunListener=\
org.springframework.boot.context.event.EventPublishingRunListener

# Application Listeners
org.springframework.context.ApplicationListener=\
org.springframework.boot.ClearCachesApplicationListener(),\
org.springframework.boot.builder.ParentContextCloserApplicationListener,\
org.springframework.boot.cloud.CloudFoundryVcapEnvironmentPostProcessor,\
org.springframework.boot.context.FileEncodingApplicationListener,\
org.springframework.boot.context.config.AnsiOutputApplicationListener,\
org.springframework.boot.context.config.ConfigFileApplicationListener,\
org.springframework.boot.context.config.DelegatingApplicationListener,\
org.springframework.boot.context.logging.ClasspathLoggingApplicationListener,\
org.springframework.boot.context.logging.LoggingApplicationListener,\
org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener

# Application Listeners
org.springframework.context.ApplicationListener=\
org.springframework.boot.autoconfigure.BackgroundPreinitializer

通过对这些内置监听器的源码查看我们发现这些监听器都实现了 ApplicationEvent接口。也就是都会监听 ApplicationEvent发布的相关的事件。ApplicationContext事件机制是观察者设计模式的实现，通过ApplicationEvent类和ApplicationListener接口，可以实现ApplicationContext事件处理。

2.2 run方法

在SpringApplication.run()方法中是如何发布对应的事件的?

首先会通过getRunListeners方法来获取我们在spring.factories中定义的SpringApplicationRunListener类型的实例。也就是EventPublishingRunListener。



加载这个类型的时候会同步的完成实例化。

实例化操作就会执行EventPublishingRunListener.

在这个构造方法中会绑定我们前面加载的11个过滤器。

到这其实我们就已经清楚了EventPublishingRunListener和我们前面加载的11个监听器的关系了。然后在看事件发布的方法。

查看starting()方法。


进入到multicastEvent中方法中我们可以看到具体的触发逻辑

以ConfigFileApplicationListener为例。

触发会进入ConfigFileApplicationListener对象的onApplicationEvent方法中

通过代码我们可以发现当前的事件是ApplicationStartingEvent事件，都不满足，所以ConfigFileApplicationListener在SpringBoot项目开始启动的时候就不会做任何的操作。而当我们在配置环境信息的时候，会发布对应的事件来触发


继续进入

继续进入

然后再触发ConfigFileApplicationListener监听器的时候就会触发如下方法了

其实到这儿，后面的事件发布与监听器的处理逻辑就差不多是一致了。到这儿对应SpringBoot中的监听器这块就分析的差不错了。像SpringBoot的属性文件中的信息什么时候加载的就是在这些内置的监听器中完成的。

官方内置的事件有：

二、属性加载过程分析

1. 找到入口

在SpringApplication.run()方法，在该方法中会针对SpringBoot项目启动的不同的阶段来发布对应的事件。

处理属性文件加载解析的监听器是 ConfigFileApplicationListener ,这个监听器监听的事件有两个。

进入SpringApplication.prepareEnvironment()方法中发布的事件其实就是ApplicationEnvironmentPreparedEvent事件。进入代码查看。

进行进入

继续进入会看到对应的发布事件：ApplicationEnvironmentPreparedEvent

结合上篇文件的内容，我们知道在initialMulticaster中是有ConfigFileApplicationListener这个监听器的。

2. ConfigFileApplicationListener

2.1 主要流程分析

ConfigFileApplicationListener中具体的如何来处理配置文件的加载解析的。

根据逻辑我们直接进入onApplicationEnvironmentPreparedEvent()方法中。

系统提供那4个不是重点，重点是 ConfigFileApplicationListener 中的这个方法处理.

直接进入ConfigFileApplicationListener.postProcessEnvironment()方法。

在进入addPropertySources()方法中会完成两个核心操作，
1。创建Loader对象，2。调用Loader对象的load方法，

2.2 Loader构造器

现在我们来看下在Loader构造器中执行了什么操作。

通过源码我们可以发现在其中获取到了属性文件的加载器、从spring.factories文件中获取，对应的类型是 PropertySourceLoader类型。

而且在loadFactories方法中会完成对象的实例化。

到这Loader的构造方法执行完成了，然后来看下load()方法的执行。先把代码贴上

void load() {
			FilteredPropertySource.apply(this.environment, DEFAULT_PROPERTIES, LOAD_FILTERED_PROPERTY,
					(defaultProperties) -> {
						// 创建默认的profile 链表
						this.profiles = new LinkedList<>();
						// 创建已经处理过的profile 类别
						this.processedProfiles = new LinkedList<>();
						// 默认设置为未激活
						this.activatedProfiles = false;
						// 创建loaded对象
						this.loaded = new LinkedHashMap<>();
						// 加载配置 profile 的信息，默认为 default
						initializeProfiles();
						// 遍历 Profiles，并加载解析
						while (!this.profiles.isEmpty()) {
							// 从双向链表中获取一个profile对象
							Profile profile = this.profiles.poll();
							// 非默认的就加入，进去看源码即可清楚
							if (isDefaultProfile(profile)) {
								addProfileToEnvironment(profile.getName());
							}
							load(profile, this::getPositiveProfileFilter,
									addToLoaded(MutablePropertySources::addLast, false));
							this.processedProfiles.add(profile);
						}
						// 解析 profile
						load(null, this::getNegativeProfileFilter, addToLoaded(MutablePropertySources::addFirst, true));
						// 加载默认的属性文件 application.properties
						addLoadedPropertySources();
						applyActiveProfiles(defaultProperties);
					});
		}

然后我们进入具体的apply()方法中来查看。

中间的代码都有注释，主要是处理profile的内容。

首先是getSearchLocations()方法，在该方法中会查询默认的会存放对应的配置文件的位置，如果没有自定义的话，路径就是 file:./config/ file:./ classpath:/config/ classpath:/ 这4个


然后回到load方法中，遍历4个路径，然后加载对应的属性文件。

getSearchNames()获取的是属性文件的名称。如果自定义了就加载自定义的

否则加载默认的application文件。

再回到前面的方法

进入load方法，会通过前面的两个加载器来分别加载application.properties和application.yml的文件。

loader.getFileExtensions()获取对应的加载的文件的后缀。



进入loadForFileExtension()方法，对profile和普通配置分别加载

继续进入load方法





开始加载我们存在的application.properties文件。

2.3 properties加载

在找到了要加载的文件的名称和路径后，我们来看下资源加载器是如何来加载具体的文件信息的。

进入loadDocuments方法中，我们会发现会先从缓存中查找，如果缓存中没有则会通过对应的资源加载器来加载了。

此处是PropertiesPropertySourceLoader来加载的。


进入loadProperties方法

之后进入load()方法看到的就是具体的加载解析properties文件中的内容了。感兴趣的可以看下具体的逻辑，本文就给大家介绍到这里了。