如果对各个bean加载到Spring临时容器beanDefinitionNames
和manualSingletonNames
的顺序控制不当,就可能会导致@ConditionalOnBean、@ConditionalOnMissingBean注解失效。
一、@ConditionalOnMissingBean 失效场景案例
1> 一个被@Component
注解和@ConditionalOnMissingBean(ClassC.class)
注解标注的ClassA:
package com.saint;
import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.stereotype.Component;
@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;
@Configuration
public class ClassB {
public ClassB() {
System.out.println("初始化了ClassB!!!");
}
@Bean
public ClassC getClassC() {
return new ClassC();
}
}
3> 普通的ClassC对象:
package com.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 容器中。
为什么会这样呢?
SpringBoot对配置类的处理分为两个阶段:配置类解析 和 Bean注册。
在配置类解析阶段会将所有被@Component衍生注解标注的类全部添加到Spring临时容器beanDefinitionNames
和manualSingletonNames
中,而其他的配置类(@Import、@Bean等导入的类)在此阶段完成后会临时存放在ConfigurationClassParser
对象的configurationClasses
映射(Map<ConfigurationClass, ConfigurationClass>)中,在Bean注册阶段才会把映射里所有的ConfigurationClass转为BeanDefinition注册到Spring容器中,并添加到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;
@Configuration
@ConditionalOnMissingBean(ClassC.class)
public class ClassA {
public ClassA() {
System.out.println("初始化了ClassA!");
}
}
2> 增加自动装配配置:
3> 注册Bean阶段时类的顺序如下:
4> 程序运行结果:
- ClassA没有被注册到Spring容器中。
这里ClassA在解析阶段一样的被启动类上的@ComponentScan扫描到,但由于它是自动配置类,被排除了(因此自动配置类不需要放在包扫描路径之外)。直到在处理延迟导入时才添加自动配置类,此时ClassA被添加进来,但它的位置在ClassB之后。在类注册阶段,先处理ClassB,处理ClassB时会处理它内部的@Bean方法并注册ClassC,等到处理ClassA时,已经不满足条件装配了。
四、总结
SpringBoot官网的JavaDoc强烈建议开发人员仅在自动装配中使用Bean Conditions条件注解。因为开发人员需要特别小心BeanDefinition的添加顺序,因为这些条件是依赖于迄今为止哪些bean已经被处理来评估的。