@Conditional注解 -【Spring底层原理】

2401_85767411

于 2024-06-17 15:13:37 发布

阅读量458

点赞数 4

文章标签： spring java 后端

本文链接：https://blog.csdn.net/2401_85767411/article/details/139744984

版权

案例已上传GitHub，欢迎star以鼓励：https://github.com/oneStarLR/spring-annotation

一、注解用法

@Conditional是Spring4新提供的注解，也是用来注册bean的，作用如下：

按照一定的条件进行判断，满足条件的给容器注册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接口中，我们可以获取上下文环境，从而进行判断，达到条件判断的作用

二、实例分析

通过实例来进行分析，以不同的操作系统为条件，通过实现Condition接口，并重写其matches方法来构造判断条件，通过idea配置来改变操作系统环境，将注入的bean进行打印来进行判断。

// 启动类

@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注入到容器，可以看到打印结果如下：

现在需要根据操作系统来进行条件注入，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 {

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);

…

}

通过parse方法解析BeanDefinitionRegistry中能直接获取到的候选bean，并解析保存到ConfigurationClassParser类的保存解析过的配置类的集合configurationClasses中

loadBeanDefinitions则是对上面解析的集合configurationClasses中的bean内部的进一步的处理，处理类内部定义的bean

【3】ConfigurationClassParser的parse方法

public void parse(Set 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 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方法得到匹配结果