《SpringBoot系列十四》：@ConditionalOnBean、@ConditionalOnMissingBean注解居然失效了

《SpringBoot系列十四》：@ConditionalOnBean、@ConditionalOnMissingBean注解居然失效了

文章目录

​​一、前言​​​​二、@ConditionalOnMissingBean失效场景复现​​​​三、@ConditionalOnMissingBean失效原因分析​​

​​解决方案：​​

​​四、总结​​

一、前言

在上一篇博文（​​《SpringBoot系列十三》：图文精讲@Conditional条件装配实现原理​​​）中我们讨论了@Conditional条件装配的原理。其中会牵扯到各个bean加载到Spring临时容器​​beanDefinitionNames​​​和​​manualSingletonNames​​的顺序，如果对顺序的控制不当会导致@ConditionalOnBean、@ConditionalOnMissingBean注解失效。

条件装配的其他文章如下：

​​《SpringBoot系列十一》：精讲如何使用@Conditional系列注解做条件装配​​​​《SpringBoot系列十二》：如何自定义条件装配（由@ConditionalOnClass推导）​​​​《SpringBoot启动流程六》：SpringBoot自动装配时做条件装配的原理（万字图文源码分析）（含@ConditionalOnClass原理）​​

二、@ConditionalOnMissingBean失效场景复现

1> 一个被​​@Component​​注解和​​@ConditionalOnMissingBean(ClassC.class)​​注解标注的ClassA：

package com.saint;import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;import org.springframework.stereotype.Component;/** * @author Saint */@Component@ConditionalOnMissingBean(ClassC.class)public class ClassA { public ClassA() { System.out.println("初始化了ClassA!"); }}

2> 一个被​​@Configuration​​注解标注，其中有一个@Bean方法的ClassB：

package com.saint;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;/** * @author Saint */@Configurationpublic class ClassB { public ClassB() { System.out.println("初始化了ClassB!!!"); } @Bean public ClassC getClassC() { return new ClassC(); }}

3> 普通的ClassC对象：

package com.saint;/** * @author Saint */public class ClassC { public ClassC() { System.out.println("初始化了ClassC!!"); }}

期望的效果：

如果没有人注册了类型为ClassC的bean对象，就往Spring容器里注册一个类型为ClassA的bean对象；而ClassB对象中通过@Bean方法向Spring容器中注册了类型为ClassC的bean对象；按照正常的逻辑，并不会向Spring容器中注册ClassA对象。

实际效果：

从控制台的输出来看，实际上ClassA对象被注册到了Spring容器中；

三、@ConditionalOnMissingBean失效原因分析

结合我们对@ConditionalOnMissingBean的理解，很容易得到表面结论：在解析ClassA中的​​@ConditionalOnMissingBean(ClassC.class)​​注解时，ClassC还没有注册到Spring 容器中。

为什么会这样呢？

我们结合Spring Boot对ConfigurationClass配置类的处理过程来看一下，在博文（​​《SpringBoot系列十三》：图文精讲@Conditional条件装配实现原理​​）中我们聊过：SpringBoot对配置类的处理分为两个阶段：配置类解析 和 Bean注册。

在配置类解析阶段会将所有被@Component衍生注解标注的类全部添加到Spring临时容器​​beanDefinitionNames​​​和​​manualSingletonNames​​​中，而其他的配置类（@Import、@Bean等导入的类）在此阶段完成后会临时存放在​​ConfigurationClassParser​​​对象的​​configurationClasses​​映射（Map）中，在Bean注册阶段才会把映射里所有的ConfigurationClass转为BeanDefinition注册到BeanFactory的String集合类型的beanDefinitionNames成员中。如下代码块所示：

变量​​configClasses​​​ 的数据结构是 ​​LinkedHashSet​​，所以其排序规则就是先来的放前面。

所以在配置类解析阶段，ClassA已经放入到了Spring的临时容器​​beanDefinitionNames​​​和​​configurationClasses​​​映射中，ClassB放入到了​​configurationClasses​​映射中，ClassC还没有被解析出来。在配置类注册阶段，根据类所在包中的顺序，重新先将ClassA再次根据条件装配结果注入到Spring的临时容器​​beanDefinitionNames​​，然后才将ClassB注入到Spring的临时容器，再解析ClassB中的ClassC，并将其注入到Spring容器。

从上图可以看出，​​用户自定义的类​​​ 排在 ​​EnableAutoConfiguration自动配置加载的类​​ 的前面；

​​用户自定义的类​​之间的顺序是按照文件的目录结构从上到下排序，并且无法干预， @Order，Order接口，@AutoConfigureBefore，@AutoConfigureAfter，AutoConfigureOrder 在这里都是无效的；​​自动装配的类​​之间 可以使用 @Order，Order接口，@AutoConfigureBefore，@AutoConfigureAfter，AutoConfigureOrder 五种方式去改变加载的顺序。

解决方案：

结合上述最后注册Bean阶段时，类的排序规则，我们可以将ClassA当做自动装配类，这样在注册bean阶段，ClassA的处理也就处于 ​​在ClassB中处理@Bean方法将ClassC注册到Spring容器中​​​ 的处理之后，即ClassA中处理​​@ConditionalOnMissingBean(ClassC.class)​​注解时，ClassC对象已经处理完了。

1> 修改ClassA类：

package com.saint;import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;import org.springframework.context.annotation.Configuration;/** * @author Saint */@Configuration@ConditionalOnMissingBean(ClassC.class)public class ClassA { public ClassA() { System.out.println("初始化了ClassA!"); }}

2> 增加自动装配配置：

3> 注册Bean阶段类的顺序如下：

4> 程序运行结果：

ClassA没有被注册到Spring容器中。

四、总结

SpringBoot官网的JavaDoc强烈建议开发人员仅在自动装配中使用Bean Conditions条件注解。因为开发人员需要特别小心BeanDefinition的添加顺序，因为这些条件是依赖与迄今为止哪些bean已经被处理来评估的！

下一篇博文：我们详细讨论一下@Conditional条件装配时Condition的处理顺序。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。