文章目录

SpringBoot自动装配原理
- 1. 从调用SpringApplication构造器方法开始
- 2. 解析启动类
- 4.按需装配
- - 4.1 分析dubbo自动装配
- 5. 如果定义自己的starter
- 6. 面试答法

SpringBoot自动装配原理

之前面试被问到这个题目，只会答一些spi、@AutoConfigration注解、@Import之类的，感觉面试官并不是很满意，自己也还停留在八股文的水平，最近有时间了，仔细总结一下

1. 从调用SpringApplication构造器方法开始

以下源码分析基于springboot2.6.x

首先一切的开始都是从这个方法开始的SpringApplication.run()，所以说自动装箱的核心就是这个run方法的执行过程

首先我们应该带着问题看这个方法的执行

是否需要创建IOC容器，需要创建那些Bean
创建Bean之前的准备工作

最好的看源码的方式是通过debug的方式，我们在SpringApplication.run()上面打一个断点，然后一步一步的分析

首先第一步，SpringApplication.run()方法需要传入两个参数，第一个参数就是启动类本身，用于在之后解析启动类（解析标记的注解、启动类作为一个配置类，也需要解析），后面那个args是传入的虚拟机参数

再往下一层能够看到new SpringApplication(primarySources).run(args)，当我们看到new关键字的时候我们处了知道创建了一个对象之外，还应该注意到他调用了SpringApplication这个类的构造器，构造器一般会用来加载一些配置

启动类里面的这一行其实在表示当前Spring要用什么web方式，在JavaWeb开发中一般常用的就是Servlet程序，其实就对应着SpringMVC，Spring还提供了SpringWebflux来进行响应式响应式编程

/**
 * The application should not run as a web application and should not start an
 * embedded web server.
 */
NONE,
/**
 * The application should run as a servlet-based web application and should start an
 * embedded servlet web server.
 */
SERVLET,
/**
 * The application should run as a reactive web application and should start an
 * embedded reactive web server.
 */
REACTIVE;

接下来就是非常重要的两行代码了，这里就涉及到了spring.factories文件到底是怎么加载的问题了

一看名字就能看出来

设置初始化器
设置监听器

这里面的getSpringFactoriesInstances就是去加载spring.factories带给我们自动装箱的bean实例的

通过org.springframework.context.ApplicationContextInitializer来加载自动装箱文件

再然后获取spring.factories文件的资源路径

其实这个资源文件FACTORIES_RESOURCE_LOCATION也早已经定义好了

然后就到了加载配置文件里面配置好的bean了

接下来就是通过反射创建实例并返回的操作

到目前为止，其实还没有牵涉到自动装配的东西

2. 解析启动类

我们继续debug，直接到解析启动类的地方

org.springframework.boot.SpringApplication#prepareContext

看这里，就是去加载启动类

一路进入到这里

org.springframework.boot.BeanDefinitionLoader#load()

开始加载我们的启动类，可以看到其实我们的启动类可以定义不止一个，进入load方法

这里看到一个方法isEligible(source)，即有资格的的bean，这个方法在低版本的boot中是isComponent(source)，很好理解，即这个bean必须要被@Component标记才能被注册

准备工作完成之后接下来进入到我们非常重要的一个方法refreshContext(context)方法

接下来会落到这个方法里面

当我们在Spring源码中看到refresh方法的时候，其实我们应该知道这肯定跟SpringIOC容器有关了，我们在org.springframework.context.support.AbstractApplicationContext#refresh中其实能够看到13个方法，在Spring中所有带有refresh方法最终的实现基本上都是在这里

我们看到其中的一个方法postProcessBeanFactory(beanFactory)

这个方法就是做增强的，在Spring中看到postProcessBean开头的方法，我们一般喜欢将其称之为后置增强器

我们来到这里，其中configCandidates用来存放启动类

org.springframework.context.annotation.ConfigurationClassPostProcessor#processConfigBeanDefinitions

在这里会去找到所有匹配的能够被解析的类，可以看到已经拿到我们的启动类了

继续往下，我们就能看到解析启动类的地方

-> org.springframework.context.annotation.ConfigurationClassParser#processConfigurationClass
-> org.springframework.context.annotation.ConfigurationClassParser#doProcessConfigurationClass

我们来看一下解析@Import注解的地方，因为在实际开发中自动装箱我们用这个注解比较多

    org.springframework.context.annotation.ConfigurationClassParser#collectImports

在这里的方法中递归解析

拿到import注解后我们在来到这里org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.AutoConfigurationGroup#process

然后再到这里面就会去加载spring.factories文件了

SpringBoot 定义了一套接口规范，这套规范规定：SpringBoot 在启动时会扫描外部引用 jar 包中的META-INF/spring.factories文件，将文件中配置的类型信息加载到 Spring 容器

org.springframework.core.io.support.SpringFactoriesLoader#loadSpringFactories

比较精彩的一点是他会去拿一下之前已经加载过的缓存，避免重复加载

当然也不会全部加载进去，如果项目中没有依赖，会将这些bean排除掉

那么到底哪些bean会被加载？哪些bean会被过滤掉呢？我们继续往下看

4.按需装配

那么面试官可能会问：怎么排除META-INF/spring.factories里不需要的bean呢？

我们可以在springboot官网上找到答案

我们的自动装配依赖条件注解，来判断哪些bean需要加载进入IOC容器，这一类条件注解一般是以@Conditional开头

4.1 分析dubbo自动装配

我们来看一下dubbo所依赖的bean是如何自动装配到ioc容器中的

首先我们需要引入dubbo的starter

<!-- dubbo -->
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>3.0.7</version>
</dependency>

<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-dependencies-zookeeper-curator5</artifactId>
    <version>${dubbo.version}</version>
    <type>pom</type>
</dependency>

既然是一个starter，肯定得准守springboot约定大于配置的约定，在对应的jar包下一定有个**META-INF/spring.factories**文件

在org.springframework.core.io.support.SpringFactoriesLoader#loadSpringFactories方法加载完毕后，这些配置的bean就会通过反射进行加载

我们分析一下这个bean，点进去进行查看

但是当我们去查看最终注入到ioc容器里的bean的时候，却没有发现这些bean，甚至一个关于dubbo的bean都没有

这是因为我们的项目中并没有添加对dubbo的条件注解，没有按需进入注入

这时候其实我们需要的是添加条件注解

可以看到，当项目中有条件注解时，才能加入到ioc容器

5. 如果定义自己的starter

定义的步骤在springboot官网上非常详细

Createing Your Own Auto-configuration

6. 面试答法

首先自动装配中最重要的三个类，回答的时候要沿着这三个方法去回答

BFPP: BeanFactoryPostProcessor
BPP: BeanPostProcessor
BDRPP：BeanDefinitionRegistryPostProcessor

第一步：自动装配是什么？解决了那些问题

第二步：自动装配的过程

当启动springboot应用程序的时候，会先创建SpringApplication的对象，在对象的构造方法中会进行某些参数的初始化工作，最主要的是判断当前应用程序的类型以及初始化器和监听器，在这个过程中会加载整个应用程序中的spring.factories文件，将文件的内容放到缓存对象中，方便后续获取。
SpringApplication对象创建完成之后，开始执行run方法，来完成整个启动，启动过程中最主要的有两个方法，第一个叫做prepareContext，第二个叫做refreshContext,在这两个关键步骤中完整了自动装配的核心功能，前面的处理逻辑包含了上下文对象的创建，banner的打印，异常报告期的准备等各个准备工作，方便后续来进行调用。
在prepareContext方法中主要完成的是对上下文对象的初始化操作，包括了属性值的设置，比如环境对象，在整个过程中有一个非常重要的方法，叫做load，load主要完战一件事，将当前启动类做为一个beanDefinition注册到registry中，方便后续在进行BeanFactoryPostProcessor调用执行的时候，找到对应的主类，来完成@SpringBootApplicaiton，@EnableAutoConfiguration等注解的解析工作
在refreshContext方法中会进行整个容器刷新过程，会调用中spring中的refresh方法，refresh中有13个非常关键的方法，来完成整个spring应用程序的启动，在自动装配过程中，会调用invokeBeanFactoryPostProcessor方法，在此方法中主要是对ConfigurationClassPostProcessor类的处理，这次是BFPP的子类也是BDRPP的子类，在调用的时候会先调用BDRPP中的postProcessBeanDefinitionRegistry方法，然后调用postProcessBeanFactory方法，在执行postProcesskeanDefinitionRegistry的时候回解析处理各种注解，包含@PropertySource，@ComponentScan，@ComponentScans，@Bean，@lmport等注解，最主要的是import注解的解析
在解析@lmport注解的时候，会有一个getlmports的方法，从主类开始递归解析注解，把所有包含@lmport的注解都解析到，然后在processlmport方法中对Import的类进行分类，此处主要识别的时候AutoConfigurationlmportSelect归属于ImportSelect的子类，在后续过程中会调用deferredlmportSelectorHandler中的process方法，来完整EnableAutoConfiguration的加载。
通过@Conditional等条件注解按需加载的配置类，其他的将被过滤掉

最后一句话总结：Spring Boot 通过@EnableAutoConfiguration开启自动装配，通过 SpringFactoriesLoader 最终加载META-INF/spring.factories中的自动配置类实现自动装配，自动配置类其实就是通过@Conditional按需加载的配置类，想要其生效必须引入spring-boot-starter-xxx包实现起步依赖