重读Spring系列-Conditional注入Bean的判断

Posted 2021-06-27 _微风轻起

这一篇我们要梳理的主要是关于注入Bean的条件判断，只有满足对应的条件才注入对应的BeanDefinition。关于注入的条件判断目前我们知道是有3个地方，其中两个都是使用的ConditionEvaluator处理，另外一个是我们的上一篇提到的AutoConfigurationImportFilter。下面我们就按顺序来依次梳理。建议看下前两篇

一、@Conditional

1、结构

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Conditional {

   Class<? extends Condition>[] value();

}

​ 首先我们需要了解这个注解，这个注解就是用来条件判断的，只有满足条件(通过value导入的继承Condition接口的类来判断)，才导入这个Bean。下面我们通过一个spring源码中的demo来看下这个注解的具体配套使用。

2、demo1

@Configuration
@Conditional(NoBeanOneCondition.class)
static class BeanTwoConfiguration {

   @Bean
   public ExampleBean bean2() {
      return new ExampleBean();
   }
}

​ 这个配置类BeanTwoConfiguration，我们可以看到其本身是要注入bean2()(ExampleBean)的，但其加了一个@Conditional(NoBeanOneCondition.class)，就是说这个配置类能不能注入，需要看NoBeanOneCondition的判断。

static class NoBeanOneCondition implements Condition {

   @Override
   public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
      return !context.getBeanFactory().containsBeanDefinition("bean1");
   }
}

​ 这个判断就是看当前Bean工厂中有没有名称为bean1的BeanDefiniton，如果没有就返回true，这样就会注入BeanTwoConfiguration以此来注入其中的ExampleBean。

@Test
public void conditionalOnMissingBeanNoMatch() throws Exception {
   AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
   ctx.register(BeanTwoConfiguration.class);
   ctx.refresh();
   assertFalse(ctx.containsBean("bean1"));
   assertTrue(ctx.containsBean("bean2"));
   assertTrue(ctx.containsBean("configurationClassWithConditionTests.BeanTwoConfiguration"));
}

​ 这个就是测试类，可以看到其只ctx.register(BeanTwoConfiguration.class)，即只注入了BeanTwoConfiguration，就还没有bean1，所以这里就会成功注入bean2(ExampleBean)。

3、demo2

在上面的demo1基础上，我们来看下另一种情况：

@Configuration
static class BeanOneConfiguration {

   @Bean
   public ExampleBean bean1() {
      return new ExampleBean();
   }
}

​ 这个BeanOneConfiguration就是注解注入bean1，然后看测试类：

@Test
public void conditionalOnMissingBeanMatch() throws Exception {
   AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
   ctx.register(BeanOneConfiguration.class, BeanTwoConfiguration.class);
   ctx.refresh();
   assertTrue(ctx.containsBean("bean1"));
   assertFalse(ctx.containsBean("bean2"));
   assertFalse(ctx.containsBean("configurationClassWithConditionTests.BeanTwoConfiguration"));
}

​ 这样就没有注入configurationClassWithConditionTests.BeanTwoConfiguration了，所以也不会注入bean2。

二、@Conditional在SpringBoot中的使用

上面这个是简单使用。下面我们就来其在SpringBoot中的使用，这个其实我们上一篇文章有简单提到。下面这些注解都是用在SpringBoot的自动配置。

1、@ConditionalOnBean

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnBeanCondition.class)
public @interface ConditionalOnBean {

   Class<?>[] value() default {};

   String[] type() default {};
    ...........

​ 这个注解@ConditionalOnBean有点类似上面demo的NoBeanOneCondition这种，只不过NoBeanOneCondition是类，还要自动注入，这个@ConditionalOnBean只要注解标注就可以了。不过两者的核心都是通过@Conditional来导入Condition接口的实现类。这里是导入的OnBeanCondition。

​ 然后这个@ConditionalOnBean只要是用来判断有没有Bean，只有存在的话才注入。下面我们来看下使用demo

1）、demo

@Configuration
@ConditionalOnBean(name = "foo")
protected static class OnBeanNameConfiguration {

   @Bean
   public String bar() {
      return "bar";
   }
}

@Configuration
protected static class FooConfiguration {

   @Bean
   public String foo() {
      return "foo";
   }

}

@Test
public void testNameOnBeanCondition() {
   this.contextRunner.withUserConfiguration(FooConfiguration.class, OnBeanNameConfiguration.class)
         .run(this::hasBarBean);
}

private void hasBarBean(AssertableApplicationContext context) {
   assertThat(context).hasBean("bar");
   assertThat(context.getBean("bar")).isEqualTo("bar");
}

​ 这样就完成了OnBeanNameConfiguration的注入，当然这里还可以指定这个Bean的类似，可以通过value、或type：

@Configuration
@ConditionalOnBean(name = "foo", value = Date.class)
protected static class OnBeanNameAndTypeConfiguration {

   @Bean
   public String bar() {
      return "bar";
   }

}

@Test
public void testNameAndTypeOnBeanCondition() {
   this.contextRunner.withUserConfiguration(FooConfiguration.class, OnBeanNameAndTypeConfiguration.class)
         .run((context) -> assertThat(context).doesNotHaveBean("bar"));
}

​ 这样由于类型不匹配，就不能注入了。

当然SpringBoot还有很多的这种注解，来帮助自动配置与注解。

​ 看名称也大致知道其的作用了。我们下面就来看下OnBeanCondition具体逻辑。

三、OnBeanCondition

class OnBeanCondition extends SpringBootCondition implements ConfigurationCondition {

​ 它有继承SpringBootCondition,然后实现ConfigurationCondition。

1、ConfigurationCondition

public interface ConfigurationCondition extends Condition {

   ConfigurationPhase getConfigurationPhase();

   enum ConfigurationPhase {

      PARSE_CONFIGURATION,
      REGISTER_BEAN
   }

}

​ 这个接口主要是为了颗粒化控制Condition的作用，要对应匹配才会返回true。PARSE_CONFIGURATION表面这个是Configuration即配置类，REGISTER_BEAN表示这个是一个常规Bean。

2、SpringBootCondition

public abstract class SpringBootCondition implements Condition {

​ SpringBootCondition是SpringBoot关于Condition的基础接口，也就是说，SpringBoot所有拓展Condition的都是通过SpringBootCondition来实现Condition接口。下面我们就来具体看下其的方法。

1)、matches

@Override
public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
   String classOrMethodName = getClassOrMethodName(metadata);
   try {
      ConditionOutcome outcome = getMatchOutcome(context, metadata);
      logOutcome(classOrMethodName, outcome);
      recordEvaluation(context, classOrMethodName, outcome);
      return outcome.isMatch();
   }
   catch (NoClassDefFoundError ex) {
      throw new IllegalStateException("Could not evaluate condition on " ....
            + "put a @ComponentScan in the default package by mistake)", ex);
   }
   catch (RuntimeException ex) {
      throw new IllegalStateException("Error processing condition on " + getName(metadata), ex);
   }
}

​ 这里首先是通过getMatchOutcome方法来获取匹配结果，然后再通过recordEvaluation来记录评估提交的详细结果，最后返回是否匹配。这里主要是getMatchOutcome方法，因为整个逻辑判断是否匹配都是这个方法，其他方法主要是记录一些信息，我们就略过了。

public class ConditionOutcome {

   private final boolean match;
   private final ConditionMessage message;

2）、getMatchOutcome

public abstract ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata);

​ 这个方法是抽象方法，要让子类来处理是否匹配。

​ 下面我们就来具体看下这个SpringBootCondition的一个子类OnBeanCondition的实现逻辑。

3、getMatchOutcome(SpringBootCondition)

@Override
public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
   ConditionMessage matchMessage = ConditionMessage.empty();
   if (metadata.isAnnotated(ConditionalOnBean.class.getName())) {
     ..........
   }
   if (metadata.isAnnotated(ConditionalOnSingleCandidate.class.getName())) {
     .........
   }
   if (metadata.isAnnotated(ConditionalOnMissingBean.class.getName())) {
      ........
   }
   return ConditionOutcome.match(matchMessage);
}

​ 这个我们可以看到其是会判断三种不同的注解ConditionalOnBean、ConditionalOnSingleCandidate、ConditionalOnMissingBean。其中ConditionalOnSingleCandidate是用来判断是不是传入的类是不是有单例Bean、ConditionalOnMissingBean是判断有没有缺失这个Bean。

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnBeanCondition.class)
public @interface ConditionalOnMissingBean {

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnBeanCondition.class)
public @interface ConditionalOnSingleCandidate {

​ 这里面的具体判断我们就先不深入探究了。

四、在注入的时候使用Conditional判断

​ 下面我们就来看下其是怎样使用的，我们在前面的两篇文章是有初步提到过得。

1、以PARSE_CONFIGURATION的方式(ConditionEvaluator源码调用)

protected void processConfigurationClass(ConfigurationClass configClass) throws IOException {
   if (this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)) {
      return;
   }
	..........
   // Recursively process the configuration class and its superclass hierarchy.
   SourceClass sourceClass = asSourceClass(configClass);
   do {
      sourceClass = doProcessConfigurationClass(configClass, sourceClass);
   }
   while (sourceClass != null);
   this.configurationClasses.put(configClass, configClass);
}

​ 这里就是在配置类的解析的前面以PARSE_CONFIGURATION也就是解析配置类的方式。

public boolean shouldSkip(@Nullable AnnotatedTypeMetadata metadata, @Nullable ConfigurationPhase phase) {
   if (metadata == null || !metadata.isAnnotated(Conditional.class.getName())) {
      return false;
   }

   if (phase == null) {
      .......
   }

   List<Condition> conditions = new ArrayList<>();
   for (String[] conditionClasses : getConditionClasses(metadata)) {
      .........
   }

   AnnotationAwareOrderComparator.sort(conditions);

   for (Condition condition : conditions) {
    ......
   }

   return false;
}

​ 下面我们就以前面的demo1为例，来看下这个过程。

1）

if (metadata == null || !metadata.isAnnotated(Conditional.class.getName())) {
   return false;
}

​ 首先是判断这个配置类有没有@Conditional注解，如果没有就返回false，主要在processConfigurationClass就不会直接返回，是继续往下解析。

2）

if (phase == null) {
   if (metadata instanceof AnnotationMetadata &&
         ConfigurationClassUtils.isConfigurationCandidate((AnnotationMetadata) metadata)) {
      return shouldSkip(metadata, ConfigurationPhase.PARSE_CONFIGURATION);
   }
   return shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN);
}

​ 下一步是类型phase判断，如果为null，就需要设置参数，这里的ConfigurationClassUtils.isConfigurationCandidate我们前面文章讲过，就是判断有没有@Component、@Bean这些

static {
   candidateIndicators.add(Component.class.getName());
   candidateIndicators.add(ComponentScan.class.getName());
   candidateIndicators.add(Import.class.getName());
   candidateIndicators.add(ImportResource.class.getName());
}

public static boolean isConfigurationCandidate(AnnotationMetadata metadata) {
	....
   // Any of the typical annotations found?
   for (String indicator : candidateIndicators) {
      if (metadata.isAnnotated(indicator)) {
         return true;
      }
   }
   // Finally, let's look for @Bean methods...
   try {
      return metadata.hasAnnotatedMethods(Bean.class.getName());
   }
      return false;
   }
}

​ 是的话，就返回true表面其是PARSE_CONFIGURATION,不然的话就是一个普通的REGISTER_BEAN然后再重新进入shouldSkip方法，就能继续往下走了。

3）

List<Condition> conditions = new ArrayList<>();
for (String[] conditionClasses : getConditionClasses(metadata)) {
   for (String conditionClass : conditionClasses) {
      Condition condition = getCondition(conditionClass, this.context.getClassLoader());
      conditions.add(condition);
   }
}

​ 这里就是获取@Conditional的值，也就是实现Condition接口的类获取，然后通过getCondition去实例化创建添加到conditions中。例如我们的demo中，这里获取的就是NoBeanOneCondition

4）

for (Condition condition : conditions) {
   ConfigurationPhase requiredPhase = null;
   if (condition instanceof ConfigurationCondition) {
      requiredPhase = ((ConfigurationCondition) condition).getConfigurationPhase();
   }
   if ((requiredPhase == null || requiredPhase == phase) && !condition.matches(this.context, metadata)) {
      return true;
   }
}
return false;

​ 这里就是最后一步了，如果是ConfigurationCondition类型，由于其本身是有getConfigurationPhase()返回ConfigurationPhase的，所以这里会判断，然后就上课关键的condition.matches,就是调用Condition的方法，如果不匹配就会true，也就是注解return，不就行后续解析了。不然就最后返回false来继续解析。

五、在@ComponentScan的使用。

protected final SourceClass doProcessConfigurationClass(以上是关于重读Spring系列-Conditional注入Bean的判断的主要内容，如果未能解决你的问题，请参考以下文章
 
 重读Spring系列-@SpringBootApplication注解的详细解析
 重读Spring系列-@SpringBootApplication注解的详细解析
 Spring@Conditional详解
 Spring@Conditional详解
 Spring@Conditional详解
 020 使用@Conditional注解完成条件注入