本文对SpringBoot的启动流程作一个讲解。
通过SpringApplication开始引导启动
SpringApplication类是用来执行Spring框架启动的引导类。有两种方式可以进行启动引导：
- 通过静态方法
SpringApplication.run启动。 - 先创建
SpringApplication实例，在调用的实例方法run进行启动。
无论是以上哪种方式，最终都是通过创建SpringApplication实例，在调用run()启动。
new SpringApplication——创建引导启动的实例
在创建SpringApplication实例的时候，会根据用户输入和工程环境做一些基础配置，供之后引导启动中使用。
- 设置
ResourceLoader和PrimarySources - 从类中加载
initializer和listener放在集合 - 设置是否为Web环境(先确认用户是否指定，未指定则根据工程目录下是否有servlet相关环境)
- 从工程环境中决定主入口的类
run()——开始引导启动
new StopWatch()——创建计时器
StopWatch是springframework.util中提供的一个工具类，在启动过程中使用StopWatch是为了记录启动花费的时间。
configureHeadlessProperty()——配置Headless模式
Headless模式是在环境缺少显示器等设备情况下的一种配置，和启动流程并无太多关系，不做介绍。
SpringApplicationRunListener.start()——获取监听器，启动监听
监听器可以用来监听SpringApplication启动过程中的各个阶段。默认的监听器是EventPublishRunListener，用户也可以通过实现SpringApplicationRunListener接口，实现应用程序对SpringApplication启动过程的监听。
在 resources/META-INF 下建立 spring.factories 文件，文件中添加 key=value 形式，其中 key 为 SpringApplicationRunListener的全路径名，value 为应用程序对该接口的实现类(类需要一个参数类型为 SpringApplication 和 String 数组的构造函数，用于通过反射创建实例)。
prepareEnvironment()——准备环境，创建ConfigurableEnvironment对象
在这一步，SpringApplication会创建Spring启动所需的环境，这个环境主要由ConfigurableEnviroment对象表示。首先，该对象确认了程序是否需要设置Web环境，其次，该对象还确定了程序所需要的参数和读取的配置文件等信息。
此步骤会回调SpringApplicationRunListener的environmentPrepared()方法，通知监听器环境已经准备好。
printBanner()——打印横幅
这一步骤其实和启动并没有太大关系，只是会向控制台或是日志中输出Spring的Logo和版本信息。
createApplicationContext()——创建应用程序上下文并加载Bean
在准备好环境之后，接下来要做的就是创建应用程序上下文ApplicationContext对象。
ApplicationContext是Spring IoC的核心组件，它不仅是程序所需Bean的容器，还提供了国际化，事件发布等功能。
在创建应用程序上下文的时候，首先会根据之前配置决定上下文的具体类型（AnnotationConfigApplicationContext或是AnnotationConfigServletWebServerApplicationContext）。再通过反射实例化到对象。
prepareContext()——准备ApplicationContext
虽然已经得到了ApplicationContext对象，但此时的对象还只是一个空白对象，需要准备和处理后，ApplicationContext才能被使用。
在准备过程中主要做了做了几件事：为ApplicationContext设置之前准备好的Environment对象。
通过对ApplicationContext后置处理或是BeanDefinitionLoader等方式往容器中添加一些初始的Bean。
应用默认的初始化器初始化应用程序上下文(责任链模式的应用，多个初始化器形成一个List，应用程序需要被每个初始化器应用一次，每个初始化器有自己的职责)。
准备过程中ApplicationRunListener发出两个消息，分别是contextPrepared和contextLoaded。
refreshContext()——刷新上下文
在应用程序上下文准备好后，可以通过刷新应用程序上下文发现Bean并加载到容器中。refreshContext()会调用ApplicationContext.refresh()方法。
AbstractApplicationContext中定义了refresh()方法的基本框架(模板模式的应用)。
prepareRefresh()——准备刷新
准备刷新的阶段做了初始化和校验的工作。比如初始化启动时间，初始化PropertySources(在AbstractApplicationContext中只是一个空方法，留给子类根据需要实现)，以及校验环境中是否已经有必要的参数。
prepareBeanFactory()——准备BeanFactory
BeanFactory是 Spring 框架中容器的底层实现，所有的 Bean 都存放在BeanFactory中，虽然ApplicationContext也实现了BeanFactory接口，但是在其内部还是将获取 Bean 的相关操作委托给内部的DefaultListableBeanFactory变量，只是ApplicationContext帮用户屏蔽了底层的操作，同时提供出一些更符合外部用户使用的接口。
对BeanFactory的准备主要是：添加一些必要组件，比如类加载器，表达式解析器，属性编辑器注册表等。
以及一些后置处理器，比如ApplicationContextAwareProcessor(xxxAware的接口就是通过后置处理器在Bean创建的时候，通过后置处理器设置的)。此外还有一些特殊的Bean，environment,systemProperties和systemEnvirnoment。
postProcessBeanFactory()——后置处理BeanFactory
对于非WebServlet环境的ApplicationContext而言这个方法是个空方法，但是Web环境下的ApplicationContext会通过这个方法定制一些后处理动作，比如添加WebApplicationContextServletAwareProcessor后置处理器，添加在web环境中可能使用的Scope（session和request）。
invokeBeanFactoryPostProcessors()——实例化并调用BeanFactoryPostProcessor
BeanFactoryPostProcessor是一种特殊的后置处理器，其操作的对象是针对BeanFactory。
此时主要有三个后置处理器，分别是:SharedMetadataReaderFactoryContextInitializer$CachingMetadataReaderFactoryPostProcessor,ConfigurationWarningsApplicationContextInitializer$ConfigurationWarningsPostProcessor和ConfigFileApplicationListener$PropertySourceOrderingPostProcessor。这三个类名字虽然很长，但是其实是因为内部类的关系，而且看名字也能发现类是怎么来的(外部类是xxxInitializer的就说明是初始化器设置的)。
其中第一个类和启动流程有关，因为它会向容器注册ConfigurationClassPostProcessor。
如果BeanFactoryPostProcessor同时又是BeanDefinitionRegistryPostProcessor，则先进行针对BeanDefinition注册表的后置处理，目的是为了发现Bean。
在最初的三个BeanFactoryProcessor后置处理完成后，会从容器中获取BeanDefinitionRegistryPostProcessor类型的后置处理器（这里主要会得到刚才加载的ConfigurationClassPostProcessor实例）。再调用这些BeanDefinitionRegistry的后置处理器，继续向发现并向容器中注册新的Bean。
这里主要是通过@Configuration注解作为入口发现Bean，如果发现的Bean中又存在新的@ConfigurationBean，则以此Bean为入口再进行发现，直到所有的Bean都被发现。
在针对BeanDefinition注册表的后置处理完成（发现Bean的过程）中，如果找到了BeanFactoryPostProcessor(包括最初的三个BeanFatoryProcessor)，会进行针对BeanFactory的后置处理过程（之前只是进行针对注册表的后置处理，二者的目的还是有区别的）。
注意 Bean的发现过程只是向BeanDefinition注册表注册BeanDefinition的过程，并没有针对发现的Bean进行实例化（少部分需要用到的Bean会进行实例化，比如这部分会对BeanDefinitionRegistryPostProcessor类型的Bean实例化）。
registerBeanPostProcessors()——注册Bean后置处理器
上一步是针对BeanFactory和BeanDefinitionRegistry的后置处理器，这一步从BeanFactory中获取针对普通Bean的后置处理器BeanFactoryPostProcessor放到专门的容器beanPostProcessors中。
initMessageSource()——初始化MessageSource
MessageSource是拥有特殊功能的Bean，用来处理国际化相关内容。
initApplicationEventMulticaster()——初始化ApplicationEventMulticaster
ApplicationEventMulticaster是ApplicationEvent广播器，可以通过这个对象向容器中添加移除Listener，也可以通过这个对象发布事件（观察者模式的应用）。
onRefresh()——刷新应用程序
发现了所有的Bean，并且需要实例化的Bean也都被创建好了之后，Spring接下去要做的是创建ThemeSource（和主题相关的组件），以及创建Webserver(如果是Web环境的话)。
registerListeners()——注册监听器
这一步会将初始化得到的ApplicationListener方法和容器中获得ApplicationListener一起注册到ApplicationEventMulticaster中，并且如果存在需要早起发布的事件，则发布事件。
finishBeanFactoryInitialzation()——初始化容器中的Bean
经过之前的步骤，现在容器中必要的组件都已经准备好了，并且所有需要容器管理的Bean也都已经被发现注册成BeanDefinition注册表中。
对于Scope是Singleton的Bean而言，此时已经具备了实例化Bean的条件，因此在这一步中，Spring会对所有Singleton且非lazy-init的Bean进行实例化。
主要做法就是获取容器中所有为singletion且非lazyInit的BeanDefinition，然后通过getBean创建出Bean的实例，保存在容器内部。
有一种特殊的情况是针对FactoryBean，FactoryBean是一种用来创建Bean的特殊Bean，在得到FactoryBean的Bean之后，还需要判断是否要创建FactoryBean负责创建的Bean。
finishRefresh()——完成刷新
在这步主要是一些资源清理以及注册LifeCycleProcessor。LifeCycleProcessor可以用来在 Spring 生命周期的refresh和close时触发回调。并且发布Refresh的消息。
afterRefresh()——留给子类的钩子函数
在Application完成刷新后，SpringApplication给子类留了afterRefresh()的方法作为回调。
启动完成
启动完成后，stopWatch会记录下本次启动消费的时间。
然后向ApplicationRunListener发布started事件，说明已经启动就绪。
准备运行
启动完成后，正式运行前，SpringApplication还会执行用户定义的ApplicationRunner和CommandLineRunner两个接口中定义的run()方法。
在执行完成后，向ApplicationRunListener发布runing的消息。至此，启动流程结束。
总结
本文旨在对SpringBoot启动流程各个步骤做一次梳理（本文的段落标题就是启动的各个步骤，不同等级的标题也含有方法前后调用的关系），并没有对每行代码做深入分析。如果感兴趣可以对照流程自己分析一遍。另外，在贴一份整理的不错的流程图帮助大家加深印象。
由于该系统是底层系统，以[微服务]形式对外暴露dubbo服务，所以本流程中SpringBoot不基于jetty或者tomcat等容器启动方式发布服务，而是以执行程序方式启动来发布(参考下图keepRunning方法)。本文以调试一个实际的SpringBoot启动程序为例，参考流程中主要类类图，来分析其启动逻辑和自动化配置原理。
总览：
上图为SpringBoot启动结构图，我们发现启动流程主要分为三个部分，第一部分进行SpringApplication的初始化模块，配置一些基本的环境变量、资源、构造器、监听器，第二部分实现了应用具体的启动方案，包括启动流程的监听模块、加载配置环境模块、及核心的创建上下文环境模块，第三部分是自动化配置模块，该模块作为springboot自动配置核心，在后面的分析中会详细讨论。在下面的启动程序中我们会串联起结构中的主要功能。
启动：
每个SpringBoot程序都有一个主入口，也就是main方法，main里面调用SpringApplication.run()启动整个spring-boot程序，该方法所在类需要使用@SpringBootApplication注解，以及@ImportResource注解(if need)，@SpringBootApplication包括三个注解，功能如下：@EnableAutoConfiguration：SpringBoot根据应用所声明的依赖来对Spring框架进行自动配置
@SpringBootConfiguration(内部为@Configuration)：被标注的类等于在spring的XML配置文件中(applicationContext.xml)，装配所有bean事务，提供了一个spring的上下文环境
@ComponentScan：组件扫描，可自动发现和装配Bean，默认扫描SpringApplication的run方法里的Booter.class所在的包路径下文件，所以最好将该启动类放到根包路径下
SpringBoot启动类
首先进入run方法
run方法中去创建了一个SpringApplication实例，在该构造方法内，我们可以发现其调用了一个初始化的initialize方法
这里主要是为SpringApplication对象赋一些初值。构造函数执行完毕后，我们回到run方法
该方法中实现了如下几个关键步骤：
1.创建了应用的监听器SpringApplicationRunListeners并开始监听
2.加载SpringBoot配置环境(ConfigurableEnvironment)，如果是通过web容器发布，会加载StandardEnvironment，其最终也是继承了ConfigurableEnvironment，类图如下
可以
看出，\Environment最终都实现了PropertyResolver接口，我们平时通过environment对象获取配置文件中指定Key对应的value方法时，就是调用了propertyResolver接口的getProperty方法
3.配置环境(Environment)加入到监听器对象中(SpringApplicationRunListeners)
4.创建run方法的返回对象：ConfigurableApplicationContext(应用配置上下文)，我们可以看一下创建方法：
方法会先获取显式设置的应用上下文(applicationContextClass)，如果不存在，再加载默认的环境配置（通过是否是web environment判断），默认选择AnnotationConfigApplicationContext注解上下文（通过扫描所有注解类来加载bean），最后通过BeanUtils实例化上下文对象，并返回，ConfigurableApplicationContext类图如下：
主要看其继承的两个方向：
LifeCycle：生命周期类，定义了start启动、stop结束、isRunning是否运行中等生命周期空值方法
ApplicationContext：应用上下文类，其主要继承了beanFactory(bean的工厂类)
5.回到run方法内，prepareContext方法将listeners、environment、applicationArguments、banner等重要组件与上下文对象关联
6.接下来的refreshContext(context)方法(初始化方法如下)将是实现spring-boot-starter-*(mybatis、redis等)自动化配置的关键，包括spring.factories的加载，bean的实例化等核心工作。
refresh方法
配置结束后，Springboot做了一些基本的收尾工作，返回了应用环境上下文。回顾整体流程，Springboot的启动，主要创建了配置环境(environment)、事件监听(listeners)、应用上下文(applicationContext)，并基于以上条件，在容器中开始实例化我们需要的Bean，至此，通过SpringBoot启动的程序已经构造完成，接下来我们来探讨自动化配置是如何实现。
自动化配置：
之前的启动结构图中，我们注意到无论是应用初始化还是具体的执行过程，都调用了SpringBoot自动配置模块
SpringBoot自动配置模块
该配置模块的主要使用到了SpringFactoriesLoader，即Spring工厂加载器，该对象提供了loadFactoryNames方法，入参为factoryClass和classLoader，即需要传入上图中的工厂类名称和对应的类加载器，方法会根据指定的classLoader，加载该类加器搜索路径下的指定文件，即spring.factories文件，传入的工厂类为接口，而文件中对应的类则是接口的实现类，或最终作为实现类，所以文件中一般为如下图这种一对多的类名集合，获取到这些实现类的类名后，loadFactoryNames方法返回类名集合，方法调用方得到这些集合后，再通过反射获取这些类的类对象、构造方法，最终生成实例
工厂接口与其若干实现类接口名称
下图有助于我们形象理解自动配置流程
SpringBoot自动化配置关键组件关系图
mybatis-spring-boot-starter、spring-boot-starter-web等组件的META-INF文件下均含有spring.factories文件，自动配置模块中，SpringFactoriesLoader收集到文件中的类全名并返回一个类全名的数组，返回的类全名通过反射被实例化，就形成了具体的工厂实例，工厂实例来生成组件具体需要的bean。
之前我们提到了EnableAutoConfiguration注解，其类图如下
可以发现其最终实现了ImportSelector(选择器)和BeanClassLoaderAware(bean类加载器中间件)，重点关注一下AutoConfigurationImportSelector的selectImports方法
该方法在springboot启动流程——bean实例化前被执行，返回要实例化的类信息列表。我们知道，如果获取到类信息，spring自然可以通过类加载器将类加载到jvm中，现在我们已经通过spring-boot的starter依赖方式依赖了我们需要的组件，那么这些组建的类信息在select方法中也是可以被获取到的，不要急我们继续向下分析
该方法中的getCandidateConfigurations方法，通过方法注释了解到，其返回一个自动配置类的类名列表，方法调用了loadFactoryNames方法，查看该方法
在上面的代码可以看到自动配置器会跟根据传入的factoryClass.getName()到项目系统路径下所有的spring.factories文件中找到相应的key，从而加载里面的类。我们就选取这个mybatis-spring-boot-autoconfigure下的spring.factories文件
进入org.mybatis.spring.boot.autoconfigure.MybatisAutoConfiguration中，主要看一下类头
发现@Spring的Configuration，俨然是一个通过注解标注的springBean，继续向下看，
@ConditionalOnClass({ SqlSessionFactory.class, SqlSessionFactoryBean.class})这个注解的意思是：当存在SqlSessionFactory.class, SqlSessionFactoryBean.class这两个类时才解析MybatisAutoConfiguration配置类,否则不解析这一个配置类，make sence，我们需要mybatis为我们返回会话对象，就必须有会话工厂相关类
@CondtionalOnBean(DataSource.class):只有处理已经被声明为bean的dataSource
@ConditionalOnMissingBean(MapperFactoryBean.class)这个注解的意思是如果容器中不存在name指定的bean则创建bean注入，否则不执行（该类源码较长，篇幅限制不全粘贴）
以上配置可以保证sqlSessionFactory、sqlSessionTemplate、dataSource等mybatis所需的组件均可被自动配置，@Configuration注解已经提供了Spring的上下文环境，所以以上组件的配置方式与Spring启动时通过mybatis.xml文件进行配置起到一个效果。通过分析我们可以发现，只要一个基于SpringBoot项目的类路径下存在SqlSessionFactory.class, SqlSessionFactoryBean.class，并且容器中已经注册了dataSourceBean，就可以触发自动化配置，意思说我们只要在maven的项目中加入了mybatis所需要的若干依赖，就可以触发自动配置，但引入mybatis原生依赖的话，每集成一个功能都要去修改其自动化配置类，那就得不到开箱即用的效果了。所以Spring-boot为我们提供了统一的starter可以直接配置好相关的类，触发自动配置所需的依赖(mybatis)如下：
这里是截取的mybatis-spring-boot-starter的源码中pom.xml文件中所有依赖:
评论区