《SpringBoot启动流程六》：SpringBoot自动装配时做条件装配的原理（万字图文源码分析）（含@ConditionalOnClass原理）

ゞ浴缸里的玫瑰 2023-09-29 14:55 27阅读 0赞

#### 文章目录 ####

*  一、前言
 *  二、入口
 *   *  第五步> getConfigurationClassFilter().filter(configurations) --> 过滤候选自动装配Class集合中不符合条件装配的Class成员：
     *   *  1）获取所有的Filter!\[在这里插入图片描述\](https://img-blog.csdnimg.cn/3cf78180eafe4dd2ba4c5fb371c2d2e9.png)
         *  2）执行条件装配
 *  三、条件装配原理
 *   *  1、OnClassCondition
     *   *  1）条件装配逻辑判断
     *  2、OnWebApplicationCondition
     *  3、OnBeanCondition
     *   *  1、验证加载自动装配类时@ConditionalOnBean注解是针对Class而不是Bean！!

## 一、前言 ##

我们前六篇博文，详细讨论了SpringBoot整个启动流程、自动装配。博文如下：

> 1> [《SpringBoot启动流程一》：万字debug梳理SpringBoot如何加载并处理META-INF/spring.factories文件中的信息][SpringBoot_debug_SpringBoot_META-INF_spring.factories]；  
> 2> [《SpringBoot启动流程二》：七千字源码分析SpringApplication构造阶段][SpringBoot_SpringApplication]；  
> 3> [《SpringBoot启动流程三》：两万+字图文带你debug源码分析SpringApplication准备阶段（含配置文件加载时机、日志系统初始化时机）][SpringBoot_debug_SpringApplication]；  
> 4> [《SpringBoot启动流程四》：图文带你debug源码分析SpringApplication运行阶段和运行后阶段][SpringBoot_debug_SpringApplication 1]。  
> 5> [《SpringBoot启动流程五》：你确定你真的知道SpringBoot自动装配原理吗（两万字图文源码分析）][SpringBoot_SpringBoot]。  
> 6> [SpringBoot自动装配机制原理][SpringBoot]。

在[《SpringBoot启动流程五》：你确定你真的知道SpringBoot自动装配原理吗（两万字图文源码分析）][SpringBoot_SpringBoot]一文中聊了`@EnableAutoConfiguration`，`@Import`注解是在何时被扫描的？所有的自动自动装配类是何时被扫描/加载的？也埋了一个坑：为什么127个自动装配类经过`AutoConfigurationImportFilter`过滤后只剩23个了？

本文我们就这个坑，聊一下Spring自动装配中自动装配类是如何实现条件装配的！！

注：Spring Boot版本：2.3.7.RELEASE。

## 二、入口 ##

![在这里插入图片描述][b335e62435774f9294627f5c5cf31390.png]  
接着上篇博文[《SpringBoot启动流程五》：你确定你真的知道SpringBoot自动装配原理吗（两万字图文源码分析）][SpringBoot_SpringBoot 1]中自动装配入口的代码执行流程图来看；核心在于`AutoConfigurationImportSelector`的`getAutoConfigurationEntry(AnnotationMetadata)`方法中。

其负责拿到所有自动配置的节点，大致分为六步；

> 1.  第一步，在`getCandidateConfigurations()`方法中利用Spring Framework工厂机制的加载器`SpringFactoriesLoader`，通过`SpringFactoriesLoader#loadFactoryNames(Class, ClassLoader)`方法读取所有`META-INF/spring.factories`资源中`@EnableAutoConfiguration`所关联的自动装配Class集合。
> 2.  第二步，利用Set不可重复性对`自动装配Class集合`进行去重，因为自动装配组件存在重复定义的情况；
> 3.  第三步，读取当前配置类所标注的@EnableAutoConfiguration注解的属性exclude和excludeName，并与`spring.autoconfigure.exclude`配置属性的值 合并为**自动装配class排除集合**。
> 4.  第四步，校验自动装配Class排除集合的合法性、并排除掉`自动装配Class排除集合`中的所有Class（不需要自动装配的Class）。
> 5.  第五步，再次过滤后候选自动装配Class集合中不符合条件装配的Class成员；
> 6.  最后一步，触发自动装配的导入事件。

### 第五步> getConfigurationClassFilter().filter(configurations) --> 过滤候选自动装配Class集合中不符合条件装配的Class成员： ###

**这里分两步：**

#### 1）获取所有的Filter![在这里插入图片描述][3cf78180eafe4dd2ba4c5fb371c2d2e9.png] ####

首先通过`getConfigurationClassFilter()`方法从所有`META-INF/spring.factories`文件中获取所有的自动装配过滤器`AutoConfigurationImportFilter`的实现类（一共有三个），然后实例化`AutoConfigurationImportSelector`类的内部类`ConfigurationClassFilter`，并将获取多的所有`AutoConfigurationImportFilter`的实现类集合赋值到ConfigurationClassFilter的`filters`属性中（后面会用到它做条件装配）。  
![在这里插入图片描述][e76a6dee7b884e11961dd9147070bb11.png]

#### 2）执行条件装配 ####

然后对获取到的所有自动装配类（最干净、最简单的SpringBoot程序有127个）执行过滤操作（条件装配）后，还剩23个自动装配类。  
![在这里插入图片描述][02ca81b04bbd49cea19508cfd0a6292d.png]  
那么是如何做的条件装配呢？

## 三、条件装配原理 ##

![在这里插入图片描述][8dab334a9c6d4168bd096483a9b70d58.png]  
首先遍历在`getConfigurationClassFilter()`方法中获取到的三个过滤器：OnClassCondition、OnWebApplicationCondition、OnBeanCondition；分别执行他们的`match()`方法做条件装配，最后将符合条件的结果放入到一个List集合中返回。

下面以实际样例来看一下，这三个过滤器是如何对自动装配类做条件装配的？  
![在这里插入图片描述][93883ead056643c2a333948f22b27767.png]  
无论是OnClassCondition、OnWebApplicationCondition 还是OnBeanCondition他们都继承自`FilteringSpringBootCondition`类，并且它们三个之中都没有重写`FilteringSpringBootCondition`\#`match(String[], AutoConfigurationMetadata)`方法，所以条件装配判定逻辑的入口统一为`FilteringSpringBootCondition`\#`match(String[], AutoConfigurationMetadata)`：  
![在这里插入图片描述][c7716a91a01c4a72ac4f79cdacdfe6a2.png]  
其中调用的getOutcomes(String\[\],AutoConfigurationMetadata)方法里针对不同的`FilteringSpringBootCondition`子类而实现逻辑不同，下面分开看一下。

### 1、OnClassCondition ###

OnClassCondition\#getOutComs()方法代码执行流程如下：  
![在这里插入图片描述][c34a9d93145b422a9a42ed929a05153e.png]  
**`resolveOutcomesThreaded()`方法源码解释如下：**

private ConditionOutcome[] resolveOutcomesThreaded(String[] autoConfigurationClasses,
    		AutoConfigurationMetadata autoConfigurationMetadata) {
        
    	// 将自动装配类的条件装配一分为2进行处理，
    	int split = autoConfigurationClasses.length / 2;
    	// 这里会开启一个线程处理前半部分的自动装配类
    	OutcomesResolver firstHalfResolver = createOutcomesResolver(autoConfigurationClasses, 0, split,
    			autoConfigurationMetadata);
    	OutcomesResolver secondHalfResolver = new StandardOutcomesResolver(autoConfigurationClasses, split,
    			autoConfigurationClasses.length, autoConfigurationMetadata, getBeanClassLoader());
    	// 当前线程处理后半部分的自动装配类
    	ConditionOutcome[] secondHalf = secondHalfResolver.resolveOutcomes();
    	// 这里调用thread.join()方法等待上面开启的线程run()执行完毕（即：处理完前半部分自动装配类）
    	ConditionOutcome[] firstHalf = firstHalfResolver.resolveOutcomes();
    	// 最后将处理结果合并 并 返回。
    	ConditionOutcome[] outcomes = new ConditionOutcome[autoConfigurationClasses.length];
    	System.arraycopy(firstHalf, 0, outcomes, 0, firstHalf.length);
    	System.arraycopy(secondHalf, 0, outcomes, split, secondHalf.length);
    	return outcomes;
    }

这里挺有意思的，它首先将所有的自动装配类一分为二，前半部分开启一个线程进行处理、后半部分当前线程处理，**后半部分处理完之后，调用thread.join()等待thread.join()方法等待上面开启的线程run()执行完毕（即：处理完前半部分自动装配类）**。最后合并处理结果并返回。

**1> 创建线程处理前半部分自动装配类：**  
![在这里插入图片描述][5c5072ce02a547babab59a5739093f9f.png]  
**2> 处理后半部分自动装配类：**

从这里我们来看条件装配的细节；

#### 1）条件装配逻辑判断 ####

代码逻辑在OnClassCondition静态内部类`StandardOutcomesResolver#resolveOutcomes()`方法中：  
![在这里插入图片描述][69134696cd484f9aaa789f101b58fa98.png]  
在getOutcomes(String\[\],int,int,AutoConfigurationMetadata)方法中：

> 遍历传入的所有自动装配类名称；
> 
> 1.  首先获取自动装配类`autoConfigurationClass`上@ConditionalOnClass注解中的值；如果获取不到，继续下一个循环。
> 2.  获取到相应的类，则通过类加载机制判断其是否存在，如果能加载到则返回。。。。 否则返回null。这里使用类加载机制判断Class是否存在时，不会对Class执行初始化操作。

以`org.springframework.boot.autoconfigure.jmx.JmxAutoConfiguration`类为例，细看一下其@ConditionalOnClass条件装配逻辑；

![在这里插入图片描述][62938c6f27c04fde96575e9bb74c6171.png]  
JmxAutoConfiguration类上被`@ConditionalOnClass({ MBeanExporter.class })`注解标注，所以获取到的`candidates`局部变量值为：`MBeanExporter`。

接着来看如何判断MBeanExporter.class类是否存在，代码执行流程如下：  
![在这里插入图片描述][a6a4994b1c7c49119cdbebb43ffc8d02.png]  
代码流程解析：

> 1.  根据当前ClassLoader使用反射Class.forNam()加载类：如果能加载到，则给最上层的getOutComes(String)方法返回FALSE；如果加载不到返回一个`ConditionOutcome`对象，内容为：@ConditionalOnClass did not find required class ‘org.springframework.jms.core.JmsTemplate’。（JmsTemplate为某自动装配类，是一个变量）
> 2.  如果@ConditionalOnClass中存在多个Class，则for循环判断，只要有一个Class不存在，则直接返回返回一个`ConditionOutcome`对象，内容为：@ConditionalOnClass did not find required class ‘org.springframework.jms.core.JmsTemplate’。（JmsTemplate为某自动装配类，是一个变量）

就`JmxAutoConfiguration`而言，其可以被自动装配。  
![在这里插入图片描述][56acf64986de4666b47fa1a3b433a79d.png]  
最后返回到条件装配判定逻辑的入口统一`FilteringSpringBootCondition`\#`match(String[], AutoConfigurationMetadata)`的体现为：  
![在这里插入图片描述][9521cc7f29ac43fda99260cd439af4a9.png]  
就`JmxAutoConfiguration`而言，其在`String[] autoConfigurationClasses`数组中的下标位置为63，而返回的`boolean[] match`数组下标位置63处为TRUE，表示其可以被自动装配。

此外：SpringBoot提供了两个基于Class的条件注解：一个是@ConditionalOnClass(类加载器中存在指定的类)，另一个是@ConditionalOnMissingClass(类加载器中不存在指定的类)，@ConditionalOnClass条件装配的原理我们知道了，@ConditionalOnMissingClass我们同样也就知道了。区别在于@ConditionalOnMissingClass加载到类之后给最上层的getOutComes(String)方法返回TRUE。

OnClassCondition过滤完，候选的自动装配类还剩26个：  
![在这里插入图片描述][8bfb70979b9f4131bd0e66d7ad14e70f.png]  
继续进入第二个过滤器OnWebApplicationCondition开始第二轮过滤；

### 2、OnWebApplicationCondition ###

OnWebApplicationCondition的执行逻辑和OnClassCondition一样，区别在于：

> 1.  OnClassCondition判断的是@ConditionalOnClass注解，OnWebApplicationCondition判断的是@ConditionalOnWebApplication注解。
> 2.  OnClassCondition依靠类加载机制判断@ConditionalOnClass注解value属性中的Class是否存在；OnWebApplicationCondition同样也是依靠类加载机制，但是判断的内容要少很多，其仅仅判断<ANY、SERVLET、REACTIVE>三种应用类型对应的类是否存在。

就`org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration`而言：  
![在这里插入图片描述][673b41ae13f24ec9b1c1662e17fa6a22.png]  
其没被`@ConditionalOnWebApplication`注解标注，所以在`getOutcome(String type)`方法中直接返回null，否者需要走应用类型的判断逻辑。  
![在这里插入图片描述][fa52bb25bcfc44d7bd4eb9a21bb28b9d.png]  
上图的两个常量如下：

// SERVLET应用特有类
    private static final String SERVLET_WEB_APPLICATION_CLASS = "org.springframework.web.context.support.GenericWebApplicationContext";
    
    // Reactive应用特有类
    private static final String REACTIVE_WEB_APPLICATION_CLASS = "org.springframework.web.reactive.HandlerResult";

如果这两个类同时存在，优先走SERVLET应用类型，这个在之前的博文（[SpringBoot应用分类？][SpringBoot 1]）聊过。

最后`SpringApplicationAdminJmxAutoConfiguration`类可以被自动装配；  
![在这里插入图片描述][b7260528fa72409f8689da81d96dde68.png]

OnWebApplicationCondition过滤完，候选的自动装配类还剩24个：  
![在这里插入图片描述][f58bd144e82f4b59ad822b862b8e36f3.png]  
继续进入第三个过滤器OnBeanCondition开始第三轮过滤；

### 3、OnBeanCondition ###

OnBeanCondition\#`getOutcomes(String[],AutoConfigurationMetadata)`方法执行逻辑如下：

> 遍历所有的（24个）候选自动装配类；
> 
> 1.  首先获取自动装配类`autoConfigurationClass`上@OnBeanCondition注解中的值；如果获取不到，继续下一个循环。
> 2.  获取到相应的类，则通过类加载机制判断其是否存在，如果能加载到则返回。。。。 否则返回null。这里使用类加载机制判断Class是否存在时，不会对Class执行初始化操作。

以`org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration`类为例，细看一下其@OnBeanCondition条件装配逻辑；  
![在这里插入图片描述][aa3b8e24b9ee4b94936d6fbed08c4692.png]

CacheAutoConfiguration类上被`@ConditionalOnBean(CacheAspectSupport.class)`注解标注，所以获取到的`onBeanTypes`局部变量值为：`CacheAspectSupport`。

接着来看如何判断CacheAspectSupport类的Bean实例是否存在，代码执行流程如下：  
![在这里插入图片描述][934b12fc84324ec4b151407d64eaf4bf.png]

看到最后我人傻了，卧槽，这和我学的@ConditionalOnBean注解的含义不一样啊，它不是要判断指定的Class是否已经被实例化存在于Spring容器中吗？？

**但是从代码debug流程上来看它居然也是判断当前类加载器是否可以加载到Class类。**

就`CacheAutoConfiguration`而言，其可以被自动装配。  
![在这里插入图片描述][a733d8a27045455fb7d5db4f49edfa4a.png]  
最后返回到条件装配判定逻辑的入口统一`FilteringSpringBootCondition`\#`match(String[], AutoConfigurationMetadata)`的体现为：  
![在这里插入图片描述][9bac972a89a947cda59cf4dfa4b0ef8f.png]  
就`CacheAutoConfiguration`而言，其在`String[] autoConfigurationClasses`数组中的下标位置为4，而返回的`boolean[] match`数组下标位置4处为TRUE，表示其可以被自动装配。

#### 1、验证加载自动装配类时@ConditionalOnBean注解是针对Class而不是Bean！! ####

**但是从代码debug流程上来看@ConditionalOnBean居然也是判断当前类加载器是否可以加载到Class类。**

**虽然代码debug出来了，但我还是不敢相信！所以我要写个demo验证一下！！**

首先自定义一个自动装配类：TestSaintAutoConfiguration

@Configuration
    @ConditionalOnBean(MyConditionBean.class)
    public class TestSaintAutoConfiguration {
        
        static {
        
            System.out.println("TestSaintAutoConfiguration类自动装配了");
        }
    }

MyConditionBean类上不加任何注解，不让其注册到Spring容器中，仅使其可以在Class.forName时加载到。

public class MyConditionBean {
        
        public MyConditionBean() {
        
            System.out.println("MyConditionBean");
        }
    }

整体项目目录如下：  
![在这里插入图片描述][52f86bd56e8c4f80a03c1e57b13f458d.png]  
如何自定义自动装配类，参考博文：[SprinBoot自定义自动装配类与xxx-spring-boot-starter][SprinBoot_xxx-spring-boot-starter]。

经过上述过滤器过滤之后，我们的自动装配类`TestSaintAutoConfiguration`通过了过滤，”可以被自动装配“！！！  
![在这里插入图片描述][46a2ea21de5f4824b35b3265aa5c3f84.png]  
**呀，真的可以自动装配了耶！！**

**执行运行程序并将自动装配的信息打出来试试看呢！**

*  首先要在application.yml文件中增加配置`debug: true`，打印自动装配信息。

**控制台输出如下：**  
![在这里插入图片描述][751632e78c884d5480e70a648217670f.png]  
卧槽，卧槽，卧槽，不对呀！这里没自动装配`TestSaintAutoConfiguration`类啊。

**推测肯定后面又做了某些处理！！！**

代码一直往上返回，追到最上层获取所有自动装配类的地方 --> ConfigurationClassParser的内部类的`processGroupImports()`方法中：  
![在这里插入图片描述][81476f7e86194c7382920baac6aded2a.png]  
又进到了ConfigurationClassParser\#processConfigurationClass()方法中，你会发现这里`ConfigurationPhase`是`PARSE_CONFIGURATION`而不是`REGISTER_BEAN`也就意味着，这里依旧会跳过条件装配，继续解析流程，啊啊啊啊，到底在哪呢？（此时博主已即将崩溃，但是博主没放弃，又找了好久好久，终于找到了）。

回到处理自动装配的核心逻辑`ConfigurationClassPostProcessor`\#`processConfigBeanDefinitions(BeanDefinitionRegistry)`方法：  
![在这里插入图片描述][7109ce92919c4db88dce0aaff28bdbc5.png]

**关于@ConditionalOnBean的处理逻辑，下篇文章<《SpringBoot启动流程七》：@Conditional条件装配实现原理（待补充博文链接）>中再做讨论。**

下图为我们自定义的自动装配类`TestSaintAutoConfiguratioin`装配失败的表现：  
![在这里插入图片描述][92051fd0720e4558b3f8557c91f49851.png]

[SpringBoot_debug_SpringBoot_META-INF_spring.factories]: https://blog.csdn.net/Saintmm/article/details/124673268
[SpringBoot_SpringApplication]: https://blog.csdn.net/Saintmm/article/details/124686043
[SpringBoot_debug_SpringApplication]: https://blog.csdn.net/Saintmm/article/details/124741566
[SpringBoot_debug_SpringApplication 1]: https://blog.csdn.net/Saintmm/article/details/124779826
[SpringBoot_SpringBoot]: https://blog.csdn.net/Saintmm/article/details/124792341
[SpringBoot]: https://blog.csdn.net/Saintmm/article/details/123904258
[b335e62435774f9294627f5c5cf31390.png]: https://img-blog.csdnimg.cn/b335e62435774f9294627f5c5cf31390.png
[SpringBoot_SpringBoot 1]: https://www.baidu.com
[3cf78180eafe4dd2ba4c5fb371c2d2e9.png]: https://img-blog.csdnimg.cn/3cf78180eafe4dd2ba4c5fb371c2d2e9.png
[e76a6dee7b884e11961dd9147070bb11.png]: https://img-blog.csdnimg.cn/e76a6dee7b884e11961dd9147070bb11.png
[02ca81b04bbd49cea19508cfd0a6292d.png]: https://img-blog.csdnimg.cn/02ca81b04bbd49cea19508cfd0a6292d.png
[8dab334a9c6d4168bd096483a9b70d58.png]: https://img-blog.csdnimg.cn/8dab334a9c6d4168bd096483a9b70d58.png
[93883ead056643c2a333948f22b27767.png]: https://img-blog.csdnimg.cn/93883ead056643c2a333948f22b27767.png
[c7716a91a01c4a72ac4f79cdacdfe6a2.png]: https://img-blog.csdnimg.cn/c7716a91a01c4a72ac4f79cdacdfe6a2.png
[c34a9d93145b422a9a42ed929a05153e.png]: https://img-blog.csdnimg.cn/c34a9d93145b422a9a42ed929a05153e.png
[5c5072ce02a547babab59a5739093f9f.png]: https://img-blog.csdnimg.cn/5c5072ce02a547babab59a5739093f9f.png
[69134696cd484f9aaa789f101b58fa98.png]: https://img-blog.csdnimg.cn/69134696cd484f9aaa789f101b58fa98.png
[62938c6f27c04fde96575e9bb74c6171.png]: https://img-blog.csdnimg.cn/62938c6f27c04fde96575e9bb74c6171.png
[a6a4994b1c7c49119cdbebb43ffc8d02.png]: https://img-blog.csdnimg.cn/a6a4994b1c7c49119cdbebb43ffc8d02.png
[56acf64986de4666b47fa1a3b433a79d.png]: https://img-blog.csdnimg.cn/56acf64986de4666b47fa1a3b433a79d.png
[9521cc7f29ac43fda99260cd439af4a9.png]: https://img-blog.csdnimg.cn/9521cc7f29ac43fda99260cd439af4a9.png
[8bfb70979b9f4131bd0e66d7ad14e70f.png]: https://img-blog.csdnimg.cn/8bfb70979b9f4131bd0e66d7ad14e70f.png
[673b41ae13f24ec9b1c1662e17fa6a22.png]: https://img-blog.csdnimg.cn/673b41ae13f24ec9b1c1662e17fa6a22.png
[fa52bb25bcfc44d7bd4eb9a21bb28b9d.png]: https://img-blog.csdnimg.cn/fa52bb25bcfc44d7bd4eb9a21bb28b9d.png
[SpringBoot 1]: https://blog.csdn.net/Saintmm/article/details/123792591
[b7260528fa72409f8689da81d96dde68.png]: https://img-blog.csdnimg.cn/b7260528fa72409f8689da81d96dde68.png
[f58bd144e82f4b59ad822b862b8e36f3.png]: https://img-blog.csdnimg.cn/f58bd144e82f4b59ad822b862b8e36f3.png
[aa3b8e24b9ee4b94936d6fbed08c4692.png]: https://img-blog.csdnimg.cn/aa3b8e24b9ee4b94936d6fbed08c4692.png
[934b12fc84324ec4b151407d64eaf4bf.png]: https://img-blog.csdnimg.cn/934b12fc84324ec4b151407d64eaf4bf.png
[a733d8a27045455fb7d5db4f49edfa4a.png]: https://img-blog.csdnimg.cn/a733d8a27045455fb7d5db4f49edfa4a.png
[9bac972a89a947cda59cf4dfa4b0ef8f.png]: https://img-blog.csdnimg.cn/9bac972a89a947cda59cf4dfa4b0ef8f.png
[52f86bd56e8c4f80a03c1e57b13f458d.png]: https://img-blog.csdnimg.cn/52f86bd56e8c4f80a03c1e57b13f458d.png
[SprinBoot_xxx-spring-boot-starter]: https://blog.csdn.net/Saintmm/article/details/123829093
[46a2ea21de5f4824b35b3265aa5c3f84.png]: https://img-blog.csdnimg.cn/46a2ea21de5f4824b35b3265aa5c3f84.png
[751632e78c884d5480e70a648217670f.png]: https://img-blog.csdnimg.cn/751632e78c884d5480e70a648217670f.png
[81476f7e86194c7382920baac6aded2a.png]: https://img-blog.csdnimg.cn/81476f7e86194c7382920baac6aded2a.png
[7109ce92919c4db88dce0aaff28bdbc5.png]: https://img-blog.csdnimg.cn/7109ce92919c4db88dce0aaff28bdbc5.png
[92051fd0720e4558b3f8557c91f49851.png]: https://img-blog.csdnimg.cn/92051fd0720e4558b3f8557c91f49851.png