我们在 Spring/ Spring Boot Starter 或者一些框架的创建源码里经常能看到类似如下的注解声明，可能作用在类上，时样也可能在某个方法上：

@ConditionalOnProperty(name = "spring.cloud.refresh.enabled",判断 matchIfMissing = true) @ConditionalOnProperty(prefix = "management.metrics.export.atlas", name = "enabled", havingValue = "true",     matchIfMissing = true) 

我们一眼都能看出来，这是条件来「谈条件」的。需要满足某个属性存在，创建或者属性值是时样xx这一类的。

对于属性的判断匹配，是条件会在 Environment 里查找是否包含当前需要的属性，如果没指定 havingValue 的创建话，那需要同时属性的时样值不为「false」这个字符串，其它的判断东西都视为true。

今天的条件这篇做为铺垫，先来描述一下注解的创建工作原理，后面一篇我会写写与此有关的时样一个有趣的案例。

工作原理

浓缩版

在SpringBoot 启动过程中，判断会扫描当前依赖里的 @Configuration，服务器租用然后遍历的过程中会判断其中哪些是要讲条件的。对于讲条件的这些，会判断

shouldSkip ，这里的是否跳过，会根据注解作用在类上，方法上，转向不同的Metadata，提取对应的实现类，但本质上还是通过 resolver 去Environment 里找找这个属性在不在，不在跳过，在的话是否值匹配。从而决定 Confirutaion 是否生效。

源码版

我们知道 Spring 启动的过程，也是创建和初始化Bean 的过程，在这个过程中，会先拿到BeanNames，并一个个的去创建和初始化。云南idc服务商

此时，对于Configuration，是通过BeanPostProcessor的方式来处理的.

public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {      int registryId = System.identityHashCode(registry);     this.registriesPostProcessed.add(registryId);     processConfigBeanDefinitions(registry);// 对，是这里   } 

部分调用栈如下：

java.lang.Thread.State: RUNNABLE     at org.springframework.boot.autoconfigure.condition.OnPropertyCondition.getMatchOutcome(OnPropertyCondition.java:65)     at org.springframework.boot.autoconfigure.condition.SpringBootCondition.matches(SpringBootCondition.java:47)     at org.springframework.context.annotation.ConditionEvaluator.shouldSkip(ConditionEvaluator.java:108)     at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod(ConfigurationClassBeanDefinitionReader.java:181)     at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:142)     at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitions(ConfigurationClassBeanDefinitionReader.java:118)     at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:328)     at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:233) 

这里对于 Class 和 Method，都在该方法中，处理入口不一样，传入的Meta也有所区别

/**    * Build and validate a configuration model based on the registry of    * { @link Configuration} classes.    */   public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {      List<BeanDefinitionHolder> configCandidates = new ArrayList<>();     String[] candidateNames = registry.getBeanDefinitionNames();     for (String beanName : candidateNames) {        BeanDefinition beanDef = registry.getBeanDefinition(beanName);       if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||           ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {        }       else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {          configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));       }     }     // Return immediately if no @Configuration classes were found     if (configCandidates.isEmpty()) {        return;     }     // Parse each @Configuration class     ConfigurationClassParser parser = new ConfigurationClassParser(         this.metadataReaderFactory, this.problemReporter, this.environment,         this.resourceLoader, this.componentScanBeanNameGenerator, registry);     Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);     Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());     do {        parser.parse(candidates); // 这里处理class       parser.validate();       Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());       configClasses.removeAll(alreadyParsed);       // Read the model and create bean definitions based on its content       if (this.reader == null) {          this.reader = new ConfigurationClassBeanDefinitionReader(             registry, this.sourceExtractor, this.resourceLoader, this.environment,             this.importBeanNameGenerator, parser.getImportRegistry());       }       this.reader.loadBeanDefinitions(configClasses); // 这里处理Method       alreadyParsed.addAll(configClasses);     while (!candidates.isEmpty());   } 

里面的逻辑，则都是在判断这些Condition 是否match，重点看这一行

condition.matches(this.context, metadata)

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

通过观察 Condition 这个接口你也能发现，和我们上面说的一样，这里不同的处理metadata是不同的。

在 SpringBoot 里，ConditionalOnProperty 的 Condition 实现，运用了一个模板方法模式， SpringBootCondition 做为模板，再调用各子类的实现方法。

public final boolean matches(ConditionContext context,       AnnotatedTypeMetadata metadata) {      String classOrMethodName = getClassOrMethodName(metadata);       ConditionOutcome outcome = getMatchOutcome(context, metadata);// 这里交给了抽象方法       recordEvaluation(context, classOrMethodName, outcome);       return outcome.isMatch();   } 

来看子类的实现

private ConditionOutcome determineOutcome(AnnotationAttributes annotationAttributes,       PropertyResolver resolver) {      Spec spec = new Spec(annotationAttributes);     List<String> missingProperties = new ArrayList<>();     List<String> nonMatchingProperties = new ArrayList<>();     spec.collectProperties(resolver, missingProperties, nonMatchingProperties);     if (!missingProperties.isEmpty()) {        return ConditionOutcome.noMatch(           ConditionMessage.forCondition(ConditionalOnProperty.class, spec)               .didNotFind("property", "properties")               .items(Style.QUOTE, missingProperties));     }     if (!nonMatchingProperties.isEmpty()) {        return ConditionOutcome.noMatch(           ConditionMessage.forCondition(ConditionalOnProperty.class, spec)               .found("different value in property",                   "different value in properties")               .items(Style.QUOTE, nonMatchingProperties));     }     return ConditionOutcome.match(ConditionMessage         .forCondition(ConditionalOnProperty.class, spec).because("matched"));   } 

有了这个判断，对于 OnClass 之类的云服务器提供商，你也能猜个八九不离十。

同样会有一个子类的实现

只不过判断的从属性，换成了在classloader里查找已加载的类。

本文转载自微信公众号「Tomcat那些事儿」，可以通过以下二维码关注。转载本文请联系Tomcat那些事儿公众号。