1 SpringBoot简介
SpringBoot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，Boot致力于在蓬勃发展的快速应用开发领域（rapid application development）成为领导者。
SpringBoot并不是要成为Spring平台里面众多“Foundation”层项目的替代者。SpringBoot的目标不在于为已解决的问题域提供新的解决方案，而是为平台带来另一种开发体验，从而简化对这些已有技术的使用。
SpringBoot主要有如下核心特点：
- 包含执行所需的一切的可执行jar包。包含了运行所需的一切，包括内嵌应用服务器等，并打包为一个可执行jar文件部署，这点在微服务概念里非常重要。
- 约定大于配置理念的完美践行，自动配置模块
- 提供各种各样的starter简化初始配置过程
- 提供各种扩展机制等等
2 一个简单的例子
下面先通过一个简单的例子看一下使用SpringBoot开发项目能有多快捷。我们打算编写一个web服务器，设置启动端口并提供一个简单的页面/index，当浏览该页面时会显示hello world。为了达到这样的效果只需要简单的几步就可以做到：
配置pom.xml
在其中添加如下依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
编写项目的启动类
@SpringBootApplication
public class SBApplication {
public static void main(String args[]) throws Exception{
SpringApplication.run(SBApplication.class, args);
}
}
添加Controller
最后，编写页面/index对应的Controller:
@RestController
public class TestController {
@RequestMapping("/index")
public String index(){
return "hello world";
}
}
默认端口为8080，为了设置自定义端口，我们在项目的/src/main/resources下新建application.properties文件，并在其中加上：
server.port=7668
如此一来，一个最简单的SpringBoot Web程序就完成了，由于启动类有main方法，我们直接run as application就可以运行这个程序，控制台输出结果为：
...................
2017-12-30 00:50:35.873 INFO 14033 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup
2017-12-30 00:50:35.931 INFO 14033 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 7668 (http)
2017-12-30 00:50:35.937 INFO 14033 --- [ main] springbootext.SBApplication : Started SBApplication in 3.752 seconds (JVM running for 4.089)
看到输出的最后几句就表示web服务器启动成功了，端口为我们定义的7668。接下来访问
http://localhost:7668/index
就能看到页面上显示的hello world，一个基本的web服务器就这么简简单单创建完成了，简直是简单的令人发指。
上面的SpringBoot程序跟一个普通java程序的两点不同在于@SpringBootApplication注释以及SpringApplication类。下面我们介绍这两者的功能及其背后的SpringBoot框架的实现原理。
3 @SpringBootApplication注释
前面例子中为了简洁，直接将@SpringBootApplication打在了主类上，其实更加清晰的写法应该是将主类和SpringBoot配置类分开，如下所示：
@SpringBootApplication
public class SBConfiguration {
}
public class SBApplication {
public static void main(String args[]) throws Exception{
SpringApplication.run(SBConfiguration.class, args);
}
}
如此一来，就能比较清晰的看出主类SBApplication只是程序的入口，没有什么特殊的。调用了SpringApplication的静态方法run，并使用SpringBoot主配置类SBConfigration.class作为参数。
主配置类就是打上@SpringBootApplication注释的类，首先看一下注释SpringBootApplication的代码：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = {
@Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
...........................
}
可以看出，这是一个复合注释，其中@SpringBootConfiguration代表了SpringBoot的配置类，除了测试时有些区别，大体上就是Spring标准@Configuration的替代品。
@EnableAutoConfiguration用于启动SpringBoot的自动配置机制，这是SpringBoot的核心特色之一，自动对各种机制进最大可能的进行配置。
@ComponentScan是Spring原来就有的注释，用于对指定的路径进行扫描，并将其中的@Configuration配置类加载。接下来分别对其一一介绍。
3.1 @SpringBootConfiguration
先看该注释的定义：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
public @interface SpringBootConfiguration {
}
从代码可见，其本质上就是一个@Configuration。唯一不同的地方是在测试时，如果打上了@SpringBootConfiguration注释，那么SpringBootTest中并不需要指定就可以自动加载该配置类；而当打上@Configuration时，需要通过@SpringBootTest(classes = SBConfiguration.class)来指定加载的SpringBoot配置类。
若不考虑测试时非要省略指定Configuration类的话，该注释可有可无。因为在作为参数传递给SpringApplication.run方法后，只要其中配置了@Bean方法，就会直接被认为是一个配置类进行加载处理，并不需要@Configuration来标识。
应用启动时在springcontext经典的refresh主流程中，当beanFactory创建完成后会执行invokeBeanFactoryPostProcessors阶段，该阶段会调用前面注册的BeanFactoryPostProcessors中的postProcessBeanDefinitionRegistry方法来对beanFactory进一步处理。
其中ConfigurationClassPostProcessor是专门用来处理Configuration类的启动加载进程的。其processConfigBeanDefinitions方法中首先使用：
String[] candidateNames = registry.getBeanDefinitionNames();
获得所有已注册到registry中的beanDefinitionNames然后对其中的每一个beanDefinitionName判断其是否属于配置类：
for (String beanName : candidateNames) {
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||
ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {
if (logger.isDebugEnabled()) {
logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);
}
}
else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
}
其中把判断beanDef是否为Configuration类委托给ConfigurationClassUtils来处理，ConfigurationClassUtils类通过两个方法来确定一个类是否是配置类：
public static boolean isFullConfigurationCandidate(AnnotationMetadata metadata) {
return metadata.isAnnotated(Configuration.class.getName());
}
以及
public static boolean isLiteConfigurationCandidate(AnnotationMetadata metadata) {
// Do not consider an interface or an annotation...
if (metadata.isInterface()) {
return false;
}
// Any of the typical annotations found?
for (String indicator : candidateIndicators) {
if (metadata.isAnnotated(indicator)) {
return true;
}
}
// Finally, let's look for @Bean methods...
try {
return metadata.hasAnnotatedMethods(Bean.class.getName());
}
catch (Throwable ex) {
if (logger.isDebugEnabled()) {
logger.debug("Failed to introspect @Bean methods on class [" + metadata.getClassName() + "]: " + ex);
}
return false;
}
}
从上述代码可知，当一个类没有标注@Configuration但是其中定义了@Bean方法时，也会被判断为lite configuration（轻量级配置）类。判断过程完成后，委托ConfigurationClassParser来解析前面找到的每一个配置类，具体解析过程在此就不展开了，回头会专门写一篇关于spring context的介绍文章详细介绍。
由此我们可知，如果在springcontext refresh主流程的invokeBeanFactoryPostProcessors阶段之前就将beanDefinition注册到beanDefinitionRegistry，那么这个beanDefinition并不需要非得打上@Configuration注释，也可以通过其内部定义的@Bean方法被认定是一个Configuration类。
而在SpringApplication的run方法中以参数形式传递进去，就是方法之一。
例如，当我们把上述代码修改为：
@EnableAutoConfiguration
@ComponentScan
public class SBConfiguration {
}
并不会有任何影响。
3.2 @EnableAutoConfiguration
EnableAutoConfiguration自动配置机制是SpringBoot的核心特色之一。可根据引入的jar包对可能需要的各种机制进进行默认配置。
该注释的定义如下：
@SuppressWarnings("deprecation")
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(EnableAutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {
..........
}
其中@AutoConfigurationPackage用来指示包含打了该注释的类的包（package）应该被注册到AutoConfigurationPackages中，以备后续扩展机制（例如JPA或Mybatis等）的实体扫描器使用。
@EnableAutoConfiguration真正核心的动作就是通过Import机制加载EnableAutoConfigurationImportSelector.selectImports函数返回的配置类：
public String[] selectImports(AnnotationMetadata annotationMetadata) {
if (!isEnabled(annotationMetadata)) {
return NO_IMPORTS;
}
try {
AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader
.loadMetadata(this.beanClassLoader);
AnnotationAttributes attributes = getAttributes(annotationMetadata);
List<String> configurations = getCandidateConfigurations(annotationMetadata,
attributes);
configurations = removeDuplicates(configurations);
configurations = sort(configurations, autoConfigurationMetadata);
Set<String> exclusions = getExclusions(annotationMetadata, attributes);
checkExcludedClasses(configurations, exclusions);
configurations.removeAll(exclusions);
configurations = filter(configurations, autoConfigurationMetadata);
fireAutoConfigurationImportEvents(configurations, exclusions);
return configurations.toArray(new String[configurations.size()]);
}
catch (IOException ex) {
throw new IllegalStateException(ex);
}
}
其中比较核心的动作为getCandidateConfigurations(annotationMetadata, attributes)，代码如下：
protected List<String> getCandidateConfigurations(AnnotationMetadata metadata,
AnnotationAttributes attributes) {
List<String> configurations = SpringFactoriesLoader.loadFactoryNames(
getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader());
Assert.notEmpty(configurations,
"No auto configuration classes found in META-INF/spring.factories. If you "
+ "are using a custom packaging, make sure that file is correct.");
return configurations;
}
protected Class<?> getSpringFactoriesLoaderFactoryClass() {
return EnableAutoConfiguration.class;
}
我们注意：
List<String> configurations = SpringFactoriesLoader.loadFactoryNames(
getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader());
这句，SpringFactoriesLoader是spring framework内部使用的通用的工厂加载机制，其可加载并实例化可能出现在classpath上的多个jar包中的META-INF/spring.factories文件中定义的指定类型的工厂，可视为一种类似于SPI的接口。
SpringBoot利用这种SPI接口实现了autoconfiguration机制：委托SpringFactoriesLoader来加载所有配置在META-INF/spring.factories中的org.springframework.boot.autoconfigure.EnableAutoConfiguration对应的值，spring-boot-autoconfiguration jar包中的META-INF/spring.factories中的EnableAutoConfiguration配置摘录如下：
Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\
org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,\
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration,\
org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration,\
org.springframework.boot.autoconfigure.cloud.CloudAutoConfiguration,\
..........................
其中我们可以看到相当多非常熟悉的自动配置类，例如AopAutoConfiguration、CacheAutoConfiguration等等。其中的每一个自动配置类都会在一定条件（@Condition）下启动生效，并对相关的机制进行默认自动的配置。这便是SpringBoot自动配置机制的核心功能所在。
3.3 @ComponentScan
这是spring-context原来就存在的注释，需要在@Configuration标注的类上标注，用来指示扫描某些包及其子包上的组件。可通过配置属性basePackageClasses、basePackages或value来指出需要扫描哪些包（包括其子包），如果没有指定任何一个属性值，则默认扫描当前包及其子包。
例如，在前面例子中，如果SBConfiguration所在的包是springbootext，那么由于SBConfiguration打了@ComponentScan注释，那么在springbootext、springbootext.service、springbootext.config等等地方定义的@Configuration、@Component、@Service、@Controller等等组件都可以直接被加载，无需额外配置。而在anotherpackage中定义的组件，无法被直接加载。可以通过设置扫描路径来解决：
@EnableAutoConfiguration
@ComponentScan(basePackages={"springbootext", "anotherpackage"})
public class SBConfiguration{
}
当然也可以通过借助3.2节中介绍的在spring.factories中定义扩展机制定义EnableAutoConfiguration来实现加载。
启动过程中@ComponentScan起作用的时机是在springcontext refresh主流程的invokeBeanFactoryPostProcessor阶段，也就是BeanFactory创建并准备完毕后通过BeanFactoryPostProcessors来进一步对beanFactory进行处理的阶段。
在该阶段，ConfigurationClassPostProcessor中对于Configuration类的处理里包括了识别其打的@ComponentScan注释，并委托ComponentScanAnnotationParser根据该注释的属性值进行组件扫描。将扫描生成的beanDefinitions注册到beanFactory中供下一个阶段创建beans。
4 SpringApplication一站式程序启动解决方案
当我们执行SpringApplication.run(Object[] sources, String[] args)静态方法时，内部会执行
new SpringApplication(sources).run(args);
因此，我们也可以将前面程序主类的启动过程修改为：
public class SBApplication {
public static void main(String args[]) throws Exception{
SpringApplication sa = new SpringApplication(SBConfiguration.class);
sa.run(args);
}
}
如此一来，我们可以使用到SpringApplication提供的一系列实例方法对其进行配置。
从上面代码看，应用的启动过程分为两部分：首先创建一个SpringApplication对象；然后执行其对象方法run。构造函数中实际业务逻辑都放在了initialize方法中。下面我们分别分析这两部分都干了什么。
4.1 初始化initialize
顾名思义，initialize就是初始化函数，其代码如下：
private void initialize(Object[] sources) {
if (sources != null && sources.length > 0) {
this.sources.addAll(Arrays.asList(sources));
}
this.webEnvironment = deduceWebEnvironment();
setInitializers((Collection) getSpringFactoriesInstances(
ApplicationContextInitializer.class));
setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
this.mainApplicationClass = deduceMainApplicationClass();
}
首先，将初始化参数中的Object… sources保存在this.sources中，供后续run方法的prepareContext阶段使用。该参数代表了SpringBoot启动时指定的Configuration类（可多个）。然后通过判断当前是否含有：
private static final String[] WEB_ENVIRONMENT_CLASSES = { "javax.servlet.Servlet",
"org.springframework.web.context.ConfigurableWebApplicationContext" };
中定义的两个类，来判断当前是否是一个web环境，后续会针对不同的环境创建不同的ApplicationContext。
接着通过两个函数getSpringFactoriesInstances(ApplicationContextInitializer.class)、getSpringFactoriesInstances(ApplicationListener.class)得到以SpringFactoriesLoader扩展方案注册的ApplicationContextInitializer和ApplicationListener类型的实例，并设置到当前SpringApplication的对象中。在这两个函数都调用了：
private <T> Collection<? extends T> getSpringFactoriesInstances(Class<T> type,
Class<?>[] parameterTypes, Object... args) {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
// Use names and ensure unique to protect against duplicates
Set<String> names = new LinkedHashSet<String>(
SpringFactoriesLoader.loadFactoryNames(type, classLoader));
List<T> instances = createSpringFactoriesInstances(type, parameterTypes,
classLoader, args, names);
AnnotationAwareOrderComparator.sort(instances);
return instances;
}
来获取特定类型的实例，又看到了熟悉的SpringFactoriesLoader。查找配置在classpath及各个jar包中的META-INF/spring.factories中配置的ApplicationContextInitializer和ApplicationListener，并实例化。
最后一步得到含有main函数的主类，并保存在mainApplicationClass属性中。
4.2 实际启动过程run
SpringApplication将SpringBoot应用启动流程模板化，并在启动过程的不同时机定义了一系列不同类型的的扩展点，方便我们对其进行定制。下面对整个启动过程代码进行分析：
-
通过SpringFactoriesLoader来获取定义在spring.factories中的SpringApplicationRunListener，SpringBoot框架默认只定义了一个EventPublishingRunListener，其中维护了一个SimpleApplicationEventMulticaster，并将前面initialize阶段中获得的ApplicationListeners注册进去。然后调用其start方法，给所有的SpringApplicationRunListener发送一个start事件，然后EventPublishingRunListener给注册在其中的所有ApplicationListener发送ApplicationStartedEvent。
SpringApplicationRunListeners listeners = getRunListeners(args); listeners.starting();
此处包含了两个扩展点，我们可以自定义SpringApplicationRunListener以扩展SpringBoot程序启动过程，也可以自定义ApplicationListener以扩展EventPublishingRunListener。我们后面可以看到在启动的不同阶段，会发送不同的事件给SpringApplicationRunListeners和ApplicationListeners。
-
将参数包装为ApplicationArguments，DefaultApplicationArguments是用来维护命令行参数的，例如可以方便的将命令行参数中的options和non options区分开，以及获得某option的值等。
ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
-
通过ApplicationArguments来准备应用环境Environment， Environment包含了两个层面的信息：属性（properties）和轮廓（profiles）：
ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
prepareEnvironment方法的代码如下：
private ConfigurableEnvironment prepareEnvironment(
SpringApplicationRunListeners listeners,
ApplicationArguments applicationArguments) {
// Create and configure the environment
ConfigurableEnvironment environment = getOrCreateEnvironment();
configureEnvironment(environment, applicationArguments.getSourceArgs());
listeners.environmentPrepared(environment);
if (!this.webEnvironment) {
environment = new EnvironmentConverter(getClassLoader())
.convertToStandardEnvironmentIfNecessary(environment);
}
return environment;
}
在getOrCreateEnvironment()方法中通过4.1初始化中判断的是否为web应用创建一个StandardServletEnvironment或StandardEnvironment。然后执行configureEnvironment函数：
protected void configureEnvironment(ConfigurableEnvironment environment,
String[] args) {
configurePropertySources(environment, args);
configureProfiles(environment, args);
}
其中分别配置属性源（propertySource）以及轮廓（profile），关于Environment中的属性来源分散在启动的若干个阶段，并且按照特定的优先级顺序，也就是说一个属性值可以在不同的地方配置，但是优先级高的值会覆盖优先级低的值。具体属性取值顺序我们将专门在下面详细介绍。
而轮廓（profile）可以认为是程序的运行环境，典型的环境比如有开发环境（Develop）、生产环境（Production）、测试环境（Test）等等。我们可以定义某个Bean在特定的环境中才生效，这样就可以通过指定profile来方便的切换运行环境。可通过SpringApplication.setAdditionalProfiles()来设置轮廓，environment内通过activeProfiles来维护生效的轮廓（可不止一个）。
在环境配置完毕后，执行所有SpringApplicationRunListeners的environmentPrepared函数，然后EventPublishingRunListener给所有注册其中的ApplicationListeners发送一个“环境准备好了”ApplicationEnvironmentPreparedEvent事件：
listeners.environmentPrepared(environment);
此时各SpringApplicationRunListener或ApplicationListener已经可以得到environment了， 可以在此处对environment进行一些额外的处理。
-
根据前面判断的是web应用还是普通应用决定创建什么类型的ApplicationContext：
context = createApplicationContext();
createApplicationContext方法代码如下：
public static final String DEFAULT_CONTEXT_CLASS = "org.springframework.context."
+ "annotation.AnnotationConfigApplicationContext";
public static final String DEFAULT_WEB_CONTEXT_CLASS = "org.springframework."
+ "boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext";
protected ConfigurableApplicationContext createApplicationContext() {
Class<?> contextClass = this.applicationContextClass;
if (contextClass == null) {
try {
contextClass = Class.forName(this.webEnvironment
? DEFAULT_WEB_CONTEXT_CLASS : DEFAULT_CONTEXT_CLASS);
}
catch (ClassNotFoundException ex) {
throw new IllegalStateException(
"Unable create a default ApplicationContext, "
+ "please specify an ApplicationContextClass",
ex);
}
}
return (ConfigurableApplicationContext) BeanUtils.instantiate(contextClass);
}
关于ApplicationContext多说两句：ApplicationContext用于扩展BeanFactory中的功能，ApplicationContext拥有BeanFactory对于Bean的管理维护的所有功能，并且提供了更多的扩展功能，实际上ApplicationContext的实现在内部持有一个BeanFactory的实现来完成BeanFactory的工作。AbstractApplicationContext是ApplicationContext的第一个抽象实现类，其中使用模板方法模式定义了springcontext的核心扩展流程refresh，并提供几个抽象函数供具体子类去实现。其直接子类有AbstractRefreshableApplicationContext和GenericApplicationContext两种。
这两个子类的不同之处在于对内部的DefaultListableBeanFactory的管理：AbstractRefreshableApplicationContext允许多次调用其refreshBeanFactory()函数，每次调用时都会重新创建一个DefaultListableBeanFactory，并将已有的销毁；而GenericApplicationContext不允许刷新beanFactory,只能调用refreshBeanFactory()一次，当多次调用时会抛出异常。
无论AnnotationConfigApplicationContext还是AnnotationConfigEmbeddedWebApplicationContext，它们都是GenericApplicationContext的子类。因此其内部持有的BeanFactory是不可刷新的，并且从初始化开始就一直持有一个唯一的BeanFactory。相关细节会在spring context的介绍中深入讨论。
-
借助SpringFactoriesLoader获得spring.factories中注册的FailureAnalyzers以供当运行过程中出现异常时进行分析：
analyzers = new FailureAnalyzers(context);
其中又用到了SpringFactoriesLoader扩展方案：
List<String> analyzerNames = SpringFactoriesLoader
.loadFactoryNames(FailureAnalyzer.class, classLoader);
-
接着就是SpringBoot启动过程中的最核心流程，对第4步创建的ApplicationContext进行准备：
prepareContext(context, environment, listeners, applicationArguments, printedBanner);
此处就不展开了，在下一节专门对这个函数进行分析。
-
调用ApplicationContext的refresh函数，开启spring context的核心流程，就是根据配置加载bean（spring beans核心功能）以及在各个时机开放的不同扩展机制（spring context）：
refreshContext(context);
这个过程在此不展开了，后续会写关于spring context的文章专门介绍。
-
获取所有的ApplicationRunner和CommandLineRunner并执行：
afterRefresh(context, applicationArguments);
此时由于context已经refresh完毕，因此bean都已经加载完毕了。所以这两个类型的runner都是直接从context中获取的：
protected void afterRefresh(ConfigurableApplicationContext context,
ApplicationArguments args) {
callRunners(context, args);
}
private void callRunners(ApplicationContext context, ApplicationArguments args) {
List<Object> runners = new ArrayList<Object>();
runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());
runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());
AnnotationAwareOrderComparator.sort(runners);
for (Object runner : new LinkedHashSet<Object>(runners)) {
if (runner instanceof ApplicationRunner) {
callRunner((ApplicationRunner) runner, args);
}
if (runner instanceof CommandLineRunner) {
callRunner((CommandLineRunner) runner, args);
}
}
}
两者的执行时机是完全一样的，唯一的区别在于一个接受ApplicationArguments，一个接受String[]类型的原始命令行参数。而ApplicationArguments也只是对原始命令行参数的一个封装，因此本质上是一样的。
此处又定义了两个扩展机制，我们可以自定义ApplicationRunner或CommandLineRunner并将其配置为Bean，便可以在context refresh完毕后执行。
-
spring-context refresh过程完毕后执行所有SpringApplicationRunListeners的finished函数，然后EventPublishingRunListener给所有注册其中的ApplicationListeners发送一个“应用启动完毕”ApplicationReadyEvent事件：
listeners.finished(context, null);
-
当运行时出现异常时，向context发送退出码事件ExitCodeEvent，供其内部listener执行退出前的操作；并使用前面第5步获得的analyzers来打印可能的原因：
handleRunFailure(context, listeners, analyzers, ex);
另外，就算运行异常，也会向SpringApplication中的listeners发送“应用启动完毕”的事件，代码如下：
private void handleRunFailure(ConfigurableApplicationContext context,
SpringApplicationRunListeners listeners, FailureAnalyzers analyzers,
Throwable exception) {
try {
try {
handleExitCode(context, exception);
listeners.finished(context, exception);
}
finally {
reportFailure(analyzers, exception);
if (context != null) {
context.close();
}
}
}
catch (Exception ex) {
logger.warn("Unable to close ApplicationContext", ex);
}
ReflectionUtils.rethrowRuntimeException(exception);
}
此时，EventPublishingRunListener发送给注册其中的ApplicationListeners的事件成了”应用启动异常“ApplicationFailedEvent。
至此，SpringApplication的run函数，也就是SpringBoot应用的启动过程就执行完毕了。可以看出，SpringBoot的启动过程是对Spring context启动过程的扩展，在其中定义了若干的扩展点并提供了不同的扩展机制。并提供了默认配置，我们可以什么都不配，也可以进行功能非常强大的配置和扩展。这也正是SpringBoot的优势所在。
4.3 核心过程prepareContext
顾名思义，该函数的功能就是对前面创建的ApplicationContext进行准备，其执行步骤如下：
- 将environment设置到context中：
context.setEnvironment(environment);
environment是我们在run过程的第3步创建的。
- 对ApplicationContext应用相关的后处理，子类可以重写该方法来添加任意的后处理功能：
postProcessApplicationContext(context);
该方法代码如下：
protected void postProcessApplicationContext(ConfigurableApplicationContext context) {
if (this.beanNameGenerator != null) {
context.getBeanFactory().registerSingleton(
AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR,
this.beanNameGenerator);
}
if (this.resourceLoader != null) {
if (context instanceof GenericApplicationContext) {
((GenericApplicationContext) context)
.setResourceLoader(this.resourceLoader);
}
if (context instanceof DefaultResourceLoader) {
((DefaultResourceLoader) context)
.setClassLoader(this.resourceLoader.getClassLoader());
}
}
}
如果SpringApplication设置了beanNameGenerator，则将其注册为singleton类型的bean，并命名为：
org.springframework.context.annotation.internalConfigurationBeanNameGenerator
另外，若SpringApplication设置了resourceLoader，则设置进context中。
-
对initialize阶段得到的通过spring.factories注册进来的所有ApplicationContextInitializer，逐个执行其initialize方法来修改context，并在执行之前对其进行校验：
protected void applyInitializers(ConfigurableApplicationContext context) {
for (ApplicationContextInitializer initializer : getInitializers()) {
Class<?> requiredType = GenericTypeResolver.resolveTypeArgument(
initializer.getClass(), ApplicationContextInitializer.class);
Assert.isInstanceOf(requiredType, context, “Unable to call initializer.”);
initializer.initialize(context);
}
}
此处定义了一个扩展点，可以自定义并通过spring.factories注册ApplicationContextInitializer，这些ApplicationContextInitializer可在ApplicationContext准备完毕后对其进行维护修改，例如可以改变其定义的activeProfiles以改变应用环境。
- 执行所有SpringApplicationRunListeners的contextPrepared函数，注意EventPublishingRunListener并没有给所有注册其中的ApplicationListeners发送对应的事件：
listeners.contextPrepared(context);
此时的listeners可以获得context作为参数，从而对context进行修改。
-
将applicationArguments注册进context.getBeanFactory()中，名字为"SpringApplicationArguments"、若printBanner不为空，将printBanner注册到context.getBeanFactory()中，名字为"SpringBootBanner"：
context.getBeanFactory().registerSingleton("springApplicationArguments", applicationArguments); if (printedBanner != null) { context.getBeanFactory().registerSingleton("springBootBanner", printedBanner); } -
得到所有的sources（可通过SpringApplication的run函数、构造函数和setSources函数指定，代表了一个或多个Configuration类），然后执行load(context, sources)函数：
Set<Object> sources = getSources(); Assert.notEmpty(sources, "Sources must not be empty"); load(context, sources.toArray(new Object[sources.size()]));
load函数中会创建一个BeanDefinitionLoader并设置其beanNameGenerator, resourceLoader, environment等属性，然后委托其执行具体的load动作，代码如下：
protected void load(ApplicationContext context, Object[] sources) {
if (logger.isDebugEnabled()) {
logger.debug(
"Loading source " + StringUtils.arrayToCommaDelimitedString(sources));
}
BeanDefinitionLoader loader = createBeanDefinitionLoader(
getBeanDefinitionRegistry(context), sources);
if (this.beanNameGenerator != null) {
loader.setBeanNameGenerator(this.beanNameGenerator);
}
if (this.resourceLoader != null) {
loader.setResourceLoader(this.resourceLoader);
}
if (this.environment != null) {
loader.setEnvironment(this.environment);
}
loader.load();
}
其中对于每一个source根据其类型不同执行不同的load逻辑：class, Resource, Package, CharSequence等。将解析出来的所有bean的BeanDefinition注册到BeanDefinitionRegistry中（注意，只是source本身，并不包括其内部定义的@Bean方法）：
public int load() {
int count = 0;
for (Object source : this.sources) {
count += load(source);
}
return count;
}
private int load(Object source) {
Assert.notNull(source, "Source must not be null");
if (source instanceof Class<?>) {
return load((Class<?>) source);
}
if (source instanceof Resource) {
return load((Resource) source);
}
if (source instanceof Package) {
return load((Package) source);
}
if (source instanceof CharSequence) {
return load((CharSequence) source);
}
throw new IllegalArgumentException("Invalid source type " + source.getClass());
}
由于我们的source是class类，所以load某一个具体source的行为是委托给了AnnotatedBeanDefinitionReader的register方法：
public void register(Class<?>... annotatedClasses) {
for (Class<?> annotatedClass : annotatedClasses) {
registerBean(annotatedClass);
}
}
此处已是spring context的功能了，将通过注释定义的Configuration类的BeanDefinition注册到BeanDefinitionRegistry中。（此时尚不解析Configuration类内部定义的@Bean方法）
- 执行所有SpringApplicationRunListeners的contextLoaded函数，然后EventPublishingRunListener给所有注册其中的ApplicationListeners发送一个“应用上下文准备完毕”ApplicationPreparedEvent事件，另外还将所有注册在自身的ApplicationListener注册到context之中：
listeners.contextLoaded(context);
其中调用到EventPublishingRunListener的contextLoaded函数:
public void contextLoaded(ConfigurableApplicationContext context) {
for (ApplicationListener<?> listener : this.application.getListeners()) {
if (listener instanceof ApplicationContextAware) {
((ApplicationContextAware) listener).setApplicationContext(context);
}
context.addApplicationListener(listener);
}
this.initialMulticaster.multicastEvent(
new ApplicationPreparedEvent(this.application, this.args, context));
}
5 SpringBoot扩展机制
SpringApplication首先提供了一系列的setter方法来进行定制，另外从上面对于SpringBoot启动过程的解读可知，对于SpringBoot有如下几种扩展机制：
5.1 SpringApplicationRunListener
SpringApplicationRunListener是SpringBoot独有的概念，用以在SpringBoot应用启动过程的不同时机接收事件通知并执行相应操作，接口定义如下：
public interface SpringApplicationRunListener {
void starting();
void environmentPrepared(ConfigurableEnvironment environment);
void contextPrepared(ConfigurableApplicationContext context);
void contextLoaded(ConfigurableApplicationContext context);
void finished(ConfigurableApplicationContext context, Throwable exception);
}
SpringBoot框架内置定义了一个EventPublishingRunListener用以将定义在spring.factories中的ApplicationListener管理起来，并在SpringBoot应用启动的不同时机通知它们执行各自的业务逻辑。
我们可以自定义一个实现了EventPublishingRunListener接口的类，例如：
public class MySpringApplicationRunListener implements SpringApplicationRunListener {
Logger logger = LoggerFactory.getLogger(MySpringApplicationRunListener.class);
private final SpringApplication application;
private final String[] args;
public MySpringApplicationRunListener(SpringApplication application, String[] args){
this.application = application;
this.args = args;
}
@Override
public void starting() {
System.out.println("===============starting");
}
@Override
public void environmentPrepared(ConfigurableEnvironment environment) {
environment.setActiveProfiles("Develop");
logger.info("===============environmentPrepared");
}
@Override
public void contextPrepared(ConfigurableApplicationContext context) {
logger.info("===============contextPrepared");
}
@Override
public void contextLoaded(ConfigurableApplicationContext context) {
logger.info("===============contextLoaded");
}
@Override
public void finished(ConfigurableApplicationContext context,
Throwable exception) {
logger.info("===============finished");
}
}
注意：其必须拥有一个SpringApplication类型和String[]类型参数的构造函数：
public MySpringApplicationRunListener(SpringApplication application, String[] args)
另外，SpringBoot启动过程中，LoggingApplicationListener作为一个注册到spring.factories中的ApplicationListener，其在接收到ApplicationEnvironmentPreparedEvent时，才会执行logging system的初始化，因此在starting方法中是没法使用logger打印日志的。
然后在META-INF/spring.factories中添加如下配置：
org.springframework.boot.SpringApplicationRunListener=
springbootext.runlistener.MySpringApplicationRunListener
此时启动应用，可得到如下的输出：
```clike
===============starting
2017-12-31 02:28:39.647 INFO 16329 --- [ main] s.r.MySpringApplicationRunListener : ===============environmentPrepared
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v1.5.8.RELEASE)
2017-12-31 02:28:39.768 INFO 16329 --- [ main] s.r.MySpringApplicationRunListener : ===============contextPrepared
2017-12-31 02:28:39.772 INFO 16329 --- [ main] springbootext.SBApplication : Starting SBApplication on wangd-ThinkPad-T450 with PID 16329 (/home/wangd/work/test/springbootext/target/classes started by wangd in /home/wangd/work/test/springbootext)
2017-12-31 02:28:39.773 INFO 16329 --- [ main] springbootext.SBApplication : The following profiles are active: Develop
2017-12-31 02:28:39.824 INFO 16329 --- [ main] s.r.MySpringApplicationRunListener : ===============contextLoaded
2017-12-31 02:28:39.828 INFO 16329 --- [ main] ationConfigEmbeddedWebApplicationContext : Refreshing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@58a90037: startup date [Sun Dec 31 02:28:39 CST 2017]; root of context hierarchy
2017-12-31 02:28:41.654 INFO 16329 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port(s): 7668 (http)
2017-12-31 02:28:41.672 INFO 16329 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2017-12-31 02:28:41.673 INFO 16329 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet Engine: Apache Tomcat/8.5.23
2017-12-31 02:28:41.802 INFO 16329 --- [ost-startStop-1] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
2017-12-31 02:28:41.802 INFO 16329 --- [ost-startStop-1] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 1978 ms
2017-12-31 02:28:41.980 INFO 16329 --- [ost-startStop-1] o.s.b.w.servlet.ServletRegistrationBean : Mapping servlet: 'dispatcherServlet' to [/]
2017-12-31 02:28:41.985 INFO 16329 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: 'characterEncodingFilter' to: [/*]
2017-12-31 02:28:41.986 INFO 16329 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]
2017-12-31 02:28:41.987 INFO 16329 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: 'httpPutFormContentFilter' to: [/*]
2017-12-31 02:28:41.987 INFO 16329 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: 'requestContextFilter' to: [/*]
2017-12-31 02:28:42.390 INFO 16329 --- [ main] s.w.s.m.m.a.RequestMappingHandlerAdapter : Looking for @ControllerAdvice: org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@58a90037: startup date [Sun Dec 31 02:28:39 CST 2017]; root of context hierarchy
2017-12-31 02:28:42.476 INFO 16329 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/index]}" onto public java.lang.String springbootext.controller.TestController.index()
2017-12-31 02:28:42.482 INFO 16329 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/error],produces=[text/html]}" onto public org.springframework.web.servlet.ModelAndView org.springframework.boot.autoconfigure.web.BasicErrorController.errorHtml(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse)
2017-12-31 02:28:42.483 INFO 16329 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/error]}" onto public org.springframework.http.ResponseEntity<java.util.Map<java.lang.String, java.lang.Object>> org.springframework.boot.autoconfigure.web.BasicErrorController.error(javax.servlet.http.HttpServletRequest)
2017-12-31 02:28:42.526 INFO 16329 --- [ main] o.s.w.s.handler.SimpleUrlHandlerMapping : Mapped URL path [/webjars/**] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
2017-12-31 02:28:42.526 INFO 16329 --- [ main] o.s.w.s.handler.SimpleUrlHandlerMapping : Mapped URL path [/**] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
2017-12-31 02:28:42.581 INFO 16329 --- [ main] o.s.w.s.handler.SimpleUrlHandlerMapping : Mapped URL path [/**/favicon.ico] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
2017-12-31 02:28:42.786 INFO 16329 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup
2017-12-31 02:28:42.852 INFO 16329 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 7668 (http)
2017-12-31 02:28:42.858 INFO 16329 --- [ main] s.r.MySpringApplicationRunListener : ===============finished
2017-12-31 02:28:42.858 INFO 16329 --- [ main] springbootext.SBApplication : Started SBApplication in 3.469 seconds (JVM running for 3.776)
可以看到，在启动过程的不同时机，MySpringApplicationRunListener会执行不同的方法，并得到与当前时机息息相关的参数，因此可以在不同时机执行一些不同的操作。
5.2 ApplicationListener
如5.1所述，SpringBoot框架内置了一个EventPublishingRunListener用以将定义在spring.factories中的ApplicationListener管理起来，并在SpringBoot应用启动的不同时机给他们发送不同的事件。
EventPublishingRunListener内部维护了一个ApplicationEventMulticaster，并将SpringApplication初始化时获得的ApplicationListeners注册进去：
private final ApplicationEventMulticaster initialMulticaster;
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);
}
}
然后在SpringBoot执行的不同时机被调用不同方法时，将通知封装成不同类型的ApplicationEvent并广播给注册的ApplicationListener：
@Override
public void started() {
this.initialMulticaster.multicastEvent(new ApplicationStartedEvent(
this.application, this.args));
}
@Override
public void environmentPrepared(ConfigurableEnvironment environment) {
this.initialMulticaster.multicastEvent(new ApplicationEnvironmentPreparedEvent(
this.application, this.args, environment));
}
@Override
public void contextPrepared(ConfigurableApplicationContext context) {
}
@Override
public void contextLoaded(ConfigurableApplicationContext context) {
for (ApplicationListener<?> listener : this.application.getListeners()) {
if (listener instanceof ApplicationContextAware) {
((ApplicationContextAware) listener).setApplicationContext(context);
}
context.addApplicationListener(listener);
}
this.initialMulticaster.multicastEvent(new ApplicationPreparedEvent(
this.application, this.args, context));
}
@Override
public void finished(ConfigurableApplicationContext context, Throwable exception) {
// Listeners have been registered to the application context so we should
// use it at this point
context.publishEvent(getFinishedEvent(context, exception));
}
注意：contextLoaded通知发出时，EventPublishingRunListener会将SpringApplication中的ApplicationListeners统统注册到context中。而在finished通知发出时，直接通知的是context中的所有ApplicationListeners。
我们也可以自定义一个实现了ApplicationListener接口的类，然后通过
springApplication.addListeners(new MyApplicationListener());
或者在spring.factories中添加：
org.springframework.context.ApplicationListener=\
springbootext.listener.MyApplicationListener
来将其注册进EventPublishingRunListener中，参与SpringBoot启动过程生命周期。
5.3 ApplicationContextInitializer
ApplicationContextInitializer是Spring context原有的概念，其目的就是在ApplicationContext准备好之后且refresh之前执行，可以对ApplicationContext做进一步的维护。其执行时机是在SpringApplication run阶段的prepareContext时期调用applyInitializers函数来实现的，代码如下：
protected void applyInitializers(ConfigurableApplicationContext context) {
for (ApplicationContextInitializer initializer : getInitializers()) {
Class<?> requiredType = GenericTypeResolver.resolveTypeArgument(
initializer.getClass(), ApplicationContextInitializer.class);
Assert.isInstanceOf(requiredType, context, "Unable to call initializer.");
initializer.initialize(context);
}
}
其中getInitializers()得到的就是在initialize阶段借助SpringFactoriesLoader工具来获取的所有initializers，详情请翻阅4.1小节。
我们也可以自定义一个实现了ApplicationContextInitializer接口的类，然后通过
springApplication.addInitializers(new MyInitializer());
或者在spring.factories中添加：
org.springframework.context.ApplicationContextInitializer=\
springbootext.initializer.MyInitializer
来将其注册进SpringBoot的启动流程中。
5.4 CommandLineRunner和ApplicationRunner
这两个runner如此相似，就将他们放在一起说明了。CommandLineRunner和ApplicationRunner接口是在容器启动成功后的最后一步回调，可以认为是挂载了一些开机自启动程序。其执行时机在run的afterRefresh阶段：
protected void afterRefresh(ConfigurableApplicationContext context,
ApplicationArguments args) {
callRunners(context, args);
}
private void callRunners(ApplicationContext context, ApplicationArguments args) {
List<Object> runners = new ArrayList<Object>();
runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());
runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());
AnnotationAwareOrderComparator.sort(runners);
for (Object runner : new LinkedHashSet<Object>(runners)) {
if (runner instanceof ApplicationRunner) {
callRunner((ApplicationRunner) runner, args);
}
if (runner instanceof CommandLineRunner) {
callRunner((CommandLineRunner) runner, args);
}
}
}
这些runner无法感知applicationContext或者是environment等，只能获得启动应用时候的命令行参数。
由于其执行时机是在applicationContext的refresh完成以后，因此其获取是通过applicationContext.getBeansOfType来得到的，也就是说所有注册在applicationContext（也就是其中的beanFactory）中的CommandLineRunner或ApplicationRunner类型的bean都会被执行。
所以我们可以通过在Configuration类中定义@Bean方法将自定义的Runner注册进来。
两者的执行时机是完全一样的，唯一的区别在于一个接受ApplicationArguments，一个接受String[]类型的原始命令行参数。而ApplicationArguments也只是对原始命令行参数的一个封装，因此本质上是一样的。
6 spring-boot-starter实现原理
SpringBoot中的starter是一种非常重要的机制，能够抛弃以前繁杂的配置，将其统一集成进starter，应用者只需要引入starter jar包，SpringBoot就能自动扫描到要加载的信息并启动相应的默认配置。
starter让我们摆脱了各种依赖库的处理，需要配置各种信息的困扰。SpringBoot会自动通过classpath路径下的类发现需要的Bean，并注册进IOC容器。
SpringBoot提供了针对日常企业应用研发各种场景的spring-boot-starter依赖模块。所有这些依赖模块都遵循着约定成俗的默认配置，并允许我们调整这些配置，即遵循“约定大于配置”的理念。SpringBoot提供的starter包括了：
spring-boot-starter
spring-boot-starter-logging
spring-boot-starter-web
spring-boot-starter-jdbc
spring-boot-starter-aop
spring-boot-starter-secutiry
…
等等，有数十个之多。由于这是一篇介绍实现原理而非介绍使用教程的文章，因此不会过多的介绍各个starter的具体功能或用法，想查看具体教程的同学请参考https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples。
下面通过一个最常用的web应用场景使用的spring-boot-starter-web来介绍一下starter到底干了什么，以及是如何干的；然后自定义一个starter。
6.1 spring-boot-starter-web详解
打开spring-boot-starter-web-1.5.8.RELEASE.jar看一下，发现结构如下：
其中META-INF中并没有定义spring.factories文件，回顾前面介绍的@EnableAutoConfiguration注释的功能，其实这些SpringBoot官方提供的starter的配置类是在spring-boot-autoconfigure模块中注册的，而starter本身只通过pom.xml来定义其依赖的类库，因此其中唯一起作用的就是pom.xml，spring-boot-starter-web相应的pom.xml内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starters</artifactId>
<version>1.5.8.RELEASE</version>
</parent>
<artifactId>spring-boot-starter-web</artifactId>
<name>Spring Boot Web Starter</name>
<description>Starter for building web, including RESTful, applications using Spring
MVC. Uses Tomcat as the default embedded container</description>
<url>http://projects.spring.io/spring-boot/</url>
<organization>
<name>Pivotal Software, Inc.</name>
<url>http://www.spring.io</url>
</organization>
<properties>
<main.basedir>${basedir}/../..</main.basedir>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
</dependency>
</dependencies>
</project>
里面定义了一个web应用需要依赖的类库，其中通过spring-boot-starters来管理具体的版本，这些版本经过了精心挑选配置，可以认为是经过了充分测试可避免冲突的。
从上可得，这些starters只是定义了各个场景需要依赖的jar包，而真正做自动化配置的代码的是在spring-boot-autoconfigure里面。SpringBoot会基于你的classpath中的jar包，试图猜测和配置您可能需要的bean。
我们通过在前面介绍的spring-boot-autoconfig包中定义的META-INF/spring.factories中可看到，与web相关的自动配置类有：
org.springframework.boot.autoconfigure.web.DispatcherServletAutoConfiguration,\
org.springframework.boot.autoconfigure.web.EmbeddedServletContainerAutoConfiguration,\
org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration,\
org.springframework.boot.autoconfigure.web.HttpEncodingAutoConfiguration,\
org.springframework.boot.autoconfigure.web.HttpMessageConvertersAutoConfiguration,\
org.springframework.boot.autoconfigure.web.MultipartAutoConfiguration,\
org.springframework.boot.autoconfigure.web.ServerPropertiesAutoConfiguration,\
org.springframework.boot.autoconfigure.web.WebClientAutoConfiguration,\
org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration,\
其中WebMvcAutoConfiguration就是对于web应用环境的自动配置主类，其注释信息如下：
@Configuration
@ConditionalOnWebApplication
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class,
WebMvcConfigurerAdapter.class })
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE + 10)
@AutoConfigureAfter(DispatcherServletAutoConfiguration.class)
public class WebMvcAutoConfiguration{
...............
}
内部注册了一系列必要的ViewResolver、Converter、Formatter、Filter等等。
其中@AutoConfigureAfter代表需要在DispatcherServletAutoConfiguration之后加载，因此，在此之前需要先加载DispatcherServletAutoConfiguration，其注释信息如下：
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@Configuration
@ConditionalOnWebApplication
@ConditionalOnClass(DispatcherServlet.class)
@AutoConfigureAfter(EmbeddedServletContainerAutoConfiguration.class)
public class DispatcherServletAutoConfiguration {
......
}
DispatcherServletAutoConfiguration内部通过@EnableConfigurationProperties/@ConfigurationProperties机制使用属性设置DispatcherServlet并注册进IOC容器，然后注册一个ServletRegistrationBean到IOC容器。DispatcherServlet是springframework中web模块的概念，是http请求分发路由的核心枢纽。ServletRegistrationBean是SpringBoot中用来在Servlet容器中注册servlet用的，其作用类似于ServletContext.addServlet(String, Servlet)，但是用了更加友好的Spring bean配置注册方式。
在该类的注释中同样使用@AutoConfigureAfter来指示加载本类之前先加载EmbeddedServletContainerAutoConfiguration配置类，其代码如下：
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@Configuration
@ConditionalOnWebApplication
@Import(BeanPostProcessorsRegistrar.class)
public class EmbeddedServletContainerAutoConfiguration {
.........
}
EmbeddedServletContainerAutoConfiguration首先判断是否web应用，若是才会继续。其作用是根据不同的条件（通过判断拥有哪些类来判断引入了哪个包）注册EmbeddedServletContainerCustomizer的具体实现（例如：TomcatEmbeddedServletContainerFactory和JettyEmbeddedServletContainerFactory等），然后通过Import机制为beanFactory注册embeddedServletContainerCustomizerBeanPostProcessor和errorPageRegistrarBeanPostProcessor这两个BeanDefinition。
这两个BeanPostProcessor会在EmbeddedServletContainerCustomizer类型的bean被实例化之后、初始化之前以后对其进行进一步的操作。
EmbeddedServletContainerCustomizerBeanPostProcessor会利用已注册在beanFactory中的EmbeddedServletContainerCustomizers来对ConfigurableEmbeddedServletContainer进行定制：
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName)
throws BeansException {
if (bean instanceof ConfigurableEmbeddedServletContainer) {
postProcessBeforeInitialization((ConfigurableEmbeddedServletContainer) bean);
}
return bean;
}
private void postProcessBeforeInitialization(
ConfigurableEmbeddedServletContainer bean) {
for (EmbeddedServletContainerCustomizer customizer : getCustomizers()) {
customizer.customize(bean);
}
}
例如其中有一个名为ServerProperties的customizer，其本身通过标注@ConfigurationProperties(prefix = “server”, ignoreUnknownFields = true)来将自身属性设置为以server.开头配置的属性，然后其customize函数代码如下：
public void customize(ConfigurableEmbeddedServletContainer container) {
if (getPort() != null) {
container.setPort(getPort());
}
if (getAddress() != null) {
container.setAddress(getAddress());
}
if (getContextPath() != null) {
container.setContextPath(getContextPath());
}
if (getDisplayName() != null) {
container.setDisplayName(getDisplayName());
}
if (getSession().getTimeout() != null) {
container.setSessionTimeout(getSession().getTimeout());
}
container.setPersistSession(getSession().isPersistent());
container.setSessionStoreDir(getSession().getStoreDir());
if (getSsl() != null) {
container.setSsl(getSsl());
}
if (getJspServlet() != null) {
container.setJspServlet(getJspServlet());
}
if (getCompression() != null) {
container.setCompression(getCompression());
}
container.setServerHeader(getServerHeader());
if (container instanceof TomcatEmbeddedServletContainerFactory) {
getTomcat().customizeTomcat(this,
(TomcatEmbeddedServletContainerFactory) container);
}
if (container instanceof JettyEmbeddedServletContainerFactory) {
getJetty().customizeJetty(this,
(JettyEmbeddedServletContainerFactory) container);
}
if (container instanceof UndertowEmbeddedServletContainerFactory) {
getUndertow().customizeUndertow(this,
(UndertowEmbeddedServletContainerFactory) container);
}
container.addInitializers(new SessionConfiguringInitializer(this.session));
container.addInitializers(new InitParameterConfiguringServletContextInitializer(
getContextParameters()));
}
也就是说，该customizer负责将配置的属性设置进container中。
errorPageRegistrarBeanPostProcessor会利用已注册在beanFactory中的ErrorPageRegistrar来对ConfigurableEmbeddedServletContainer进行定制：
private void postProcessBeforeInitialization(ErrorPageRegistry registry) {
for (ErrorPageRegistrar registrar : getRegistrars()) {
registrar.registerErrorPages(registry);
}
}
默认注册了一个ErrorPageCustomizer，使用属性中的servletPath与error.path一起构建一个ErrorPage并注册到ConfigurableEmbeddedServletContainer中：
public void registerErrorPages(ErrorPageRegistry errorPageRegistry) {
ErrorPage errorPage = new ErrorPage(this.properties.getServletPrefix()
+ this.properties.getError().getPath());
errorPageRegistry.addErrorPages(errorPage);
}
除此之外还有：
org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration,
org.springframework.boot.autoconfigure.web.HttpEncodingAutoConfiguration,
org.springframework.boot.autoconfigure.web.HttpMessageConvertersAutoConfiguration,
org.springframework.boot.autoconfigure.web.MultipartAutoConfiguration,
org.springframework.boot.autoconfigure.web.ServerPropertiesAutoConfiguration,
org.springframework.boot.autoconfigure.web.WebClientAutoConfiguration,\
等等，它们都在一定条件下起作用，并各自实现特定的配置。
当我们引入spring-boot-starter-web时，上面的启动条件会满足，因此这些配置类都会被加载生效。于是对于一个web应用，默认就配置完成了。
6.2 自定义starter
SpringBoot官方提供的starter提供了两层有价值的信息：所需依赖的jar包相互之间使用不产生冲突的版本；在spring-boot-autoconfiguration库中提供了对其进行默认配置的配置类并利用Spring框架的扩展协议实现注册。
因此，当我们想要自定义一个starter，以实现一旦在pom.xml中引入该starter就能自动工作的效果时，我们需要确保两件事：
仔细确定依赖的各个库的jar包的版本，保证它们之间不会产生冲突，或无法合作。
提供对所需机制的Configuration类，以实现将需要的功能注入IOC容器。
并通过SpringBoot的扩展机制确保引入自定义starter的jar包时Configuration类被加载。
具体需要完成以下几步：
- 编写pom.xml在其中定义我们的场景需要依赖的jar包，并仔细选择其版本
- 项目中编写@Configuration配置类以将必要的功能注册进IOC容器
- 在META-INF/spring.factories中添加
org.springframework.boot.autoconfigure.EnableAutoConfiguration=
mypackage1.MyConfiguration1,
mypackage2.MyConfiguration2,
…
来应用Spring的内部扩展机制注册Configuration类。
4. 打包成jar文件以供使用。
如此一来，每当该starter jar包被引入时，SpringBoot的@EnableAutoConfiguration注释便会借助SpringFactoriesLoader将我们配置的Configuration类加载，并对其进行解析，我们的starter就可以工作起来了。
7 自动配置机制实现原理
7.1 SpringFactoriesLoader
SpringFactoriesLoader是SpringFramework内部使用的通用的工厂加载机制，其可加载并实例化可能出现在classpath上的多个jar包中的META-INF/spring.factories文件中定义的指定类型的工厂。
factories文件必须使用Properties格式，也就是多行key=value组成的格式。其中key是指定工厂的抽象类或接口的全限定名，value是用逗号隔开的key指定工厂的具体实现类的全限定名。例如：
example.MyService=example.MyServiceImpl1,example.MyServiceImpl2
其中example.MyService是接口的全限定名，而MyServiceImpl1和MyServiceImpl2是其实现类。
这样配置完后，我们就可以使用SpringFactoriesLoader.loadFactories(Myservice.class, null)来获得MyServiceImpl1和MyServiceImpl2的实例。后续如何处理MyServiceImpl1和MyServiceImpl1，就看各个扩展机制的实际业务逻辑了。
7.2 EnableAutoConfiguration
EnableAutoConfiguration是SpringBoot利用SpringFactoriesLoader扩展机制来实现的一种自动配置机制。
EnableAutoConfiguration注释包含两层功能：第一是作为注释，通过Import机制实现标注在类上以表示开启自动配置机制。第二是作为SpringBoot的autoconfiguration模块利用SpringFactoriesLoader扩展的“工厂类”。
在autoconfiguration模块的META-INF/spring.factories中定义了：
Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\
org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,\
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration,\
org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration,\
org.springframework.boot.autoconfigure.cloud.CloudAutoConfiguration,\
.......
这些配置，在启动时通过启动类上标注的@EnableAutoConfiguration注释中Import的AutoConfigurationImportSelector，来委托SpringFactoriesLoader加载进IOC容器，并在满足各自配置的@Condition条件时生效。
8 属性配置说明
8.1 SpringBoot属性配置顺序
Spring Boot支持多种外部属性源配置方式，并使用非常特别的属性源优先级顺序：
- 命令行参数
- 来自java:comp/env的JNDI属性
- Java系统属性（System.getProperties()）
- 操作系统环境变量
- RandomValuePropertySource配置的random.*属性值
- jar包外部的application-{profile}.properties或application.yml(带spring.profile)配置文件
- jar包内部的application-{profile}.properties或application.yml(带spring.profile)配置文件
- jar包外部的application.properties或application.yml(不带sprin.profile)配置文件
- jar包内部的application.properties或application.yml(不带spring.profile)配置文件
- @Configuration注解类上的@PropertySource
- 通过SpringApplication.setDefaultProperties指定的默认属性
具体使用说明，请参照文档https://docs.spring.io/spring-boot/docs/1.2.3.RELEASE/reference/html/boot-features-external-config.html。
8.2 属性值配置/获取方式
SpringBoot为我们提供的获得属性值的方式有以下几种，其中有Springframework本身就提供了的，也有SpringBoot自己扩展出来的方式：
-
environment.getProperty(String key)
任何我们可以获得Environment对象的地方，都可以直接使用这个函数来获得key所定义的属性值。key是类似home.me.name或server.port等等这样的字符串，例如：environment.getProperty(“home.me.name”);
environment.getProperty(“server.port”); -
environment.resolvePlaceholders(String placeholder)
同上，能获得environment对象的地方，都可以使用该函数。所不同的是，其参数为placeholder，也就是 h o m e . m e . n a m e 或 {home.me.name}或 home.me.name或{server.port}并且支持嵌套表达，例如：environment.resolverPlaceholders(" h o m e . m e . n a m e " ) ; e n v i r o n m e n t . r e s o l v e r P l a c e h o l d e r s ( " {home.me.name}"); environment.resolverPlaceholders(" home.me.name");environment.resolverPlaceholders("{home.me.${test.name}}");
-
@Value
当我们在一个Bean中的某属性上定义@Value(“home.me.name”)时，IOC容器在创建这个Bean的时候就会将对应的属性值注入（Inject）进去，例如：@Component
public class SBConfiguration {
@Value("${home.me.name:hello}")
String name;
…
} -
@ConfigurationProperties(“home.me”)
当我们在一个配置类上标注@ConfigurationProperties时，IOC容器会在创建这个配置类时自动为其注入其字段对应的属性（若存在的话）。这是SpringBoot新引入的获取机制。@Configuration
@ConfigurationProperties(“home.me”)
public class SBConfiguration {
String name;
…
}
所有这些获取方式都最终都会将实际的属性获取行为委托给spring-core模块中的PropertySourcesPropertyResolver：
protected <T> T getProperty(String key, Class<T> targetValueType, boolean resolveNestedPlaceholders) {
if (this.propertySources != null) {
for (PropertySource<?> propertySource : this.propertySources) {
if (logger.isTraceEnabled()) {
logger.trace("Searching for key '" + key + "' in PropertySource '" +
propertySource.getName() + "'");
}
Object value = propertySource.getProperty(key);
if (value != null) {
if (resolveNestedPlaceholders && value instanceof String) {
value = resolveNestedPlaceholders((String) value);
}
logKeyFound(key, propertySource, value);
return convertValueIfNecessary(value, targetValueType);
}
}
}
if (logger.isDebugEnabled()) {
logger.debug("Could not find key '" + key + "' in any property source");
}
return null;
}
其中的this.propertySources是从environment中获取过来的。上述代码的意思就是遍历environment中预定义的propertySources，查找属性key对应的值，如有需要递归处理嵌套属性，一旦得到非空的属性值，就返回。因此对于多个propertySources来源而言，排在前面的优先级就高过排在后面的优先级。
8.3 属性源注册顺序
从8.2属性获取及绑定过程可知，属性源优先级顺序其实就取决于属性源在environment中注册完毕后的最终顺序，SpringBoot在启动阶段控制这这个属性源的加载及排序，我们跟踪一下启动过程：
- 由于我们配置的是web应用，因此初始化的environment类型是StandardServletEnvironment。在StandardServletEnvironment初始化的时候，会执行：
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);
}
StandardServletEnvironment的父类是StandardEnvironment，其customizePropertySources方法代码如下：
protected void customizePropertySources(MutablePropertySources propertySources) {
propertySources.addLast(new MapPropertySource(SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME, getSystemProperties()));
propertySources.addLast(new SystemEnvironmentPropertySource(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME,
getSystemEnvironment()));
}
此时propertySources的顺序为：
servletConfigInitParams
servletContextInitParams
jndiProperties
systemProperties
systemEnvironment
- 然后在configEnvironment阶段：
protected void configureEnvironment(ConfigurableEnvironment environment,
String[] args) {
configurePropertySources(environment, args);
configureProfiles(environment, args);
}
其中configurePropertySources用于配置propertySources，为environment增加defaultProperties和commandLineArgs：
protected void configurePropertySources(ConfigurableEnvironment environment,
String[] args) {
MutablePropertySources sources = environment.getPropertySources();
if (this.defaultProperties != null && !this.defaultProperties.isEmpty()) {
sources.addLast(
new MapPropertySource("defaultProperties", this.defaultProperties));
}
if (this.addCommandLineProperties && args.length > 0) {
String name = CommandLinePropertySource.COMMAND_LINE_PROPERTY_SOURCE_NAME;
if (sources.contains(name)) {
PropertySource<?> source = sources.get(name);
CompositePropertySource composite = new CompositePropertySource(name);
composite.addPropertySource(new SimpleCommandLinePropertySource(
name + "-" + args.hashCode(), args));
composite.addPropertySource(source);
sources.replace(name, composite);
}
else {
sources.addFirst(new SimpleCommandLinePropertySource(args));
}
}
}
区别是defaultProperties加到末尾，而commandLineArgs添加到第一个。此时propertySources的顺序如下：
commandLineArgs
servletConfigInitParams
servletContextInitParams
jndiProperties
systemProperties
systemEnvironment
defaultProperties
- 在发出environmentPrepared事件后，ConfigFileApplicationListener执行回调函数：
public void postProcessEnvironment(ConfigurableEnvironment environment,
SpringApplication application) {
addPropertySources(environment, application.getResourceLoader());
configureIgnoreBeanInfo(environment);
bindToSpringApplication(environment, application);
}
其中addPropertySources方法首先将RandomValuePropertySource（名为random）注册进environment：
protected void addPropertySources(ConfigurableEnvironment environment,
ResourceLoader resourceLoader) {
RandomValuePropertySource.addToEnvironment(environment);
new Loader(environment, resourceLoader).load();
}
RandomValuePropertySource加载的位置如下：
public static void addToEnvironment(ConfigurableEnvironment environment) {
environment.getPropertySources().addAfter(
StandardEnvironment.SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME,
new RandomValuePropertySource(RANDOM_PROPERTY_SOURCE_NAME));
logger.trace("RandomValuePropertySource add to Environment");
}
可看到是加在systemEnvironment之后。
然后委托Loader来搜索searchLocations路径上的可用的配置文件。默认搜索顺序是file:./config/, file:./, classpath:/config/, classpath:./。我们可以通过设置"spring.config.location"来修改默认搜索路径。
结合environment当前设置的profile，在上述路径中查询特定文件名（默认为"application"，可通过设置"spring.config.name"来指定）和特定后缀（properties, xml, yml, yaml）的文件。将所有符合条件的文件封装为不同类型的PropertySource（例如PropertiesPropertySource）。最终将这些PropertySources封装成一个ConfigurationPropertySources（名为：applicationConfigurationProperties）然后添加在如下位置：
private void addConfigurationProperties(
ConfigurationPropertySources configurationSources) {
MutablePropertySources existingSources = this.environment
.getPropertySources();
if (existingSources.contains(DEFAULT_PROPERTIES)) {
existingSources.addBefore(DEFAULT_PROPERTIES, configurationSources);
}
else {
existingSources.addLast(configurationSources);
}
}
如果存在defaultProperties，则将该applicationConfigurationProperties添加到defaultProperties之前；否则添加到existingSources的最末尾。如此一来，propertySources的顺序如下：
commandLineArgs
servletConfigInitParams
servletContextInitParams
jndiProperties
systemProperties
systemEnvironment
random
applicationConfigurationProperties
defaultProperties
-
随后，在context.refresh阶段的invokeBeanFactoryPostProcessors(beanFactory)子阶段，会执行到ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry函数。其中委托ConfigurationClassParser来解析已经注册到beanDefinitionFactory中的@Configuration类，其中调用到doProcessConfigurationClass方法来获得配置在@Configuration类上的propertySource：
for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), PropertySources.class,
org.springframework.context.annotation.PropertySource.class)) {
if (this.environment instanceof ConfigurableEnvironment) {
processPropertySource(propertySource);
}
else {
logger.warn(“Ignoring @PropertySource annotation on [” + sourceClass.getMetadata().getClassName() +
“]. Reason: Environment must implement ConfigurableEnvironment”);
}
}
针对每一个打了PropertySource注释的配置类，执行processPropertySource方法，代码如下：
private void processPropertySource(AnnotationAttributes propertySource) throws IOException {
String name = propertySource.getString("name");
if (!StringUtils.hasLength(name)) {
name = null;
}
String encoding = propertySource.getString("encoding");
if (!StringUtils.hasLength(encoding)) {
encoding = null;
}
String[] locations = propertySource.getStringArray("value");
Assert.isTrue(locations.length > 0, "At least one @PropertySource(value) location is required");
boolean ignoreResourceNotFound = propertySource.getBoolean("ignoreResourceNotFound");
Class<? extends PropertySourceFactory> factoryClass = propertySource.getClass("factory");
PropertySourceFactory factory = (factoryClass == PropertySourceFactory.class ?
DEFAULT_PROPERTY_SOURCE_FACTORY : BeanUtils.instantiateClass(factoryClass));
for (String location : locations) {
try {
String resolvedLocation = this.environment.resolveRequiredPlaceholders(location);
Resource resource = this.resourceLoader.getResource(resolvedLocation);
addPropertySource(factory.createPropertySource(name, new EncodedResource(resource, encoding)));
}
catch (IllegalArgumentException ex) {
// Placeholders not resolvable
if (ignoreResourceNotFound) {
if (logger.isInfoEnabled()) {
logger.info("Properties location [" + location + "] not resolvable: " + ex.getMessage());
}
}
else {
throw ex;
}
}
catch (IOException ex) {
// Resource not found when trying to open it
if (ignoreResourceNotFound &&
(ex instanceof FileNotFoundException || ex instanceof UnknownHostException)) {
if (logger.isInfoEnabled()) {
logger.info("Properties location [" + location + "] not resolvable: " + ex.getMessage());
}
}
else {
throw ex;
}
}
}
}
其功能是获得PropertySource注释的value属性定义的逗号分割的多个locations，为每一个都创建ResourcePropertySource并对其执行addPropertySource方法：
private void addPropertySource(PropertySource<?> propertySource) {
String name = propertySource.getName();
MutablePropertySources propertySources = ((ConfigurableEnvironment) this.environment).getPropertySources();
if (propertySources.contains(name) && this.propertySourceNames.contains(name)) {
// We've already added a version, we need to extend it
PropertySource<?> existing = propertySources.get(name);
PropertySource<?> newSource = (propertySource instanceof ResourcePropertySource ?
((ResourcePropertySource) propertySource).withResourceName() : propertySource);
if (existing instanceof CompositePropertySource) {
((CompositePropertySource) existing).addFirstPropertySource(newSource);
}
else {
if (existing instanceof ResourcePropertySource) {
existing = ((ResourcePropertySource) existing).withResourceName();
}
CompositePropertySource composite = new CompositePropertySource(name);
composite.addPropertySource(newSource);
composite.addPropertySource(existing);
propertySources.replace(name, composite);
}
}
else {
if (this.propertySourceNames.isEmpty()) {
propertySources.addLast(propertySource);
}
else {
String firstProcessed = this.propertySourceNames.get(this.propertySourceNames.size() - 1);
propertySources.addBefore(firstProcessed, propertySource);
}
}
this.propertySourceNames.add(name);
}
addPropertySource函数主要用来确定ResourcePropertySource的添加次序：
如果propertySources已经添加了相同名称的propertySource并且本实例维护的propertySourceNames包含本名称，则说明已经注册过一个相同名称的用@PropertySource标注的属性源，因此需要对已有的属性源进行扩展。将新增加的propertySource插入进去。
否则，如果本实例维护的propertySourceNames为空，说明在此之前并没有注册任何通过@PropertySource标注的属性源，则将该属性源添加到propertySources的最后，也就是优先级最低的位置。
若本实例维护的propertySourceNames不为空，则说明在此之前已经注册过通过@PropertySource标注的属性源，则将本属性源添加到上一次添加的属性源之前。
添加完以后顺序如下：
commandLineArgs
servletConfigInitParams
servletContextInitParams
jndiProperties
systemProperties
systemEnvironment
random
applicationConfigurationProperties
defaultProperties
ResourcePropertySource(若干个)
-
跟着会由PropertySourceOrderingPostProcessor执行postProcessBeanFactory：
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)
throws BeansException {
reorderSources(this.context.getEnvironment());
}
其中对context.getEnvironment()中的propertySources进行重新排序：
private void reorderSources(ConfigurableEnvironment environment) {
ConfigurationPropertySources
.finishAndRelocate(environment.getPropertySources());
PropertySource<?> defaultProperties = environment.getPropertySources()
.remove(DEFAULT_PROPERTIES);
if (defaultProperties != null) {
environment.getPropertySources().addLast(defaultProperties);
}
}
finishAndRelocate函数中将名为"applicationConfigurationProperties"的ConfigurationPropertySources在原位置展开：原来将路径上的多个配置文件生成的propertySource集成成一个ConfigurationPropertySources，现在将其展开成不同的PropertySource。
然后将"defaultProperties"删除，如果"defaultProperties"不为空，那么就将其添加到队列的最后，也就是优先级最低的地方。重新排序后最终propertySources的顺序如下：
commandLineArgs
servletConfigInitParams
servletContextInitParams
jndiProperties
systemProperties
systemEnvironment
random
PropertiesPropertySource(若干)
ResourcePropertySource(若干)
defaultProperties
经过上述的整个过程以后，environment中参数源列表（propertySources）的排序与前面文档中提到的顺序就完全一致了。
小结：SpringBoot使得开发Spring应用不再那么繁琐和冗长，由于其快速开发、约定大于配置的自动配置模块、可执行jar包部署等等特点，随着微服务的流行变得越来越重要。本文详细介绍了SpringBoot框架的内部实现原理，通过源码分析了解了其自动配置、扩展机制、参数获取顺序等等核心机制。在实际使用SpringBoot框架开发时，对于各种功能知其然更应知其所以然，才能做到游刃有余。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
