前言
前天一个单身同事说他脱单了,我问他女方是谁,哪里认识的,他不说,装高人,许久才告诉我说,他的对象是注入的,我悟了许久,原来是公司里面的女同事呀,我又问他我认不认识,他又不说,装大佬,许久才让我想想Springboot 里面的bean的加载顺序以及我啥时候入职的,在那一刻,我突然就紧张了。
我紧张,不是因为我猜到了他对象是谁,而是我好像不是特别理得清Springboot 里面的bean 的加载顺序,为了缓解我的紧张感,我赶紧去做了一下功课,才发现原来之前有写过一篇文章就能解释清楚这个事情,所以我拜读了自己曾经的作品后,结合了一个很哇塞的示例,想在这里再单独对Springboot 里面的bean的加载顺序,进行一个梳理。
Springboot 版本:2.7.6
正文
一. Bean的前世今生
通常说到Spring 里面的bean,大家都有自己的认知,按照大家的认知,可以把大家分类如下。
- 一年大头兵。知道bean 就是Spring为我们创建的一个对象;
- 二年大头兵。不但知道一年大头兵知道的一切,还知道bean 在被创建前,还经历过BeanDefinition;
- 三年大头兵。不但知道二年大头兵知道的一切,还知道bean 在成为BeanDefinition 前,还经历过ConfigurationClass。
其实吧,通常Spring 中的bean ,在真正成为一个bean 前,首先是会被解析为ConfigurationClass ,然后再基于ConfigurationClass 创建出BeanDefinition ,最后在容器初始化的时候,再由BeanDefinition 创建出我们的bean。
可能帅气的大聪明就有疑问了,我们关注bean 的今生就好了,为什么要去了解bean 的前世呢,确实,如果不想去理清bean 的加载顺序,那么是不需要去关注bean 的前世的,但是如果想理清bean 的加载顺序,那么bean 的前世就尤为重要了,特别是ConfigurationClass ,搞明白ConfigurationClass 怎么来的,再搞明白如何基于ConfigurationClass 得到BeanDefinition ,那bean 的加载顺序就十分的清楚了,这在我之前的那篇文章中是解释得很清楚的,但是那篇文章写得太长了,我估摸很多帅比是耐不住性子看完的,所以我就将ConfigurationClass 和BeanDefinition的加载用流程图的形式画了出来,我觉得帅比们肯定喜欢看图吧。
先看一下ConfigurationClass的加载流程图,如下所示。
可以发现把候选者创建为ConfigurationClass 然后添加到configurationClasses 中的过程是一个递归的过程,首先递归到的是初始配置对象 ,这个初始配置对象 在Springboot 中就是Springboot 的启动类,然后由初始配置对象 ,开枝散叶,把各种其它的候选者的ConfigurationClass 在递归的过程中都添加到configurationClasses 中,同时结合上图可以发现,不同类型的候选者的ConfigurationClass 添加到configurationClasses中是有先后顺序的,结合整个递归的流程,添加的先后顺序是如下的。
- 首先,由@Controller ,@Service ,@Repository ,@Component 和@Configuration 注解修饰的对象,和@Import注解间接或直接导入的对象;
- 其次,由自动装配机制加载的配置对象。
因为configurationClasses 是一个LinkedHashMap ,所以后续在遍历configurationClasses 时,先添加的会被先遍历到,这一点很重要。
现在拿到configurationClasses 了,再往后就是遍历configurationClasses ,然后解析每个ConfigurationClass 并得到相关的BeanDefinition,流程图如下所示。
上述流程就是按照ConfigurationClass 添加到configurationClasses 的先后顺序,依次遍历到每一个ConfigurationClass ,然后会判断这个ConfigurationClass 是否需要被跳过,这里判断的依据一般就是我们常使用的@ConditionalOnBean 和@ConditionalOnMissingBean 等Condition 相关注解,再然后就是把ConfigurationClass 自己注册为容器中的BeanDefinition 和把ConfigurationClass 对应的BeanMethod (由@Bean 注解修饰的方法)注解为容器中的BeanDefinition ,最后执行ConfigurationClass 对应的ImportBeanDefinitionRegistrar 的逻辑来向容器中注册BeanDefinition。
要特别关注,@ConditionalOnBean 和@ConditionalOnMissingBean 等Condition 相关注解生效的时间,就是在将ConfigurationClass 解析为BeanDefinition 的一开始,那么ConfigurationClass 被遍历到的顺序就尤为重要的,我们可以仔细想想,假设A 添加了@ConditionalOnBean(B.class) ,再假设A 的ConfigurationClass 又先于B 的ConfigurationClass 被添加到configurationClasses 中,那么A 的ConfigurationClass 就会被先遍历到,此时A 的ConfigurationClass 解析为BeanDefinition 的一开始,就会去判断B 的BeanDefinition 是否存在于容器中,在我们的假设场景下此时B 是不存在的,所以A 的ConfigurationClass 不会被加载为容器中的BeanDefinition ,如果想让A 的Condition 被满足,就需要让B 的ConfigurationClass 先于A的被加载。
到此,bean的前世今生,就介绍完毕了,稍微总结一下。
- bean 的前世其实是BeanDefinition;
- BeanDefinition 的前世其实是ConfigurationClass;
- 每个ConfigurationClass 会按照加载的先后顺序依次解析为BeanDefinition;
- 每个ConfigurationClass 在解析为BeanDefinition 时会先进行各种Condition判断;
- 所以ConfigurationClass 的加载顺序其实就影响bean的加载顺序。
- 由@Controller ,@Service ,@Repository ,@Component 和@Configuration 注解修饰的对象,和@Import 注解间接或直接导入的对象,其ConfigurationClass先加载;
- 自动装配机制加载的配置对象,其ConfigurationClass后加载;
- 每个ConfigurationClass 包含着自己的BeanMethod (由@Bean 注解修饰的方法)和ImportBeanDefinitionRegistrar (通过@Import注解导入的);
- ConfigurationClass 在解析为BeanDefinition 时,会遵循ConfigurationClass 自己本身,BeanMethod ,ImportBeanDefinitionRegistrar这样的顺序来解析。
二. Bean的加载示例
上面已经有理论知识了,下面来结合一个示例,来做一个验证。
示例工程结构如下所示。
further包下面的代码如下所示。
java
@ConditionalOnBean(MyController.class)
public class MyFurtherConfig {
public MyFurtherConfig() {
System.out.println();
}
@Bean
public MyFurtherService myFurtherService() {
return new MyFurtherService();
}
}
public class MyFurtherService {
public MyFurtherService() {
System.out.println();
}
}
origin包下面的代码,如下所示。
java
@Configuration
@Import({MyImportBeanDefinitionRegistrar.class,
MyImportSelector.class,
MySupport.class})
public class MyConfig {
public MyConfig() {
System.out.println();
}
@Bean
public MyDao myDao() {
return new MyDao();
}
}
public class MyController {
public MyController() {
System.out.println();
}
}
public class MyDao {
public MyDao() {
System.out.println();
}
}
public class MyImportBeanDefinitionRegistrar implements ImportBeanDefinitionRegistrar {
@Override
public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata,
BeanDefinitionRegistry registry) {
BeanDefinition beanDefinition = new RootBeanDefinition(MyController.class);
registry.registerBeanDefinition("myController", beanDefinition);
}
}
public class MyImportSelector implements ImportSelector {
@Override
public String[] selectImports(AnnotationMetadata importingClassMetadata) {
return new String[] {
"com.lee.ioc.order.further.MyFurtherConfig"
};
}
}
@Service
public class MyService {
public MyService() {
System.out.println();
}
}
public class MySupport {
public MySupport() {
System.out.println();
}
}
pom文件如下所示。
xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.7.6</version>
</parent>
<properties>
<maven.compiler.source>8</maven.compiler.source>
<maven.compiler.target>8</maven.compiler.target>
</properties>
<groupId>com.lee.ioc.order</groupId>
<artifactId>ioc-order</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>com.lee.ioc.order.starter</groupId>
<artifactId>ioc-order-starter</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
示例工程引入了一个提前写好的starter ,这个starter结构如下所示。
TestBean 和MyAutoConfig代码如下。
java
public class TestBean {
}
@Configuration
public class MyAutoConfig {
public MyAutoConfig() {
System.out.println();
}
@Bean
public TestBean testBean() {
return new TestBean();
}
}
spring.factories文件内容如下。
yaml
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.lee.ioc.order.starter.config.MyAutoConfig
pom文件如下所示。
xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.7.6</version>
</parent>
<properties>
<maven.compiler.source>8</maven.compiler.source>
<maven.compiler.target>8</maven.compiler.target>
</properties>
<groupId>com.lee.ioc.order.starter</groupId>
<artifactId>ioc-order-starter</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
通过在每个bean 的构造函数中打断点,可以知道这些bean 的加载顺序,以debug运行程序,可以得到如下的加载顺序(越靠上越先实例化)。
- MyConfig (由@Configuration注解修饰);
- MyService (由@Service注解修饰);
- MySupport (由@Import注解直接导入);
- MyDao (由@Bean注解修饰的方法导入);
- MyController (由ImportBeanDefinitionRegistrar导入)
- MyAutoConfig(由自动装配机制导入的配置对象);
- TestBean (由自动装配机制导入的配置对象里的@Bean注解修饰的方法导入)。
上述的结果是完全符合我们的理论推导的,但是好像漏了MyFurtherConfig 和MyFurtherService,搞明白为什么漏了,就算是明白本文的主旨了。
首先,MyFurtherConfig 是MyConfig 通过@Import 注解导入的ImportSelector 间接导入的配置对象,所以按照ConfigurationClass 的递归加载流程,我们可以确定,MyFurtherConfig 的ConfigurationClass 要先于MyConfig 的ConfigurationClass加载。
其次,MyController 是MyConfig 通过@Import 注解导入的ImportBeanDefinitionRegistrar 在执行逻辑时会导入的对象,而只有在将MyConfig 的ConfigurationClass 解析为BeanDefinition 时,才会执行到ImportBeanDefinitionRegistrar的逻辑。
所以,在将MyFurtherConfig 的ConfigurationClass 解析为BeanDefinition 时,MyConfig 的ConfigurationClass 还没有被解析为BeanDefinition ,从而对应的ImportBeanDefinitionRegistrar 也没有被执行,因此MyController 也没有被导入,最终导致MyFurtherConfig 的@ConditionalOnBean (MyController.class )条件不满足,则MyFurtherConfig 的ConfigurationClass 解析为BeanDefinition 的动作不会执行,进而也不会解析MyFurtherConfig 的BeanMethod ,现象就是MyFurtherConfig 和MyFurtherService都没有注册到容器中。
总结
Spring 或者说Springboot 中的bean 的加载顺序,是很容易被忽略的一个知识点,很多人也被那稍显复杂的源码劝退,从而只能去找相关的文章寻求答案,但很多讲bean 加载顺序的文章,给的结论太过草率,结论其实是有误的,而要真正理解bean的加载顺序,其实是需要理解两大块内容。
- ConfigurationClass 的加载顺序。因为ConfigurationClass 在解析为BeanDefinition 时,会遵循先加载先解析的规则,所以在不加其它Condition 条件时,先加载的ConfigurationClass ,就是会比后加载的ConfigurationClass 先一步执行到解析为BeanDefinition的逻辑;
- ConfigurationClass 解析为BeanDefinition 的步骤。ConfigurationClass 会先把自己解析为BeanDefinition ,然后如果有由@Bean 注解修饰的方式,则把由@Bean 注解对应的BeanDefinition 解析出来,最后如果还通过@Import 注解导入了ImportBeanDefinitionRegistrar ,则再执行ImportBeanDefinitionRegistrar 的逻辑来注册BeanDefinition。
所以bean 的加载顺序是一个有迹可循但是容易让人晕乎的知识点,但如果能够理解上面的ConfigurationClass 加载流程图和BeanDefinition 加载流程图,这个知识点其实就搞定百分之九十了,剩下百分之十,无非就是各种Condition条件的使用和控制自动装配类加载顺序的注解的使用,不知道这些知识其实对整体的理解是不构成影响的。