SpringBoot启动原理解析

我们开发任何一个 Spring Boot 项目都会用到如下的启动类

@SpringBootApplication 
public class Application { 
    public static void main(String[] args) {  
       SpringApplication.run(Application.class, args);}}

从上面代码可以看出Annotation 定义@SpringBootApplication和类定义SpringApplication.run最为耀眼所以要揭开 SpringBoot 的神秘面纱我们要从这两位开始就可以了。

一、SpringBootApplication 背后的秘密

@SpringBootApplication 注解是 Spring Boot 的核心注解它其实是一个组合注解

 1 @Target(ElementType.TYPE) 
 2 @Retention(RetentionPolicy.RUNTIME) 
 3 @Documented 
 4 @Inherited 
 5 @SpringBootConfiguration 
 6 @EnableAutoConfiguration 
 7 @ComponentScan(excludeFilters = {@Filter(type = FilterType.CUSTOM,
  classes = TypeExcludeFilter.class), 
  @Filter(type = FilterType.CUSTOM, 
  classes = AutoConfigurationExcludeFilter.class) })
  public @interface SpringBootApplication {...}

虽然定义使用了多个 Annotation 进行了原信息标注但实际上重要的只有三个 Annotation

• @Configuration@SpringBootConfiguration 点开查看发现里面还是应用了 @Configuration
• @EnableAutoConfiguration
• @ComponentScan

即 @SpringBootApplication = (默认属性)@Configuration + @EnableAutoConfiguration + @ComponentScan。

所以如果我们使用如下的 SpringBoot 启动类整个 SpringBoot 应用依然可以与之前的启动类功能对等

@Configuration 
@EnableAutoConfiguration
@ComponentScan 
public class Application { 
    public static void main(String[] args) {
             SpringApplication.run(Application.class, args);}}

每次写这 3 个比较累所以写一个 @SpringBootApplication 方便点。接下来分别介绍这 3 个 Annotation。

1、@Configuration

​ 这里的 @Configuration 对我们来说不陌生它就是 JavaConfig 形式的 Spring Ioc 容器的配置类使用的那个 @ConfigurationSpringBoot 社区推荐使用基于 JavaConfig 的配置形式所以这里的启动类标注了 @Configuration 之后本身其实也是一个 IoC 容器的配置类。

举几个简单例子回顾下XML 跟 config 配置方式的区别

1表达形式层面

基于 XML 配置的方式是这样

 <?xml version="1.0" encoding="UTF-8"?>
 <beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"
        default-lazy-init="true">     
  <!--bean定义-->
 </beans>

而基于 JavaConfig 的配置方式是这样

 @Configuration
  public class MockConfiguration{     //bean定义 }

任何一个标注了 @Configuration 的 Java 类定义都是一个 JavaConfig 配置类。

2注册 bean 定义层面

基于 XML 的配置形式是这样

 <bean>     ... </bean>

而基于 JavaConfig 的配置形式是这样的

 @Configuration
  public class MockConfiguration{
       @Bean
       public MockService mockService(){
                return new MockServiceImpl();}}

任何一个标注了 @Bean 的方法其返回值将作为一个 bean 定义注册到 Spring 的 IoC 容器方法名将默认成该 bean 定义的 id。

3表达依赖注入关系层面

为了表达 bean 与 bean 之间的依赖关系在 XML 形式中一般是这样

 <bean>
      <propery name ="dependencyService" ref="dependencyService" />
 </bean> 
 <bean></bean>

而基于 JavaConfig 的配置形式是这样的

  @Configuration 
  public class MockConfiguration{ 
        @Bean 
        public MockService mockService(){ 
           return new MockServiceImpl(dependencyService()); 
        } 
        @Bean 
        public DependencyService dependencyService(){
           return new DependencyServiceImpl();
        }
  }

如果一个 bean 的定义依赖其他 bean则直接调用对应的 JavaConfig 类中依赖 bean 的创建方法就可以了。

@Configuration提到 @Configuration 就要提到他的搭档 @Bean。使用这两个注解就可以创建一个简单的 spring 配置类可以用来替代相应的 xml 配置文件。

 <beans> 
      <bean id = "car"> 
      <property ></property> 
      </bean> 
      <bean id = "wheel">
      </bean>
</beans>

相当于

 @Configuration  
 public class Conf {  
      @Bean  
      public Car car() {
         Car car = new Car();  
         car.setWheel(wheel()); 
       return car;   
       } 
      @Bean  
      public Wheel wheel() { 
       return new Wheel();
       }
 }

@Configuration 的注解类标识这个类可以使用 Spring IoC 容器作为 bean 定义的来源。

@Bean 注解告诉 Spring一个带有 @Bean 的注解方法将返回一个对象该对象应该被注册为在 Spring 应用程序上下文中的 bean。

2、@ComponentScan

​ @ComponentScan 这个注解在 Spring 中很重要它对应 XML 配置中的元素@ComponentScan 的功能其实就是自动扫描并加载符合条件的组件比如 @Component 和 @Repository 等或者 bean 定义最终将这些 bean 定义加载到 IoC 容器中。

我们可以通过 basePackages 等属性来细粒度的定制 @ComponentScan 自动扫描的范围如果不指定则默认 Spring 框架实现会从声明 @ComponentScan 所在类的 package 进行扫描。

注所以 SpringBoot 的启动类最好是放在 root package 下因为默认不指定 basePackages。

3、@EnableAutoConfiguration

个人感觉 @EnableAutoConfiguration 这个 Annotation 最为重要所以放在最后来解读大家是否还记得 Spring 框架提供的各种名字为 @Enable 开头的 Annotation 定义比如 @EnableScheduling、@EnableCaching、@EnableMBeanExport 等@EnableAutoConfiguration 的理念和做事方式其实一脉相承简单概括一下就是借助 @Import 的支持收集和注册特定场景相关的 bean 定义。

• @EnableScheduling 是通过 @Import 将 Spring 调度框架相关的 bean 定义都加载到 IoC 容器。
• @EnableMBeanExport 是通过 @Import 将 JMX 相关的 bean 定义加载到 IoC 容器。

而 @EnableAutoConfiguration 也是借助 @Import 的帮助将所有符合自动配置条件的 bean 定义加载到 IoC 容器仅此而已

@EnableAutoConfiguration 会根据类路径中的 jar 依赖为项目进行自动配置如添加了 spring-boot-starter-web 依赖会自动添加 Tomcat 和 Spring MVC 的依赖Spring Boot 会对 Tomcat 和 Spring MVC 进行自动配置。

@EnableAutoConfiguration 作为一个复合 Annotation其自身定义关键信息如下

 @SuppressWarnings("deprecation") 
 @Target(ElementType.TYPE) 
 @Retention(RetentionPolicy.RUNTIME) 
 @Documented 
 @Inherited 
 @AutoConfigurationPackage 
 @Import(EnableAutoConfigurationImportSelector.class) 
 public @interface EnableAutoConfiguration { ... }

其中最关键的要属 @Import(EnableAutoConfigurationImportSelector.class)借助 EnableAutoConfigurationImportSelector@EnableAutoConfiguration 可以帮助 SpringBoot 应用将所有符合条件的 @Configuration 配置都加载到当前 SpringBoot 创建并使用的 IoC 容器。就像一只 “八爪鱼” 一样借助于 Spring 框架原有的一个工具类SpringFactoriesLoader 的支持@EnableAutoConfiguration 可以智能的自动配置功效才得以大功告成

自动配置幕后英雄SpringFactoriesLoader 详解

SpringFactoriesLoader 属于 Spring 框架私有的一种扩展方案其主要功能就是从指定的配置文件 META-INF/spring.factories 加载配置。

 public abstract class SpringFactoriesLoader { 
      //...      
      public static <T> List<T> loadFactories(Class<T> factoryClass, ClassLoader classLoader) { ... }      
      public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) { .... } 
 }

配合 @EnableAutoConfiguration 使用的话它更多是提供一种配置查找的功能支持即根据 @EnableAutoConfiguration 的完整类名 org.springframework.boot.autoconfigure.EnableAutoConfiguration 作为查找的 Key获取对应的一组 @Configuration 类。

上图就是从 SpringBoot 的 autoconfigure 依赖包中的 META-INF/spring.factories 配置文件中摘录的一段内容可以很好地说明问题。

所以@EnableAutoConfiguration 自动配置的魔法骑士就变成了从 classpath 中搜寻所有的 META-INF/spring.factories 配置文件并将其中 org.springframework.boot.autoconfigure.EnableutoConfiguration 对应的配置项通过反射Java Refletion实例化为对应的标注了 @Configuration 的 JavaConfig 形式的 IoC 容器配置类然后汇总为一个并加载到 IoC 容器。

二、深入探索 SpringApplication 执行流程

SpringApplication 的 run 方法的实现是我们本次旅程的主要线路该方法的主要流程大体可以归纳如下

1 如果我们使用的是 SpringApplication 的静态 run 方法那么这个方法里面首先要创建一个 SpringApplication 对象实例然后调用这个创建好的 SpringApplication 的实例方法。在 SpringApplication 实例初始化的时候它会提前做几件事情

• 根据 classpath 里面是否存在某个特征类org.springframework.web.context.ConfigurableWebApplicationContext来决定是否应该创建一个为 Web 应用使用的 ApplicationContext 类型。
• 使用 SpringFactoriesLoader 在应用的 classpath 中查找并加载所有可用的 ApplicationContextInitializer。
• 使用 SpringFactoriesLoader 在应用的 classpath 中查找并加载所有可用的 ApplicationListener。
• 推断并设置 main 方法的定义类。

2 SpringApplication 实例初始化完成并且完成设置后就开始执行 run 方法的逻辑了方法执行伊始首先遍历执行所有通过 SpringFactoriesLoader 可以查找到并加载的 SpringApplicationRunListener。调用它们的 started() 方法告诉这些 SpringApplicationRunListener“嘿SpringBoot 应用要开始执行咯”。

3 创建并配置当前 Spring Boot 应用将要使用的 Environment包括配置要使用的 PropertySource 以及 Profile。

4 遍历调用所有 SpringApplicationRunListener 的 environmentPrepared() 的方法告诉他们“当前 SpringBoot 应用使用的 Environment 准备好了咯”。

5 如果 SpringApplication 的 showBanner 属性被设置为 true则打印 banner。

6 根据用户是否明确设置了 applicationContextClass 类型以及初始化阶段的推断结果决定该为当前 SpringBoot 应用创建什么类型的 ApplicationContext 并创建完成然后根据条件决定是否添加 ShutdownHook决定是否使用自定义的 BeanNameGenerator决定是否使用自定义的 ResourceLoader当然最重要的将之前准备好的 Environment 设置给创建好的 ApplicationContext 使用。

7 ApplicationContext 创建好之后SpringApplication 会再次借助 Spring-FactoriesLoader查找并加载 classpath 中所有可用的 ApplicationContext-Initializer然后遍历调用这些 ApplicationContextInitializer 的 initializeapplicationContext方法来对已经创建好的 ApplicationContext 进行进一步的处理。

8 遍历调用所有 SpringApplicationRunListener 的 contextPrepared() 方法。

9 最核心的一步将之前通过 @EnableAutoConfiguration 获取的所有配置以及其他形式的 IoC 容器配置加载到已经准备完毕的 ApplicationContext。

10 遍历调用所有 SpringApplicationRunListener 的 contextLoaded() 方法。

11 调用 ApplicationContext 的 refresh() 方法完成 IoC 容器可用的最后一道工序。

12 查找当前 ApplicationContext 中是否注册有 CommandLineRunner如果有则遍历执行它们。

13 正常情况下遍历执行 SpringApplicationRunListener 的 finished() 方法、如果整个过程出现异常则依然调用所有 SpringApplicationRunListener 的 finished() 方法只不过这种情况下会将异常信息一并传入处理

去除事件通知点后整个流程如下

本文以调试一个实际的 SpringBoot 启动程序为例参考流程中主要类类图来分析其启动逻辑和自动化配置原理。

总览

上图为 SpringBoot 启动结构图我们发现启动流程主要分为三个部分第一部分进行 SpringApplication 的初始化模块配置一些基本的环境变量、资源、构造器、监听器第二部分实现了应用具体的启动方案包括启动流程的监听模块、加载配置环境模块、及核心的创建上下文环境模块第三部分是自动化配置模块该模块作为 springboot 自动配置核心在后面的分析中会详细讨论。在下面的启动程序中我们会串联起结构中的主要功能。

启动

​ 每个 SpringBoot 程序都有一个主入口也就是 main 方法main 里面调用 SpringApplication.run() 启动整个 spring-boot 程序该方法所在类需要使用 @SpringBootApplication 注解以及 @ImportResource 注解 (if need)@SpringBootApplication 包括三个注解功能如下

@EnableAutoConfigurationSpringBoot 根据应用所声明的依赖来对 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 方法

1. 配置环境 (Environment) 加入到监听器对象中(SpringApplicationRunListeners)
2. 创建 run 方法的返回对象ConfigurableApplicationContext(应用配置上下文)我们可以看一下创建方法

方法会先获取显式设置的应用上下文 (applicationContextClass)如果不存在再加载默认的环境配置通过是否是 web environment 判断默认选择 AnnotationConfigApplicationContext 注解上下文通过扫描所有注解类来加载 bean最后通过 BeanUtils 实例化上下文对象并返回。

ConfigurableApplicationContext 类图如下

主要看其继承的两个方向

LifeCycle生命周期类定义了 start 启动、stop 结束、isRunning 是否运行中等生命周期空值方法

ApplicationContext应用上下文类其主要继承了 beanFactory(bean 的工厂类)

1. 回到 run 方法内prepareContext 方法将 listeners、environment、applicationArguments、banner 等重要组件与上下文对象关联
2. 接下来的 refreshContext(context)方法 (初始化方法如下) 将是实现 spring-boot-starter-*(mybatis、redis 等)自动化配置的关键包括 spring.factories 的加载bean 的实例化等核心工作。

​ 配置结束后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 文件中所有依赖

因为 maven 依赖的传递性我们只要依赖 starter 就可以依赖到所有需要自动配置的类实现开箱即用的功能。也体现出 Springboot 简化了 Spring 框架带来的大量 XML 配置以及复杂的依赖管理让开发人员可以更加关注业务逻辑的开发。