Springboot——自动配置原理

2021-01-12

我们使用Springboot进行开发的时候发现真的很方便，我们只需要很少的配置、少量的注解以及引入一些starter就可以完成一个简单项目的开发。使我们受益的就是Springboot的自动配置功能，下面我们来探索Springboot的自动配置原理。（中间的一些细节的地方不做过多介绍，影响阅读体验，主要解析核心脉络）

先看下配置类的解析流程图：

配置类解析流程图

我们知道Spring容器的主要工作原理就是先根据配置的信息将相关的BeanDefinition（也就是Bean的元数据，比如类的全路径名、属性等）扫描并加载到容器中，后续再根据这些BeanDefinition对这些Bean进行实例化初始化等一系列操作，然后再将最后的Bean实例保存到Spring容器中。因此Springboot的自动配置的原理主要是BeanDefinition的自动注册

我们就从Springboot的启动类TomcatWarApplication开始分析：

package com.sourcecode.springboot.tomcatwar;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

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

步骤分析：

第一步：main方法的作用就是新建一个SpringApplication实例并将将TomcatWarApplication.class放入到了该对象的实例属性primarySources（一个Set）中，然后调用该对象的run方法

第二步：run方法中会对primarySources中的存放的TomcatWarApplication.class进行加载并解析为一个BeanDefinition后注册到BeanFactory中

第三步【重点】：run方法内部的refreshContext方法会对BeanFactory中的BeanDefinition进行处理，将该BeanDefinition的注解元数据和对应的bean名称封装为一个ConfigurationClass（配置类）对象，然后对该对象进行解析。具体步骤如下：

类是否有@Component注解，如果有的话，解析该类的成员内部类是否满足作为一个配置类的要求（该内部类是否有@Component、@ComponentScan、@Import、@ImportResource注解或者该内部类是否有被@Bean注解的方法），如果满足的话，那么就将该内部类作为一个配置类进行同样的解析
类是否有@PropertySource注解，用来解析properties配置文件中配置的属性
类是否有@ComponentScan注解，如果有的话，解析该注解相应属性中配置的包名、类的全路径所在的包名，然后使用ClassPathBeanDefinitionScanner扫描器对这些类路径下的class文件进行加载解析，判断这些class是否满足条件（是否有@Component注解、是否有@JAVAx.annotation.ManagedBean注解、是否有@javax.inject.Named注解），如果满足条件的话，就将该class作为一个配置类进行同样的解析
类是否有@Import注解，a）如果@Import注解中的value属性值是ImportSelector类型的话，再判断是否是延迟导入选择器DeferredImportSelector类型的，如果是的话，那么延迟处理value属性值对应的class，最终调用的是processGroupImports方法；如果不是延迟导入类型，那么立即对value属性值对应的class进行处理，最终调用的是该类的selectImports方法，然后将该方法返回的所有的类名作为配置类进行同样的解析；b）如果@Import注解中的value属性值是ImportBeanDefinitionRegistrar类型的，则后续调用registerBeanDefinitions进行BeanDefinition的注册；c）如果是其他类型的class，那么就直接将该class作为一个配置类进行同样的解析
类是否有@ImportResource注解，如果有的话，就导入以XML格式进行BeanDefinition定义的配置文件，后续把该配置文件中定义的BeanDefinition作为配置类进行同样的解析
类中是否有被@Bean注解的方法，如果有的话，抽取这些方法的元数据并添加到该配置类的属性中，后续实例化时也会实例化以方法的形式声明的Bean
如果类实现了接口，抽取这些接口中被@Bean注解了的默认方法（default method）的元数据并添加到该配置类的属性中，后续实例化时也会实例化这些以方法的形式声明的Bean
如果该类有父类的话，那么把父类相关信息也封装为一个ConfigurationClass并做同上述一样的解析

第四步：通过上述步骤之后，就把TomcatWarApplication.class以及它关联的所有BeanDefinition注册到BeanFactory中了，后面进行Bean的实例化的时候就会根据所有注册的BeanDefinition来进行对应的实例化

回到我们的启动类，我们将@SpringBootApplication的一些相关元注解全部提取出来放在一起，这些看起来清晰一些：

@Configuration
@Import(AutoConfigurationImportSelector.class)
@Import(AutoConfigurationPackages.Registrar.class)
@ComponentScan
public class TomcatWarApplication {
    public static void main(String[] args) {
        SpringApplication.run(TomcatWarApplication.class, args);
    }
}

这样看发现我们的启动类实际是被这些注解标识：

@Configuration

@Import(AutoConfigurationImportSelector.class)

@Import(AutoConfigurationPackages.Registrar.class)

@ComponentScan

我们按我们上面步骤的第三步来对TomcatWarApplication.class这个配置类进行解析：

1、@ComponentScan满足第三个条件，如果@ComponentScan注解没有显示设置的属性，那么就扫描TomcatWarApplication所在包路径（com.sourcecode.springboot.tomcatwar）下的class，如果满足条件（比如注解了@Configuration或@Service等）就会将这些class作为一个配置类，然后进行同样的解析

2、@Import(AutoConfigurationImportSelector.class)，这个Selector是ImportSelector类型且是DeferredImportSelector类型，那么就将AutoConfigurationImportSelector中的selectImports方法返回的类作为配置类进行同样解析，该方法使用SPI的方式从jar中的META-INF/spring.factories文件中获取指定属性的值（也就是对应类的全路径名称为属性名），然后将这些类作为配置类进行同样的解析，一些starter的定义就是使用这种方式（比如Druid数据源的starter），如下所示：

SPI

自动配置

druid数据源的starter

3、@Import(AutoConfigurationPackages.Registrar.class)，该Registrar是ImportSelector类型但不是延迟导入类型，so调用该类的registerBeanDefinitions方法进行注册BeanDefinition，比如Mybatis的注解@MapperScan：

@MapperScan注解

再来看@Import中的MapperScannerRegistrar，最终通过registerBeanDefinitions方法来对我们定义的Mapper/Dao进行扫描并注册BeanDefinition到BeanFactory中

MapperScannerRegistrar

通过对Springboot自动配置的的分析，我们就可以定义我们自己组件的starter了~~~

再次回顾下配置类的解析流程图吧：

配置类解析流程图

觉得可以的话点个关注，加个收藏呗，陆续奉上干货~~~~