// 配置类
@Configuration
public class AppConfig {
@Bean
public User user1(){
return new User();
}
@Bean
public User user2(){
return new User();
}
}
上面的代码，通过启动测试类，会将user1和user2注入到容器，可以看到打印结果如下：
现在需要根据操作系统来进行条件注入，Windows系统下注入user1，Linux系统下注入user2，则需要实现Condition接口，并重写其matches方法来构造判断条件
- 实现Condition接口：Windows系统判断条件
// Windows系统判断条件
public class WindowsCondition implements Condition {
/**
-
@description TODO
-
@author ONESTAR
-
@date 2021/2/10 10:56
-
@param conditionContext:判断条件，能使用的上下问环境
-
@param annotatedTypeMetadata：注释信息
-
@throws
-
@return boolean
*/
public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) {
// 获取当前环境
Environment environment = conditionContext.getEnvironment();
// 判断是否是Windows系统
String property = environment.getProperty(“os.name”);
if (property.contains(“Windows”)){
return true;
}
return false;
}
}
- 实现Condition接口：Linux系统判断条件
// Linux系统判断条件
public class LinuxCondition implements Condition {
/**
-
@description 判断操作系统是否是Linux系统
-
@author ONESTAR
-
@date 2021/2/10 10:56
-
@param conditionContext
-
@param annotatedTypeMetadata
-
@throws
-
@return boolean
*/
public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) {
// 获取当前环境
Environment environment = conditionContext.getEnvironment();
// 判断是否是Linux系统
String property = environment.getProperty(“os.name”);
if (property.contains(“linux”)){
return true;
}
return false;
}
}
- 修改配置类，使用@Conditional注解进行条件注入，修改后如下
@Configuration
public class AppConfig {
// 如果WindowsCondition的实现方法返回true，则注入这个bean
@Conditional({WindowsCondition.class})
@Bean
public User user1(){
return new User();
}
// 如果LinuxCondition的实现方法返回true，则注入这个bean
@Conditional({LinuxCondition.class})
@Bean
public User user2(){
return new User();
}
}
这时我们再来运行启动类，默认情况下是Windows系统，可以看到，只有user1注入进去了，user2并没有注入
咱们通过idea配置来模拟改变运行环境：添加：-Dos.name=linux
改变运行环境后，咱们再来运行启动类，可以看到，此时注入的是user2：
三、源码追踪
参考：[https://www.jianshu.com/p/566f22bda03c](()
【1】ConditionEvaluator中matches方法
我们知道，spring通过实现Condition接口，并重写其matches方法来构造判断条件，可以从matches入手，查看源码，发现ConditionEvaluator中调用了matches这个方法
public boolean shouldSkip(@Nullable AnnotatedTypeMetadata metadata, @Nullable ConfigurationPhase phase) {
// 检查注解中是否包含@Conditional类型的注解
if (metadata != null && metadata.isAnnotated(Conditional.class.getName())) {
// 判断当前bean是解析还是注册
if (phase == null) {
// bean的注解信息封装对象是AnnotationMetadata类型并且，类上有@Component，@ComponentScan，@Import，@ImportResource，则表示为解析类型
return metadata instanceof AnnotationMetadata && ConfigurationClassUtils.isConfigurationCandidate((AnnotationMetadata)metadata) ? this.shouldSkip(metadata, ConfigurationPhase.PARSE_CONFIGURATION) : this.shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN);
} else {
List conditions = new ArrayList();
Iterator var4 = this.getConditionClasses(metadata).iterator();
// 从bean的注解信息封装对象中获取所有的Conditional类型或者Conditional的派生注解
while(var4.hasNext()) {
String[] conditionClasses = (String[])var4.next();
String[] var6 = conditionClasses;
int var7 = conditionClasses.length;
for(int var8 = 0; var8 < var7; ++var8) {
String conditionClass = var6[var8];
// 实例化Conditional中的条件判断类（Condition的子类）
Condition condition = this.getCondition(conditionClass, this.context.getClassLoader());
// 添加到条件集合中
conditions.add(condition);
}
}
// 根据Condition的优先级进行排序
AnnotationAwareOrderComparator.sort(conditions);
var4 = conditions.iterator();
Condition condition;
ConfigurationPhase requiredPhase;
do {
do {
if (!var4.hasNext()) {
return false;
}
condition = (Condition)var4.next();
requiredPhase = null;
// 如果是ConfigurationCondition类型的Condition
if (condition instanceof ConfigurationCondition) {
// 获取需要对bean进行的操作，是解析还是注册
requiredPhase = ((ConfigurationCondition)condition).getConfigurationPhase();
}
//(如果requiredPhase==null或者指定的操作类型是目前阶段的操作类型)并且不符合设置的条件则跳过
} while(requiredPhase != null && requiredPhase != phase);
} while(condition.matches(this.context, metadata));
return true;
}
} else {
return false;
}
}
ConditionEvaluator这个类的作用是评估一个加了Conditional注解的类是否需要跳过。通过类上面的注解来判断。该方法作用就是判断当前bean处于解析还是注册
- 如果处于解析阶段则跳过，如果处于注册阶段则不跳过。
- 其中
Condition的matches方法就起到了判断的是否符合的作用，进而判断是否跳过当前bean。
【2】ConfigurationClassPostProcessor的processConfigBeanDefinitions
还是通过查找ConditionEvaluator类的matches方法调用链的方式，发现最后都是在ConfigurationClassPostProcessor的processConfigBeanDefinitions中进行调用的。一共有两个调用的位置，这里用调用的位置的代码进行展示
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
List configCandidates = new ArrayList();
// 获取registry中定义的所有的bean的name
String[] candidateNames = registry.getBeanDefinitionNames();
…
do {
// 第一个会调用shouldSkip的位置，这里是解析能够直接获取的候选配置bean。可能是Component，ComponentScan，Import，ImportResource或者有Bean注解的bean
StartupStep processConfig = this.applicationStartup.start(“spring.context.config-classes.parse”);
parser.parse(candidates);
parser.validate();
// 获取上面封装已经解析过的配置bean的ConfigurationClass集合
Set configClasses = new LinkedHashSet(parser.getConfigurationClasses());
// 移除前面已经处理过的
configClasses.removeAll(alreadyParsed);
if (this.reader == null) {
this.reader = new ConfigurationClassBeanDefinitionReader(registry, this.sourceExtractor, this.resourceLoader, this.environment, this.importBeanNameGenerator, parser.getImportRegistry());
}
//第二个会调用shouldSkip的位置，这里是加载configurationClasse中内部可能存在配置bean，比如方法上加了@Bean或者@Configuration标签的bean
this.reader.loadBeanDefinitions(configClasses);
alreadyParsed.addAll(configClasses);
…
}
}