案例已上传GitHub,欢迎star以鼓励:github.com/oneStarLR/s…java
@Conditional是Spring4新提供的注解,也是用来注册bean的,做用以下:linux
- 按照必定的条件进行判断,知足条件的给容器注册bean
- 从源码中咱们能够看到,能够做用在类和方法上
- 须要传入一个Class数组,并继承Condition接口
// 能够做用在类上,也能够做用在方法上
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Conditional {
// 须要传入一个Class数组
Class<? extends Condition>[] value();
}
// 继承Condition接口
@FunctionalInterface
public interface Condition {
boolean matches(ConditionContext var1, AnnotatedTypeMetadata var2);
}
复制代码
在继承Condition接口中,咱们能够获取上下文环境,从而进行判断,达到条件判断的做用git
经过实例来进行分析,以不一样的操做系统为条件,经过实现Condition接口,并重写其matches方法来构造判断条件,经过idea配置来改变操做系统环境,将注入的bean进行打印来进行判断。github
// 启动类
@Test
public void TestMain(){
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
String[] beanNames = applicationContext.getBeanDefinitionNames();
for (String beanName : beanNames) {
System.out.println(beanName);
}
}
// User
public class User {
}
// 配置类
@Configuration
public class AppConfig {
@Bean
public User user1(){
return new User();
}
@Bean
public User user2(){
return new User();
}
}
复制代码
上面的代码,经过启动测试类,会将user1和user2注入到容器,能够看到打印结果以下:spring
如今须要根据操做系统来进行条件注入,Windows系统下注入user1,Linux系统下注入user2,则须要实现Condition接口,并重写其matches方法来构造判断条件数组
// 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;
}
}
复制代码
// 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;
}
}
复制代码
@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并无注入markdown
我们经过idea配置来模拟改变运行环境:添加:-Dos.name=linuxapp
改变运行环境后,我们再来运行启动类,能够看到,此时注入的是user2:ide
【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<Condition> 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<BeanDefinitionHolder> 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<ConfigurationClass> 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);
......
}
}
复制代码
- 经过
parse
方法解析BeanDefinitionRegistry
中能直接获取到的候选bean,并解析保存到ConfigurationClassParser
类的保存解析过的配置类的集合configurationClasses
中loadBeanDefinitions
则是对上面解析的集合configurationClasses
中的bean内部的进一步的处理,处理类内部定义的bean
【3】ConfigurationClassParser
的parse
方法
public void parse(Set<BeanDefinitionHolder> configCandidates) {
Iterator var2 = configCandidates.iterator();
while(var2.hasNext()) {
BeanDefinitionHolder holder = (BeanDefinitionHolder)var2.next();
BeanDefinition bd = holder.getBeanDefinition();
try {
if (bd instanceof AnnotatedBeanDefinition) {
this.parse(((AnnotatedBeanDefinition)bd).getMetadata(), holder.getBeanName());
} else if (bd instanceof AbstractBeanDefinition && ((AbstractBeanDefinition)bd).hasBeanClass()) {
this.parse(((AbstractBeanDefinition)bd).getBeanClass(), holder.getBeanName());
} else {
this.parse(bd.getBeanClassName(), holder.getBeanName());
}
} catch (BeanDefinitionStoreException var6) {
throw var6;
} catch (Throwable var7) {
throw new BeanDefinitionStoreException("Failed to parse configuration class [" + bd.getBeanClassName() + "]", var7);
}
}
this.deferredImportSelectorHandler.process();
}
protected final void parse(@Nullable String className, String beanName) throws IOException {
Assert.notNull(className, "No bean class name for configuration class bean definition");
MetadataReader reader = this.metadataReaderFactory.getMetadataReader(className);
this.processConfigurationClass(new ConfigurationClass(reader, beanName), DEFAULT_EXCLUSION_FILTER);
}
protected final void parse(Class<?> clazz, String beanName) throws IOException {
this.processConfigurationClass(new ConfigurationClass(clazz, beanName), DEFAULT_EXCLUSION_FILTER);
}
protected final void parse(AnnotationMetadata metadata, String beanName) throws IOException {
this.processConfigurationClass(new ConfigurationClass(metadata, beanName), DEFAULT_EXCLUSION_FILTER);
}
复制代码
在
ConfigurationClassParser
的parse
方法中有三个分支,分别是对不一样类型的BeanDefinition
进行解析,这里进入AnnotatedBeanDefinition
类型的。
【4】调用processConfigurationClass
方法
进入到parse
方法后在进入里面调用的processConfigurationClass
方法,查看源码,这里就是对Conditional注解的做用了
protected void processConfigurationClass(ConfigurationClass configClass, Predicate<String> filter) throws IOException {
// 检查当前解析的配置bean是否包含Conditional注解,若是不包含则不须要跳过
// 若是包含了则进行match方法获得匹配结果
if (!this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)) {
ConfigurationClass existingClass = (ConfigurationClass)this.configurationClasses.get(configClass);
if (existingClass != null) {
if (configClass.isImported()) {
if (existingClass.isImported()) {
existingClass.mergeImportedBy(configClass);
}
return;
}
this.configurationClasses.remove(configClass);
this.knownSuperclasses.values().removeIf(configClass::equals);
}
ConfigurationClassParser.SourceClass sourceClass = this.asSourceClass(configClass, filter);
do {
sourceClass = this.doProcessConfigurationClass(configClass, sourceClass, filter);
} while(sourceClass != null);
this.configurationClasses.put(configClass, configClass);
}
}
复制代码
这里就是对是否跳过bean解析的位置
- 检查当前解析的配置bean是否包含Conditional注解,若是不包含则不须要跳过
- 若是包含了则进行match方法获得匹配结果,若是是符合的而且设置的配置解析策略是解析阶段不须要调过
@Conditional
注解主要经过指定的Condition
实现类实现matches
方法来决定是否须要进行解析,总结以下:
Condition
接口,并重写其matches
方法来构造判断条件ConditionEvaluator
中matches
方法判断当前bean处于解析仍是注册,若是处于解析阶段则跳过,若是处于注册阶段则不跳过processConfigurationClass
方法判断当前解析的配置bean是否包含Conditional注解,若是不包含则不须要跳过,包含了则进行match方法获得匹配结果