SpringBoot源码解析-内嵌Tomcat
一、Servlet容器的使用
Spring Boot默认支持Tomcat，Jetty，和Undertow作为底层容器。
而Spring Boot默认使用Tomcat，一旦引入spring-boot-starter-web模块，就默认使用Tomcat容器。
org.springframework.boot
spring-boot-starter-web
1.1 默认servlet容器
我们看看spring-boot-starter-web这个starter中有什么
核心就是引入了tomcat和SpringMvc
1.2 切换servlet容器
那如果我们想切换其他Servlet容器呢，只需如下两步：
将tomcat依赖移除掉
引入其他Servlet容器依赖
引入jetty：
org.springframework.boot
spring-boot-starter-web
spring-boot-starter-tomcat
org.springframework.boot
org.springframework.boot
spring-boot-starter-jetty
二、内嵌Tomcat自动配置原理
在启动springboot的时候可谓是相当简单，只需要执行以下代码
public static void main(String[] args) {
SpringApplication.run(SpringBootMytestApplication.class, args);
}那些看似简单的事物，其实并不简单。我们之所以觉得他简单，是因为复杂性都被隐藏了。通过上述代码，大概的可以提出以下几个疑问
1.SpringBoot是如何启动内置tomcat的
2.SpringBoot为什么可以响应请求，他是如何配置的SpringMvc
2.1 SpringBoot启动内置tomcat流程
1、进入SpringBoot启动类，点进@SpringBootApplication源码，如下图
2、继续点进@EnableAutoConfiguration,进入该注解，如下图
3、使用@Import注解对AutoConfigurationImportSelector 类进行了引入
上图中使用@Import注解对AutoConfigurationImportSelector 类进行了引入，该类做了什么事情呢？
进入源码，首先调用selectImport()方法，在该方法中调用了getAutoConfigurationEntry()方法，在之中又调用了getCandidateConfigurations()方法，
getCandidateConfigurations()方法就去META-INF/spring.factory配置文件中加载相关配置类
这个spring.factories配置文件是加载的spring-boot-autoconfigure的配置文件
继续打开spring.factories配置文件，找到tomcat所在的类，tomcat加载在ServletWebServerFactoryAutoConfiguration配置类中
进入该类，里面也通过@Import注解将EmbeddedTomcat、EmbeddedJetty、EmbeddedUndertow等嵌入式容器类加载进来了，springboot默认是启动嵌入式tomcat容器，
如果要改变启动jetty或者undertow容器，需在pom文件中去设置。如下图：
继续进入EmbeddedTomcat类中，见下图：
进入TomcatServletWebServerFactory类，里面的getWebServer（）是关键方法，如图：
继续进入getTomcatWebServer()等方法，一直往下跟到tomcat初始化方法，调用tomcat.start()方法，tomcat就正式开启运行，见图
走到这里tomcat在springboot中的配置以及最终启动的流程就走完了，相信大家肯定有一个疑问，上上图中的getWebServer()方法是在哪里调用的呢？
上面的代码流程并没有发现getWebServer()被调用的地方。
因为getWebServer()方法的调用根本就不在上面的代码流程中，它是在另外一个流程中被调用的
2.2 getWebServer()的调用分析
首先进入SpringBoot启动类的run方法：
这个会最终调用到一个同名方法run(String… args)
/**
* 启动过程中的重要步骤共分为六步
* 第一步：获取并启动监听器
* 第二步：构造应用上下文环境
* 第三步：初始化应用上下文
* 第四步：刷新应用上下文前的准备阶段
* 第五步：刷新应用上下文
* 第六步：刷新应用上下文后的扩展接口
*
* Run the Spring application, creating and refreshing a new
* {@link ApplicationContext}.
* @param args the application arguments (usually passed from a Java main method)
* @return a running {@link ApplicationContext}
*
* 运行spring应用，并刷新一个新的 ApplicationContext（Spring的上下文）
* ConfigurableApplicationContext 是 ApplicationContext 接口的子接口。
* 在ApplicationContext基础上增加了配置上下文的工具。 ConfigurableApplicationContext是容器的高级接口
*/
public ConfigurableApplicationContext run(String... args) {
// 记录程序运行时间
// StopWatch主要是用来统计每项任务执行时长，例如Spring Boot启动占用总时长。
StopWatch stopWatch = new StopWatch();
stopWatch.start();
// ConfigurableApplicationContext Spring 的上下文
ConfigurableApplicationContext context = null;
Collection exceptionReporters = new ArrayList<>();
configureHeadlessProperty();
// 从META-INF/spring.factories中获取监听器
// 1、获取并启动监听器
// 第一步：获取并启动监听器 通过加载META-INF/spring.factories 完成了SpringApplicationRunListener实例化工作
SpringApplicationRunListeners listeners = getRunListeners(args);
// 实际上是调用了EventPublishingRunListener类的starting()方法
listeners.starting();
try {
ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
// 2、构造应用上下文环境
// 第二步：构造容器环境，简而言之就是加载系统变量，环境变量，配置文件
ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
// 处理需要忽略的Bean
configureIgnoreBeanInfo(environment);
// 打印banner
Banner printedBanner = printBanner(environment);
// 3、初始化应用上下文
// 第三步：创建容器
context = createApplicationContext();
// 实例化SpringBootExceptionReporter.class，用来支持报告关于启动的错误
// 第四步：实例化SpringBootExceptionReporter.class，用来支持报告关于启动的错误
exceptionReporters = getSpringFactoriesInstances(SpringBootExceptionReporter.class,
new Class[] { ConfigurableApplicationContext.class }, context);
// 4、刷新应用上下文前的准备阶段
// 第五步：准备容器 这一步主要是在容器刷新之前的准备动作。包含一个非常关键的操作：将启动类注入容器，为后续开启自动化配置奠定基础。
prepareContext(context, environment, listeners, applicationArguments, printedBanner);
// 5、刷新应用上下文(IOC容器的初始化过程)
// 第六步：刷新容器 springBoot相关的处理工作已经结束，接下的工作就交给了spring。内部会调用spring的refresh方法，
// refresh方法在spring整个源码体系中举足轻重，是实现 ioc 和 aop的关键。
refreshContext(context);
// 刷新应用上下文后的扩展接口
// 第七步：刷新容器后的扩展接口 设计模式中的模板方法，默认为空实现。如果有自定义需求，可以重写该方法。比如打印一些启动结束log，或者一些其它后置处理。
afterRefresh(context, applicationArguments);
// 时间记录停止
stopWatch.stop();
if (this.logStartupInfo) {
new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);
}
// 发布容器启动完成事件
listeners.started(context);
// 遍历所有注册的ApplicationRunner和CommandLineRunner，并执行其run()方法。
// 我们可以实现自己的ApplicationRunner或者CommandLineRunner，来对SpringBoot的启动过程进行扩展。
callRunners(context, applicationArguments);
}
catch (Throwable ex) {
handleRunFailure(context, ex, exceptionReporters, listeners);
throw new IllegalStateException(ex);
}
try {
// 应用已经启动完成的监听事件
listeners.running(context);
}
catch (Throwable ex) {
handleRunFailure(context, ex, exceptionReporters, null);
throw new IllegalStateException(ex);
}
return context;
}
这个方法大概做了以下几件事
1. 获取并启动监听器 通过加载META-INF/spring.factories 完成了SpringApplicationRunListener实例化工作
2. 构造容器环境，简而言之就是加载系统变量，环境变量，配置文件
3. 创建容器
4. 实例化SpringBootExceptionReporter.class，用来支持报告关于启动的错误
5. 准备容器
6. 刷新容器
7. 刷新容器后的扩展接口
那么内置tomcat启动源码，就是隐藏在上述第六步：refreshContext方法里面，该方法最终会调用到AbstractApplicationContext类的refresh()方法
进入refreshContext()方法，如图：
@Override
public void refresh() throws BeansException, IllegalStateException {
// 同步的方法;
// 来个锁，不然 refresh() 还没结束，你又来个启动或销毁容器的操作，那不就乱套了嘛
synchronized (this.startupShutdownMonitor) {
// Prepare this context for refreshing.
// 准备工作，包括设置启动时间，是否激活标识位
// 初始化属性源(property source)配置;
// 准备工作，记录下容器的启动时间、标记“已启动”状态、处理配置文件中的占位符
/**
* 前戏，做容器刷新前的准备工作
* 1.设置容器的启动时间
* 2.设置活跃状态为true
* 3.设置关闭状态为false
* 4.获取Environment对象，并加载当前系统的属性值到Environment对象中
* 5.准备监听器和事件的集合对象，默认为空的集合
*/
// 刷新上下文环境
prepareRefresh();
// Tell the subclass to refresh the internal bean factory.
// 返回一个factory 为什么需要返回一个工厂
// 因为要对工厂进行初始化
// 创建容器对象：DefaultListableBeanFactory
// 加载xml配置文件的属性值到当前工厂中，最重要的就是BeanDefinition;
// 这步比较关键，这步完成后，配置文件就会解析成一个个 Bean 定义，注册到 BeanFactory 中，
// 当然，这里说的 Bean 还没有初始化，只是配置信息都提取出来了，
// 注册也只是将这些信息都保存到了注册中心(说到底核心是一个 beanName-> beanDefinition 的 map)
// 这里是在子类中启动 refreshBeanFactory() 的地方
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
// 准备工厂
// beanFactory的准备工作，对各种属性进行填充;
// 设置 BeanFactory 的类加载器，添加几个 BeanPostProcessor，手动注册几个特殊的 bean
// 准备bean工厂，以便在此上下文中使用
prepareBeanFactory(beanFactory);
try {
// Allows post-processing of the bean factory in context subclasses.
// 子类覆盖方法做额外的处理，此处我们自己一般不做任何扩展工作，但是可以查看web中的代码，是有具体实现的;
// 【这里需要知道 BeanFactoryPostProcessor 这个知识点，Bean 如果实现了此接口，
// 那么在容器初始化以后，Spring 会负责调用里面的 postProcessBeanFactory 方法。】
// 这里是提供给子类的扩展点，到这里的时候，所有的 Bean 都加载、注册完成了，但是都还没有初始化
// 具体的子类可以在这步的时候添加一些特殊的 BeanFactoryPostProcessor 的实现类或做点什么事
// 设置 beanFactory 的后置处理
// postProcessBeanFactory()方法向上下文中添加了一系列的Bean的后置处理器。
// 后置处理器工作的时机是在所有的beanDefinition加载完成之后，bean实例化之前执行。
// 简单来说Bean的后置处理器可以修改BeanDefinition的属性信息。
postProcessBeanFactory(beanFactory);
// Invoke factory processors registered as beans in the context.
// 在spring的环境中去执行已经被注册的factory processors
// 设置执行自定义的ProcessBeanFactory和spring内部自己定义的
// 调用各种beanFactory处理器;
// 调用 BeanFactoryPostProcessor 各个实现类的 postProcessBeanFactory(factory) 方法
// 调用 BeanFactory 的后处理器，这些处理器是在Bean 定义中向容器注册的
invokeBeanFactoryPostProcessors(beanFactory);
// Register bean processors that intercept bean creation.
// 注册BeanPostProcessor
// 注册bean处理器，这里只是注册功能，真正调用的是getBean方法;
// 注册 BeanPostProcessor 的实现类，注意看和 BeanFactoryPostProcessor 的区别
// 此接口两个方法: postProcessBeforeInitialization 和 postProcessAfterInitialization
// 两个方法分别在 Bean 初始化之前和初始化之后得到执行。注意，到这里 Bean 还没初始化;
// 注册Bean的后处理器，在Bean创建过程中调用
registerBeanPostProcessors(beanFactory);
// Initialize message source for this context.
// 为上下文初始化message源，即不同语言的消息体，国际化处理，在springmvc的时候通过国际化的代码重点讲;
// 初始化当前 ApplicationContext 的事件广播器，这里也不展开了
// 初始化当前 ApplicationContext 的 MessageSource，国际化这里就不展开说了，不然没完没了了
//对上下文中的消息源进行初始化
initMessageSource();
// Initialize event multicaster for this context.
// 初始化应用事件广播器
// 初始化事件监听多路广播器
// 初始化上下文中的事件机制
initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
// 留给子类来初始化其他的bean;
// 从方法名就可以知道，典型的模板方法(钩子方法)，
// 具体的子类可以在这里初始化一些特殊的 Bean（在初始化 singleton beans 之前）
//初始化其他特殊的Bean
onRefresh();
// Check for listener beans and register them.
// 在所有注册的bean中查找listener bean，注册到消息广播器中;
// 注册事件监听器，监听器需要实现 ApplicationListener 接口。这也不是我们的重点，过
// 检查监听Bean并且将这些监听Bean向容器注册
registerListeners();
// Instantiate all remaining (non-lazy-init) singletons.
// new 对象 单例
// 初始化剩下的单实例(非懒加载的);
// 重点，重点，重点
// 初始化所有的 singleton beans
//（lazy-init 的除外）
// 实例化所有的（non-lazy-init）单例bean
finishBeanFactoryInitialization(beanFactory);
// Last step: publish corresponding event.
// 完成刷新过程，通知生命周期处理器lifecycleProcessor刷新过程，同时发出ContextRefreshEvent通知别人;
// 最后，广播事件，ApplicationContext 初始化完成
// 发布容器事件，结束Refresh过程
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
// 销毁已经初始化的 singleton 的 Beans，以免有些 bean 会一直占用资源
destroyBeans();
// Reset 'active' flag.
// 把异常往外抛
cancelRefresh(ex);
// Propagate exception to caller.
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we
// might not ever need metadata for singleton beans anymore...
resetCommonCaches();
}
}
}
一直点击refresh()方法，如图：
onRefresh()会调用到ServletWebServerApplicationContext中的createWebServer()
createWebServer()就是启动web服务，但是还没有真正启动Tomcat，既然webServer是通过ServletWebServerFactory来获取的，那就来看看这个工厂的真面目。
可以看到，tomcat,Jetty都实现了这个getWebServer方法，我们看TomcatServletWebServerFactory中的getWebServer(ServletContextInitializer… initializers)
最终就调用了TomcatServletWebServerFactory类的getWebServer()方法。
三、小结
springboot的内部通过new Tomcat() 的方式启动了一个内置Tomcat。
但是这里还有一个问题，这里只是启动了tomcat，但是我们的springmvc是如何加载的呢？
下一章我们讲接收，springboot是如何自动装配springmvc的
视频教程