springboot自动装配原理的了解

欢迎打开这篇文章

EnableAutoConfiguration 自动装配
Starter组件, 开箱即用
Actuator 监控
Spring Boot Cli 为Spring Cloud 提供了Spring Boot 命令行功能

在Spring Boot中，不得不说的一个点是自动装配，它是starter的基础，也是Spring Boot的核心， 那什么叫自动装配？或者什么叫装配呢？

回顾一下Spring Framework，它最核心的功能是IOC和AOP， IoC容器的主要功能是可以管理对象的生命周期。也就是bean的管理。我们把Bean对象托管到Spring Ioc容器的这个过程称为装配，那什么是自动装配呢？

• 装配，装配什么？
• 自动，怎么自动？

1，spring中bean注入的三种形式

在开始之前，让我们先来看点简单的开胃菜：spring中bean注入的三种形式
首先我们先来一个Person类，这里为了篇幅长度考虑使用了lombok
如果你不知道lombok是什么，那就最好不要知道，加了几个注解之后我的pojo类Person就完成了

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Person {
    private String name;
    private Integer age;
    private Boolean sex;
}

在Spring中（不是Spring Boot），要实现bean的注入，我们有3种注入方式：

1.1setter注入

这是最基本的注入方式

首先我们创建applicationContext.xml文件，在里面加入：

<bean id="person" class="pojo.Person">
    <property name="name" value="giao"/>
    <property name="age" value="20"/>
    <property name="sex" value="true"/>
bean>

这里使用property为bean对象赋值
紧接着我们会在test包下写一个version1.TestVersion1类

/**
 * 第一种bean注入实现方式 - 在xml文件中直接配置属性
 */
public class TestVersion1 {
    @Test
    public void test(){
        ApplicationContext ca = new   ClassPathXmlApplicationContext("applicationContext.xml");
        Person person = ca.getBean("person", Person.class);
        System.out.println(person);
    }
}

这里我使用了ClassPathXmlApplicationContext来加载spring配置文件并且读取其中定义的bean，然后使用getBean方法使用id和类来获取这个Person的Bean对象，结果成功输出：

Person(name=giao, age=20, sex=true)

1.2构造器注入

接下我们采用构造器注入的方式，我们需要更改applicationContext.xml中的property为construct-arg

<bean id="person" class="pojo.Person">
    <constructor-arg index="0" type="java.lang.String" value="giao" />
    <constructor-arg index="1" type="java.lang.Integer" value="20"/>
    <constructor-arg index="2" type="java.lang.Boolean" value="true"/>
bean>

version2.TestVersion2内容不变：

/**
 * 第一种bean注入实现方式 - 在xml文件中直接配置属性
 */
public class TestVersion2 {
    @Test
    public void test(){
        ApplicationContext ca = new   ClassPathXmlApplicationContext("applicationContext.xml");
        Person person = ca.getBean("person", Person.class);
        System.out.println(person);
    }
}

依然输出正确结果

Person(name=giao, age=20, sex=true)

1.3属性注入

使用注解方式的属性注入Bean是比较优雅的做法
首先我们需要在applicationContext.xml中开启注解支持和自动包扫描：

<context:annotation-config />
<context:component-scan base-package="pojo"/>

在pojo类中对Person类加上@Component注解，将其标记为组件，并且使用@Value注解为各属性赋初值

@Component
public class Person {
    
    @Value("giao")
    private String name;
    @Value("20")
    private Integer age;
    @Value("true")
    private Boolean sex;
}

然后编写version3.TestVersion3

public class TestVersion3 {
    @Test
    public void test(){
        ApplicationContext ac = new ClassPathXmlApplicationContext("applicationContext.xml");
        Person person = ac.getBean("person", Person.class);
        System.out.println(person);
    }
}

运行也可以得到如下结果

Person(name=giao, age=20, sex=true)

---

2，Spring的两种配置方式

什么？还有什么？接下来我们来聊聊Spring的两种配置方式：基于XML的配置和基于JavaConfig类的配置方式，这对于理解SpringBoot的自动装配原理是非常重要的。
首先我们在Person的基础上再创建几个pojo类：这个Person有Car、有Dog

public class Car {
    private String brand;
    private Integer price;
}

public class Dog {
    private String name;
    private Integer age;
}

public class Person {
    private String name;
    private Integer age;
    private Boolean sex;
    private Dog dog;
    private Car car;
}

2.1基于xml的配置

接下来我们尝试使用xml配置方式来为一个Person注入

<bean id="person" class="pojo.Person">
    <property name="name" value="giao"/>
    <property name="age" value="20"/>
    <property name="sex" value="true"/>
    <property name="dog" ref="dog"/>
    <property name="car" ref="car"/>
bean>

<bean id="dog" class="pojo.Dog">
    <property name="name" value="旺财"/>
    <property name="age" value="5" />
bean>

<bean id="car" class="pojo.Car">
    <property name="brand" value="奥迪双钻"/>
    <property name="price" value="100000"/>
bean>

然后跟普通的Bean注入一样，使用ClassPathXmlApplicationContext来加载配置文件，然后获取Bean

/**
 * 使用XML配置
 */
public class TestVersion1 {
    @Test
    public void test(){
        ClassPathXmlApplicationContext ca = new ClassPathXmlApplicationContext("applicationContext.xml");
        Person person = ca.getBean("person", Person.class);
        System.out.println(person);
    }
}

输出结果如下：

Person(name=giao, age=20, sex=true, dog=Dog(name=旺财, age=5), car=Car(brand=奥迪双钻, price=100000))

2.2基于JavaConfig类的配置

想要成为JavaConfig类，需要使用@Configuration注解
我们新建一个包命名为config，在config中新增一个PersonConfig类

@Configuration
@ComponentScan
public class PersonConfig {

    @Bean
    public Person person(Dog dog, Car car){
        return new Person("giao", 20, true, dog, car);
    }

    @Bean
    public Dog dog(){
        return new Dog("旺财", 5);
    }

    @Bean
    public Car car(){
        return new Car("奥迪双钻", 100000);
    }
}

此时我们的XML配置文件可以完全为空了，此时应该使用AnnotationConfigApplicationContext来获取注解配置

/**
 * 使用JavaConfig配置
 */
public class TestVersion2 {
    @Test
    public void test(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PersonConfig.class);
        Person person = ac.getBean("person", Person.class);
        System.out.println(person);
    }
}

任然可以正确输出结果

Person(name=giao, age=20, sex=true, dog=Dog(name=旺财, age=5), car=Car(brand=奥迪双钻, price=100000))

---

3，BeanDefinition

AbstractBeanDefinition

是spring中所有bean的抽象定义对象，我把他叫做bean定义
当bean.class被JVM类加载到内存中时，会被spring扫描到一个map容器中：

BeanDefinitionMap

这个容器存储了bean定义，但是bean此时还没有进行实例化，在进行实例化之前，还有一个

BeanFactoryPostProcessor

可以对bean对象进行一些自定义处理
我们打开BeanFactoryProcessor这个接口的源码可以发现如下内容：

/*
* Modify the application context's internal bean factory after its standard
* initialization. All bean definitions will have been loaded, but no beans
* will have been instantiated yet. This allows for overriding or adding
* properties even to eager-initializing beans.
*/

在spring完成标准的初始化过程后，实现BeanFactoryPostProcessor接口的对象可以用于定制bean factory，所有的bean definition都会被加载，但是此时还没有被实例化。这个接口允许对一些bean定义做出属性上的改动。
简言之就是实现了BeanFactoryPostProcessor这个接口的类，可以在bean实例化之前完成一些对bean的改动。
大致流程我画了个图：

至此我们能说出自己的理解springIOC的本质

由BeanDefinitionMap、BeanFactoryPostProcessor、BeanPostProcessor、BeanMap等等容器共同组成、共同完成、提供依赖注入和控制反转功能的一组集合，叫IOC容器。

---

4，BeanDefinition结构

既然讲到了BeanDefinition，我们来看一下BeanDefinition里面究竟定义了些什么
看看AbstractBeanDefinition这个类，一探究竟：

  private volatile Object beanClass;


  private int autowireMode = AUTOWIRE_NO;


  private ConstructorArgumentValues constructorArgumentValues;

4.1 beanClass

这个属性决定了该Bean定义的真正class到底是谁，接下来我们来做点实验
我们定义两个Bean类，A和B

@Component
public class A {
    @Value("我是AAA")
    private String name;
}
@Component
public class B {
    @Value("我是BBB")
    private String name;
}

接下来我们实现上面的BeanFactoryPostProcessor接口，来创建一个自定义的bean后置处理器

/**
 * 自定义的bean后置处理器
 * 通过这个MyBeanPostProcessor来修改bean定义的属性
 */
public class MyBeanPostProcessor implements BeanFactoryPostProcessor {
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        GenericBeanDefinition defA = (GenericBeanDefinition) beanFactory.getBeanDefinition("a");
        System.out.println("这里是MyBeanPostProcessor，我拿到了：" + defA.getBeanClassName());
    }
}

最后在XML配置文件中开启包扫描

<context:component-scan base-package="pojo"/>
<context:annotation-config />

注意：这里不要使用JavaConfig类来配置bean，不然会报如下错误

ConfigurationClassBeanDefinition cannot be cast to org.springframework.beans.factory.support.GenericBeanDefinition

这个错误出自这一句：

GenericBeanDefinition defA = (GenericBeanDefinition) beanFactory.getBeanDefinition("a");

最后，我们创建一个测试类：

public class Test {
    @Test
    public void test(){
        ClassPathXmlApplicationContext ca = new ClassPathXmlApplicationContext("applicationContext.xml");
        A aaa = ca.getBean("a", A.class);
        System.out.println("最终拿到了==> " + aaa);
    }
}

测试运行！

这里是MyBeanPostProcessor，我拿到了：pojo.A
最终拿到了==> A(name=我是AAA, b=B(name=我是BBB))

可以看到MyBeanPostProcessor成功拿到了A的Bean定义，并且输出了提示信息
接下来让我们做点修改测试
我们在MyBeanPostProcessor中修改A的Bean对象，将A的beanClass修改为B.class

System.out.println("这里是MyBeanPostProcessor，我修改了："+ defA.getBeanClassName() + " 的class为 B.class");
// 把A的class改成B
defA.setBeanClass(B.class);

重新运行Test类，输出了一些信息后：报错了！

这里是MyBeanPostProcessor，我拿到了：pojo.A
这里是MyBeanPostProcessor，我修改了：pojo.A 的class为 B.class

BeanNotOfRequiredTypeException: 
 Bean named 'a' is expected to be of type 'pojo.A' but was actually of type 'pojo.B'

我要拿到一个A类对象，你怎么给我一个B类对象呢？这明显不对
综上所述，我们可以得出beanClass属性控制bean定义的类

4.2autowireMode

我们继续看第二个属性：autowireMode，自动装配模式
我们在AbstractBeanDefinition源码中可以看到：

private int autowireMode = AUTOWIRE_NO;

自动装配模式默认是AUTOWIRE_NO，就是不开启自动装配
可选的常量值有以下四种：不自动装配，通过名称装配，通过类型装配，通过构造器装配

• AUTOWIRE_NO
• AUTOWIRE_BY_NAME
• AUTOWIRE_BY_TYPE
• AUTOWIRE_CONSTRUCTOR

接下来我们来模拟一个自动装配场景，仍然是A和B两个类，现在在A类中添加B类对象

@Component
public class A {
    @Value("我是AAA")
    private String name;
    @Autowired
    private B b;
}

我们希望b对象能够自动装配，于是我们给他加上了@Autowired注解，其他的完全不变，我们自定义的MyBeanPostProcessor中也不做任何操作，让我们运行测试类：

这里是MyBeanPostProcessor，我拿到了：pojo.A
最终拿到了==> A(name=我是AAA, b=B(name=我是BBB))

自动装配成功了！我们拿到的A类对象里面成功注入了B类对象b
现在问题来了，如果我把@Autowired注解去掉，自动装配会成功吗？

这里是MyBeanPostProcessor，我拿到了：pojo.A
最终拿到了==> A(name=我是AAA, b=null)

必然是不成功的
但是我就是想要不加@Autowired注解，仍然可以实现自动装配，需要怎么做？
这时就要在我们的MyBeanPostProcessor中做文章了，加入如下内容：

defA.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_NAME);

再次输出结果试试

这里是MyBeanPostProcessor，我拿到了：pojo.A
最终拿到了==> A(name=我是AAA, b=B(name=我是BBB))

自动装配成功了！这次我们可没加@Autowired，在我们的自定义的bean后置处理器中设置了autowireMode属性，也实现了自动装配
综上，autowireMode属性是用来控制自动装配模式的，默认值是AUTOWIRE_NO，即不自动装配

4.3constructorArgumentValues

constructorArgumentValues的字面含义是构造器参数值
改变这个参数值，我们可以做到在实例化对象时指定特定的构造器
因为要研究构造器，只能先”忍痛“关掉lombok插件，手写一个pojo.Student类

/**
 * Student类
 */
@Component
public class Student {
    private String name;
    private Integer age;

    public Student() {
        System.out.println("==>使用空参构造器 Student()");
    }

    public Student(String name, Integer age) {
        this.name = name;
        this.age = age;
        System.out.println("==>使用双参数构造器 Student(String name, Integer age)");
    }
}

我们都知道，spring在实例化对象时使用的是对象的默认空参构造器：
我们新建一个测试方法test

@Test
public void test(){
    ApplicationContext ca = new ClassPathXmlApplicationContext("applicationContext.xml");
    Student student = ca.getBean("stu", Student.class);
    System.out.println("==>" + student);
}

运行得到如下结果

这里是MyBeanPostProcessor，我拿到了：pojo.Student
==>使用空参构造器 Student()
==>pojo.Student@402e37bc

可以看到，确实使用了空参构造器
但是如何指定（自定义）使用哪个构造器呢？我根本看不见摸不着，Spring全帮我做了，实在是太贴心了。
接下来就聊聊constructorArgumentValues的使用：
我们在MyBeanPostProcessor中加入如下内容，对获取到的pojo.Student的bean定义进行操作：

ConstructorArgumentValues args = new ConstructorArgumentValues();
args.addIndexedArgumentValue(0, "我指定的姓名");
args.addIndexedArgumentValue(1, 20);
defStu.setConstructorArgumentValues(args);

再次运行test

这里是MyBeanPostProcessor，我拿到了：pojo.Student
==>使用双参数构造器 Student(String name, Integer age)
==>pojo.Student@2f177a4b

可以看到这次使用了双参数构造器
有人会好奇ConstructorArgumentValues到底是个什么东西，我点进源码研究一番，结果发现这个类就是一个普通的包装类，包装的对象是ValueHolder，里面一个List一个Map
而ValueHolder这个对象继承于BeanMetadataElement，就是构造器参数的一个包装类型
通过这个例子我们可以看到ConstructorArgumentValues就是用来管控构造器参数的，指定这个值会在进行bean注入的时候选择合适的构造器。

---

5,装配对象

现在我们把目光放回到SpringBoot的自动装配上来，原来在真正进行bean实例化对象前，我们前面还有这些过程，尤其是存在使用后置处理器BeanFactoryPostProcessor来对bean定义进行各种自定义修改的操作。

经过上面我们漫长的探索过程，我们终于可以回到第一个问题：

自动装配的对象：Bean定义 （BeanDefinition）

---

6， My自动装配

看到这里又自然会产生疑问：不会吧，上面可都是自动装配啊，我在配置文件或者使用注解都配置了变量的值，然后加个@Autowired注解就OK了，spring也是帮我自动去装配。

再优化点，就可以把XML文件写成JavaConfig配置类，然后使用@Configuration注解，这样也能自动装配，这不样不是更舒服？

6.1自动装配（再次思考）

个人见解，上面的自动装配，我们至少要写一个配置文件，无论是什么形式，我们都至少需要一个文件把它全部写下来，就算这个文件的内容是固定的，但是为了装配这个对象，我们不得不写。

我们甚至都可以做成模板了，比如我自己在学习spring框架整合时，把经常写的都搞成了模板：

有了这些模板，我们只需要按照需求更改，就能用了。

这样做确实很巴适，可是对于越来越成型的项目体系，我们每次都进行一些重复操作，也会感到非常烦躁。而且面对这么多xml配置文件，实在是看都看不来。

于是我有了一个想法就是：

我一个配置文件都不想写，程序还能照样跑，我只关心有我需要的组件就可以了，我只需要关注我的目标就可以了，我想打开一个工程之后可以1秒进入开发状态，而不是花3小时写完配置文件（2.5小时找bug）希望有个东西帮我把开始之前的准备工作全做了，即那些套路化的配置，这样我随时来都可以进入开发。

说到这里，想必大家都懂了：SpringBoot

6.2 for example（举个粒子）手动狗头

来看看下面这个例子：

任然是老嘉宾 AB两个类，其中A类任然引用B类，我们给A类组件起id=“a”,B类组件起id=“b”

@Component("a")
public class A {
   @Value("我是AAA")
   private String name;
   @Autowired
   private B b;
}

@Component("b")
public class B {
   @Value("我是BBB")
   private String name;
}

可以看到我们使用了@Autowired注解来自动注入b，测试类如下：

@Test
public void test(){
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(MyAutoConfig.class);
A aaa = ac.getBean("a", A.class);
System.out.println(aaa);
}

细心的ren已经发现了：我们这里使用了AnnotationConfigApplicationContext这个JavaConfig配置类会使用到的加载类，于是我们顺利成章地点开它所加载的MyAutoConfig类文件

@Configuration
@MyEnableAutoConfig
public class MyAutoConfig {
    // bean 都去哪了 ???
}

为啥子? 我要声明的Bean对象都去哪了（注意：这里的applicationContext.xml是空的）？

让我们运行test：

A(name=我是AAA, b=B(name=我是BBB))

竟然运行成功！！！ 这是为啥呢

细心的ren已经发现了：@MyEnableAutoConfig是什么注解？我怎么没有这个注解，这个注解让他成功的？

点击@MyEnableAutoConfig源码查看

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(MyImportSelector.class)   // 导入bean定义
public @interface MyEnableAutoConfig {
}

so 你是用了@Import注解导入了Bean定义 注释都标记出来了

but，@Import导入bean定义是没错，但是它导入的是MyImportSelector这个bean，不是A也不是B啊… （留下悬念）

6.3@Import注解

import 注解是什么意思呢？ 联想到xml形式下有一个 形式的注解，就明白它的作用了。import就是把多个分来的容器配置合并在一个配置中。在JavaConfig中所表达的意义是一样的.
@Import的功能就是获取某个类的bean对象，如何使用如下

@Import(A.class)
@Import(MyImportBeanDefinitionRegister.class)
@Import(MyImportSelector.class)

6.3.1@Import(A.class)

第一种形式so easy
我们需要那个bean定义，直接import它的class就完事

6.3.2 @Import(MyImportBeanDefinitionRegister.class)

第二种形式 midding
传递一个bean定义注册器 该注册器内容如下

public class MyImportBeanDefinitionRegister implements ImportBeanDefinitionRegistrar {
    @Override
    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {
        
        RootBeanDefinition aDef = new RootBeanDefinition(A.class);
        registry.registerBeanDefinition("a", aDef);
        
    }
}

这个注册器实现了ImportBeanDefinitionRegistrar接口，并且重写了里面的registerBeanDefinitions方法

看他做了什么事：创建了一个新的bean定义，他的类型就是A，然后把这个bean定义注册到BeanDefinitionMap（还记得吧！）里面，key值我们可以人为设置，这里就设置成"a"

这样在传递一个注册器的时候，我们就可以把注册器中新增的bean定义注册进来使用

6.3.3 @Import(MyImportSelector.class)

可以看到，这种使用方式就是我们刚才的注解中使用的方式

他传递了一个叫MyImportSelector的类，这个类依然是我们自己定义的，具体内容如下：

public class MyImportSelector implements ImportSelector {
    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        // 导入配置类
        return new String[]{"config.MyConfig"};
    }
}

这个类实现了ImportSelector接口，并且重写了selectImports方法，返回一个字符串数组

可以看到，返回的字符串数组中是我们要导入类的全类名

这个Importer返回的类如果是组件bean对象，就会被加载进来使用；如果是一个配置类，就会加载这个配置类

第三种和第二种的区别是第三种可以一次性写很多类，而且比较简洁，只需要清楚类的全包名即可。而第二种方式需要自己清楚包类名，手动创建bean定义，然后手动加入BeanDefinitionMap。

6.4 例子的深入研究

进入MyImportSelector 可以发现

return new String[]{"config.MyConfig"};

然后我们找到config.MyConfig类，发现这个类竟然就是我们刚才写的JavaConfig版本的配置文件：

@Configuration
public class MyConfig {
    @Bean
    public A a(){
        return new A();
    }

    @Bean
    public B b(){
        return new B();
    }
}

加载这个MyConfig配置类，就相当于加载了A和B两个Bean定义

不会吧不会吧，兜兜转转又回到起点，麻了麻了 又加载这个配置文件，这是我自己写的

总结哈，我们的例子跑了这么多地方

6.5偷懒解决问题

感觉上面例子也没多大优化，为什么我更加懵逼了呢？
不但绕了一大圈，定义了好多新东西，最后又回到我写的javaConfig类，怎么说我还是再写javaconfig类

但是你仔细发现了没有：有了上面的机制，我只需要把JavaConfig类写一次，然后放在某个地方，在MyImportSelector中加入这个地方的全包名路径，下次用的时候直接导入最顶层的MyAutoConfig类，所有有关这个部件我需要的东西，就全部自动整理好了，甚至比鼠标点点点添加代码模板还要快！

我突然灵机一动，（喝口水淡定淡定）不知道你有了没有 。

如果你开始有点感觉了，内心由内而外就会提出另一个问题：我这样做确实可以提高效率，但是一段代码里写入我自己定制的内容，每次更改起来不是太费劲了吗？

想到这里，我就不禁回想起使用JDBC的时候，在代码里改SQL语句的痛苦了，那真是生不如死…这种情况就构成了硬编码的行为，是不不值得倡导的。

我们自然会想到：要是我创建一个配置文件properties来专门保存我这个需求所使用的bean对象，然后使用的时候在MyImportSelector中读取配置文件并且返回全包名，不就更加nice了吗？

于是MyImportSelector中的代码又改成了下面这样：

public class MyImportSelector implements ImportSelector {
    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
    
        Properties properties = MyPropertyReader.readPropertyForMe("/MyProperty.properties");
        String strings = (String) properties.get(MyEnableAutoConfig.class.getName());
       
        return new String[]{strings};
    }
}

其中MyPropertyReader是我们自己新创建的用于读取properties文件的工具类

之所以要自己再定义这样一个工具类，是为了以后在其中可以做一些其他操作（比如：去重、预检查）

public class MyPropertyReader {
    public static Properties readPropertyForMe(String path){
        Properties properties = new Properties();
        try(InputStream sin = MyPropertyReader.class.getResourceAsStream(path)){
            properties.load(sin);
        }catch (IOException e){
            e.printStackTrace();
            System.out.println("读取异常...");
        }
        return properties;
    }
}

我们的配置文件里面这么写：

anno.MyEnableAutoConfig=config.MyConfig

可以看到，key是注解@MyEnableAutoConfig的类名，也就是根据这个注解，就会导入后面的MyConfig这个Bean，这个Bean就是我们的配置文件

如此一来我们读取这个配置文件，然后加载跟这个注解名称相符的value（即JavaConfig配置文件），就相当于我们在代码里手写的"config.MyConfig"，只不过现在的形式已经发生了巨大的变化：我们添加或者删除一个配件，完全只需要修改MyProperty.properties这个配置文件就行了！

至此，无论是添加或者删除组件，无非是在配置文件中加上或者删除一行的问题了。

让我们在更新之后运行程序，可以看到成功拿到了配置文件的全类名

程序的运行自然也是没得问题的

A(name=我是AAA, b=B(name=我是BBB))

是不是突然感觉通透起来了，一下就贯通了，领悟了（没有那就多想想多操作试试）

---

7自动装配源码分析

终于来到了重头戏

前六节都是开胃菜，现在硬菜上场了 猜猜他是谁？
springboot

启动项目

正常启动了，我们首先从@SpringBootApplication开始下手

7.1@SpringBootApplication

可以发现@SpringBootApplication由多个注释组成

主要看以下三个

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan

@SpringBootConfiguration
先来看第一个

进入注释可以看到

原来你就是一个@Configuration啊，一个JavaConfig配置类

那我们使用JavaConfig不就是用来配置bean吗，所以有了这个注解之后我们可以在SpringBoot运行的主类中使用@Bean标签配置类了，如下图所示：

7.2@ComponentScan

ComponentScan这个注解是大家接触得最多的了，相当于xml配置文件中的context:component-scan。 它的主要作用就是扫描指定路径下的标识了需要装配的类，自动装配到spring的Ioc容器中。

标识需要装配的类的形式主要是：@Component、@Repository、@Service、@Controller这类的注解标识的类。

扫描范围：springboot主启动类的同级路径及子路径

7.3@EnableAutoConfiguration

来看这个注解，也是最核心的内容
了解了ImportSelector和ImportBeanDefinitionRegistrar后，对于EnableAutoConfiguration的理解就容易一些了
  它会通过import导入第三方提供的bean的配置类：AutoConfigurationImportSelector

进入@EnableAutoConfiguration

看图中红圈位置的注解：@Import(AutoConfigurationImportSelector.class)

是不是跟我们上面自己写的内容一样！

这里的作用便是导入了 AutoConfigurationImportSelector 这个类的bean定义

我们都知道，如果这个类实现了ImportSelector接口，那他肯定重写了一个方法，就是我们上面重写过的selectImports方法：

果然，在这个类里面确实有这个selectImports方法：

这个类我们当时返回的是什么？是一个字符串数组String[ ]，那这个类无论多么长，返回的肯定就是一个字符串数组

这个字符串数组存放的内容我们是否清楚呢？当然清楚了！我们返回的是要加载的Config配置文件的全包名，通过返回这个全包名，我们就能自动装配上这些配置文件下定义的bean对象，从而达到了自动装配的目的！

根据刚才我们自己实现的selectImports方法，我们是通过注解类的名字来查找，并且最终得到需要加载的Config类的全类名，最后返回的。

因此，这里必然有一个根据注解类名字来查找相应的Config文件的操作

我们继续反推，看到返回时的定义如下：

我们发现autoConfigurationEntry中保存着我们需要的配置信息，它是通过getAutoConfigurationEntry方法获取的，于是我们继续深入，进入getAutoConfigurationEntry方法

这一段代码真是把人难住了，好大一片，看的直接头秃

我们先想这个方法应该返回什么，根据我们前面的操作，这里应该返回一个类似于Entry的保存了我们需要的配置信息的对象

这个方法返回的是新建的AutoConfigurationEntry对象，根据最后一行的构造函数来看，给他了两个参数：

configurations, exclusions

configurations显然使我们需要的配置文件，也是我们最关心的，而exclusions字面意思是排除，也就是不需要的，那我们接下来应该关注configurations到底是怎么来的

根据我们前面的经验，我们是根据注解类名来从一个配置文件中读取出我们需要的Config配置类，这里configurations就代表了Config配置类，那么我们应该找到一个入口，这个入口跟注解相关，并且返回了configurations这个参数。

正如我们所料，这个方法的参数确实传递过来了一个东西，跟注解有关：

看见Annotation（注解）

根据这个，我们找到三行代码，范围再次缩小 马上吃鸡了hxd们撑住

此时再加上返回了configurations，我们最终确定了一行代码：

就是这个getCandidateConfigurations方法，符合我们的要求！

从字面意思上分析，获取候选的配置，确实是我们需要的方法

OK，让我们继续深入探究，进入这个方法：

这个方法是不是也似曾相识呢？我们之前写过一个专门用于读取配置文件的类MyPropertyReader，还记得吗？

如果你还记得的话，我们自己写的工具类里面也是一个静态方法readPropertyForMe来帮我读取配置文件

但是我们的配置文件路径一定是需要指定的，不能乱放。

从这个loadFactoryNames方法体来看，好像没有给他传递一个具体路径

但是从下面的Assert断言中，我们发现了玄机：

在META-INF/spring.factories文件中没有找到自动配置类Config，

根据我多年来柯南推论判断，他的这个配置文件就叫spring.factories，存放的路径是META-INF/spring.factories

于是我们打开spring boot自动装配的依赖jar包：

果然xiongshou只有一个那就是这个配置文件里的内容

搜嘎

本质上来说，其实EnableAutoConfiguration会帮助springboot应用把所有符合@Configuration配置都加载到当前SpringBoot创建的IoC容器，而这里面借助了Spring框架提供的一个工具类SpringFactoriesLoader的支持。以及用到了Spring提供的条件注解@Conditional，选择性的针对需要加载的bean进行条件过滤

到这里，自动装配到底是什么，应该比较清楚了，原来他是帮我们加载了各种已经写好的Config类文件，实现了这些JavaConfig配置文件的重复利用和组件化

7.4loadFactoryNames方法

学习到这里，不能放弃，加大力度，给爷冲！！！

我们还有最后一块（几块）面纱没有解开，现在还不能善罢甘休。

让我们进入loadFactoryNames方法：

这个方法非常简短，因为他调用了真正实现的方法：loadSpringFactories

这一行return代码我复制在下面：

loadSpringFactories(classLoader)
     .getOrDefault(factoryTypeName, Collections.emptyList());

可以分析得出：loadSpringFactories方法的返回值又调用了一个getOrDefault方法，这明显是一个容器类的方法，目的是从容器中拿点东西出来

就此推测：loadSpringFactories返回了一个包含我们需要的Config全类名（字符串）的集合容器，然后从这个集合容器中拿出来的东西就是我们的configurations

让我们看这个loadSpringFactories方法：

它确实返回了一个容器：Map 这个容器的类型是：MultiValueMap

这个数据结构就非常牛逼了，多值集合映射（我自己的瞎说的）简单来说，一个key可以对应多个value，根据他的返回值，我们可以看到在这个方法中一个String对应了一个List

那么不难想到MultiValueMap中存放的形式：是”注解的类名——多个Config配置类“ 让我们打个断点来验证一下：

果然是这样，并且@EnableAutoConfiguration注解竟然加载了多达124个配置类！

接下来我们继续思考：我们来的目的是获取configurations，所以无论你做什么，必须得读取配置文件，拿到configurations

于是我们在try方法体中果然发现了这个操作：

他获取了一个路径urls，那么这个路径是否就是我们前面验证的META-INF/spring.factories呢？

我们查看静态常量FACTORIES_RESOURCE_LOCATION的值

果真如此，bingo！继续往下看，果然他遍历了urls中的内容，从这个路径加载了配置文件：终于看到了我们熟悉的loadProperties方法！

那我们大概就知道了，他确实是通过找到路径，然后根据路径读取了配置文件，然后返回了读取的result

这就是loadFactoryNames方法的内部实现。

7.5cache探索

到这里有的人又要问了：是不是结束了？其实还远没有！

细心地朋友已经发现了玄机，隐藏在loadFactoryNames方法的开头和结尾：

这个返回的result好像并不是直接new出来的

它是从cache缓存中取出来的，

根据下面的if判断，如果从缓存中读取出来了result，并且result的结果不为空，就直接返回，不需要再进行下面的读写操作了，这样减少了磁盘频繁的读写I/O

同理，在我更新完所有的配置文件资源之后，退出时也要更新缓存

7.6getAutoConfigurationEntry再探

关键部分已经过去，让我们反过头来重新审视一下遗漏的内容：

还记得getAutoConfigurationEntry方法吗？

最后来研究一下这个类除了getCandidateConfigurations还干了哪些操作：

• removeDuplicates
• configurations.removeAll(exclusions)

可以看到，这里对加载进来的配置进行了去重、排除的操作，这是为了使得用户自定义的排除包生效，同时避免包冲突异常，在SpringBoot的入口函数中我们可以通过注解指定需要排除哪些不用的包：

如我不使用RabbitMQ的配置包，就把它的配置类的class传给exclude

@SpringBootApplication(exclude = {RabbitAutoConfiguration.class})

---

8,自动装配本质

个人见解（如有不妥，评论区指正，希望各位大佬来捞捞，菜菜）：

1，SpringBoot自动装配的本质就是通过Spring去读取META-INF/spring.factories中保存的配置类文件然后加载bean定义的过程。
2，如果是标了@Configuration注解，就是批量加载了里面的bean定义
3，如何实现”自动“：通过配置文件获取对应的批量配置类，然后通过配置类批量加载bean定义，只要有写好的配置文件spring.factories就实现了自动。

---

9总结

Spring Boot的自动装配特性可以说是Spring Boot最重要、最核心的一环，正是因为这个特性，使得我们的生产复杂性大大降低，极大地简化了开发流程，可以说是给我们带来了巨大的福音了