SpringBoot工作机制概述

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

在其中添加如下依赖：

    org.springframework.boot
    spring-boot-starter-web

编写项目的启动类

@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 configurations = getCandidateConfigurations(annotationMetadata,
					attributes);
			configurations = removeDuplicates(configurations);
			configurations = sort(configurations, autoConfigurationMetadata);
			Set 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 getCandidateConfigurations(AnnotationMetadata metadata,
			AnnotationAttributes attributes) {
		List 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 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  Collection getSpringFactoriesInstances(Class type,
		Class[] parameterTypes, Object... args) {
	ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
	// Use names and ensure unique to protect against duplicates
	Set names = new LinkedHashSet(
			SpringFactoriesLoader.loadFactoryNames(type, classLoader));
	List 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应用启动流程模板化，并在启动过程的不同时机定义了一系列不同类型的的扩展点，方便我们对其进行定制。下面对整个启动过程代码进行分析：

1. 通过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。

2. 将参数包装为ApplicationArguments，DefaultApplicationArguments是用来维护命令行参数的，例如可以方便的将命令行参数中的options和non options区分开，以及获得某option的值等。

	ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);

3. 通过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进行一些额外的处理。

4. 根据前面判断的是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的介绍中深入讨论。

5. 借助SpringFactoriesLoader获得spring.factories中注册的FailureAnalyzers以供当运行过程中出现异常时进行分析：

	analyzers = new FailureAnalyzers(context);

其中又用到了SpringFactoriesLoader扩展方案：

	List analyzerNames = SpringFactoriesLoader
			.loadFactoryNames(FailureAnalyzer.class, classLoader);

6. 接着就是SpringBoot启动过程中的最核心流程，对第4步创建的ApplicationContext进行准备：

	prepareContext(context, environment, listeners, applicationArguments, printedBanner);

此处就不展开了，在下一节专门对这个函数进行分析。

7. 调用ApplicationContext的refresh函数，开启spring context的核心流程，就是根据配置加载bean（spring beans核心功能）以及在各个时机开放的不同扩展机制（spring context）：

	refreshContext(context);

这个过程在此不展开了，后续会写关于spring context的文章专门介绍。

8. 获取所有的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