一般框架，启动之后都会尽快加载配置文件，springboot也不例外，下面就开始分析一下springboot加载配置文件的流程。
springboot配置的加载是从listener类开始的，还记得上一节我说listener类的调用没那么简单么，这一节就先从listener类的调用开始。
run方法中，listeners初始化的地方。
public ConfigurableApplicationContext run(String... args) {
...
SpringApplicationRunListeners listeners = getRunListeners(args);
listeners.starting();
...
}
listener类在SpringApplication对象初始化的时候，我们已经从配置文件中获取到了，并存放在了集合里，那么这边为什么没有直接调用而是又绕了一个逻辑呢，先进入getRunListeners方法。
private SpringApplicationRunListeners getRunListeners(String[] args) {
Class<?>[] types = new Class<?>[] { SpringApplication.class, String[].class };
return new SpringApplicationRunListeners(logger, getSpringFactoriesInstances(
SpringApplicationRunListener.class, types, this, args));
}
getRunListeners方法中，首先获取了SpringApplicationRunListener对象，并且使用SpringApplication，和args作为的构造函数的参数。然后在使用获得的SpringApplicationRunListener对象集合作为参数，构造了SpringApplicationRunListeners对象。 我们先去看看SpringApplicationRunListener对象是啥。
getSpringFactoriesInstances这个方法大家 应该很熟了，从SpringApplication对象新建时候就一直在调用，所以我们可以直接到配置文件中看一下，获取的SpringApplicationRunListener对象到底是啥。
public class EventPublishingRunListener implements SpringApplicationRunListener, Ordered {
public EventPublishingRunListener(SpringApplication application, String[] args) {
this.application = application;
this.args = args;
this.initialMulticaster = new SimpleApplicationEventMulticaster();
for (ApplicationListener<?> listener : application.getListeners()) {
this.initialMulticaster.addApplicationListener(listener);
}
}
在配置文件中发现了EventPublishingRunListener对象，这就是getRunListeners方法中获得到的SpringApplicationRunListener对象，构造函数很简单，我就不详细分析了。原本SpringApplication类中的listener对象，现在被封装到了EventPublishingRunListener对象中。
回过头来再看，SpringApplicationRunListener类又被封装到了SpringApplicationRunListeners对象中，这样getRunListeners方法的逻辑就执行完了。
现在看看listeners.starting()方法的调用逻辑。
public void starting() {
for (SpringApplicationRunListener listener : this.listeners) {
//遍历调用starting方法
listener.starting();
}
}
public void starting() {
//这个地方封装了一个事件，大概猜一下应该是打算使用策略模式
this.initialMulticaster.multicastEvent(
new ApplicationStartingEvent(this.application, this.args));
}
public void multicastEvent(ApplicationEvent event) {
multicastEvent(event, resolveDefaultEventType(event));
}
public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
//getApplicationListeners获取了符合策略的监听器
for (final ApplicationListener<?> listener : getApplicationListeners(event, type)) {
Executor executor = getTaskExecutor();
if (executor != null) {
executor.execute(() -> invokeListener(listener, event));
}
else {
invokeListener(listener, event);
}
}
}
protected void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
...
doInvokeListener(listener, event);
...
}
private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) {
...
listener.onApplicationEvent(event);
...
}
最后终于在doInvokeListener方法中，看到了监听器的执行。所有监听器的执行都使用的策略模式，如果想符合某些事件，在监听器的onApplicationEvent方法中配置一下即可。在这儿，我们也可以感受到spring框架设计的规范性，使用策略模式可以很方便的基于事件做相应扩展。
上面我们已经了解了listener类的启动逻辑，下面开始正式分析配置文件的加载。
public ConfigurableApplicationContext run(String... args) {
...
ApplicationArguments applicationArguments = new DefaultApplicationArguments(
args);
ConfigurableEnvironment environment = prepareEnvironment(listeners,
applicationArguments);
...
}
private ConfigurableEnvironment prepareEnvironment(
SpringApplicationRunListeners listeners,
ApplicationArguments applicationArguments) {
...
listeners.environmentPrepared(environment);
...
}
在run方法中，找到prepareEnvironment方法，进入之后，会看到监听器启动了environmentPrepared事件，所以我们就去监听器里面，找找看符合环境事件的监听器。
看名字也能看出来，就是他ConfigFileApplicationListener。找到他的onApplicationEvent方法，开始分析。
public void onApplicationEvent(ApplicationEvent event) {
if (event instanceof ApplicationEnvironmentPreparedEvent) {
//入口在这儿
onApplicationEnvironmentPreparedEvent(
(ApplicationEnvironmentPreparedEvent) event);
}
if (event instanceof ApplicationPreparedEvent) {
onApplicationPreparedEvent(event);
}
}
private void onApplicationEnvironmentPreparedEvent(
ApplicationEnvironmentPreparedEvent event) {
List<EnvironmentPostProcessor> postProcessors = loadPostProcessors();
postProcessors.add(this);
AnnotationAwareOrderComparator.sort(postProcessors);
for (EnvironmentPostProcessor postProcessor : postProcessors) {
//虽然这边还有其他几个监听器，但是最重要的依然是他本身所以，我们还是分析他本身的postProcessEnvironment方法
postProcessor.postProcessEnvironment(event.getEnvironment(),
event.getSpringApplication());
}
}
postProcessEnvironment方法逻辑如下
public void postProcessEnvironment(ConfigurableEnvironment environment,
SpringApplication application) {
addPropertySources(environment, application.getResourceLoader());
}
protected void addPropertySources(ConfigurableEnvironment environment,
ResourceLoader resourceLoader) {
RandomValuePropertySource.addToEnvironment(environment);
//关键代码在这儿
new Loader(environment, resourceLoader).load();
}
//先看构造函数
Loader(ConfigurableEnvironment environment, ResourceLoader resourceLoader) {
this.environment = environment;
this.placeholdersResolver = new PropertySourcesPlaceholdersResolver(
this.environment);
this.resourceLoader = (resourceLoader != null) ? resourceLoader
: new DefaultResourceLoader();
//这个方法又见到了，话不多说，打开配置文件
this.propertySourceLoaders = SpringFactoriesLoader.loadFactories(
PropertySourceLoader.class, getClass().getClassLoader());
}
//这就是yml和properties配置支持的来源
org.springframework.boot.env.PropertySourceLoader=\
org.springframework.boot.env.PropertiesPropertySourceLoader,\
org.springframework.boot.env.YamlPropertySourceLoader
Loader类在构造函数中获取了yml和properties配置文件的支持。下面开始分析load函数。
public void load() {
...
//前面是关于profile的配置逻辑不复杂应该可以看懂，关键方法是load
load(null, this::getNegativeProfileFilter,
addToLoaded(MutablePropertySources::addFirst, true));
...
}
private void load(Profile profile, DocumentFilterFactory filterFactory,
DocumentConsumer consumer) {
//关注getSearchLocations方法
getSearchLocations().forEach((location) -> {
boolean isFolder = location.endsWith("/");
//关注getSearchNames方法
Set<String> names = isFolder ? getSearchNames() : NO_SEARCH_NAMES;
names.forEach(
(name) -> load(location, name, profile, filterFactory, consumer));
});
}
在getSearchLocations方法中，可以看到如果没有指定地址的话，默认地址就是”classpath:/,classpath:/config/,file:./,file:./config/”，如果想指定的话，启动时需要加上spring.config.location参数
在getSearchNames方法中，可以看到如果没有指定配置文件名称的话，配置文件的名字就按照application来搜索。如果想指定的话，启动时需要加上spring.config.name参数
所以继续往下看load方法
private void load(String location, String name, Profile profile,
DocumentFilterFactory filterFactory, DocumentConsumer consumer) {
...
Set<String> processed = new HashSet<>();
for (PropertySourceLoader loader : this.propertySourceLoaders) {
for (String fileExtension : loader.getFileExtensions()) {
if (processed.add(fileExtension)) {
loadForFileExtension(loader, location + name, "." + fileExtension,
profile, filterFactory, consumer);
}
}
}
}
在这一层的load方法中，看到了Loader类新建时，获取的yml和properties格式支持类propertySourceLoaders,查看两个类的getFileExtensions方法
public class YamlPropertySourceLoader implements PropertySourceLoader {
@Override
public String[] getFileExtensions() {
return new String[] { "yml", "yaml" };
}
public class PropertiesPropertySourceLoader implements PropertySourceLoader {
private static final String XML_FILE_EXTENSION = ".xml";
@Override
public String[] getFileExtensions() {
return new String[] { "properties", "xml" };
}
到了这一步，我们终于摸清了为什么默认的配置文件名字必须是application，而且可以为yml和properties格式。
最后加载的过程其实没啥好分析的了。经过了我们的一通操作，我们已经顺利的摸清了springboot默认配置加载的来源，并且了解了如果想指定配置该怎么做。