助力SpringBoot自动配置的条件注解ConditionalOnXXX分析--SpringBoot源码（三）

注：该源码分析对应SpringBoot版本为2.1.0.RELEASE

1 前言

本篇接
如何分析SpringBoot源码模块及结构？–SpringBoot源码（二）

上一篇分析了SpringBoot源码结构及各个模块pom之间的关系后，那么此篇开始就开始解开SpringBoot新特性之一–自动配置的神秘面纱了。因为SpringBoot自动配置原理是基于其大量的条件注解ConditionalOnXXX，因此，本节我们先来撸下Spring的条件注解的相关源码。

2 SpringBoot的派生条件注解

我们都知道，SpringBoot自动配置是需要满足相应的条件才会自动配置,因此SpringBoot的自动配置大量应用了条件注解ConditionalOnXXX。如下图：

那么上图的条件注解如何使用呢？

举个栗子，我们来看下如何使用@ConditionalOnClass和@ConditionalOnProperty这两个注解，先看下图代码：

HelloWorldEnableAutoConfiguration这个自动配置类应用了@ConditionalOnClass和ConditionalOnProperty两个条件注解，那么只有在满足:classpath中存在HelloWorldComponent.class和配置了hello.world.name和hello.world.age属性这两个条件的情况下才会创建HelloWorldComponent这个bean。

其实SpringBoot的@ConditionalOnXXX等条件注解都是派生注解，那么什么是派生注解呢？
就拿上面的栗子来说，以@ConditionalOnClass(HelloWorldComponent.class)为例，我们打开ConditionalOnClass注解源码，如下：

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

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

	String[] name() default {
   };

}

可以看到@ConditionalOnClass注解上面又标注了@Conditional(OnClassCondition.class)注解，因此@ConditionalOnClass是@Conditional的派生注解，@Conditional(OnClassCondition.class)和@ConditionalOnClass注解是等价的，即这两个注解标注在某个配置类上的效果是等价的。

而SpringBoot的自动配置原理正是建立在这些大量的派生条件注解@ConditionalOnXXX之上，而这些条件注解的原理跟Spring的Condition接口有关。因此我们先来研究下Condition接口的相关源码。

3 Condition接口

3.1 Condition接口源码分析

分析Condition接口源码前先看下如何自定义ConditionalOnXXX注解,举个栗子，比如自定义一个@ConditionalOnLinux注解，该注解只有在其属性environment是"linux"才会创建相关的bean。定义了以下代码：

/**
 * 实现spring 的Condition接口，并且重写matches()方法，如果@ConditionalOnLinux的注解属性environment是linux就返回true
 *
 */
public class LinuxCondition implements Condition {
   

	@Override
	public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
   
		// 获得注解@ConditionalOnLinux的所有属性
		List<AnnotationAttributes> allAnnotationAttributes = annotationAttributesFromMultiValueMap(
				metadata.getAllAnnotationAttributes(
						ConditionalOnLinux.class.getName()));
		for (AnnotationAttributes annotationAttributes : allAnnotationAttributes) {
   
			// 获得注解@ConditionalOnLinux的environment属性
			String environment = annotationAttributes.getString("environment");
			// 若environment等于linux，则返回true
			if ("linux".equals(environment)) {
   
				return true;
			}
		}
		return false;
	}
}

@Target({
    ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(LinuxCondition.class)
public @interface ConditionalOnLinux {
   
	// 标注是哪个环境
	String environment() default "";

}

@Configuration
public class ConditionConfig {
   
        // 只有`@ConditionalOnLinux`的注解属性`environment`是"linux"时才会创建bean
	@Bean
	@ConditionalOnLinux(environment = "linux")
	public Environment linuxEnvironment() {
   
		return new LinuxEnvironment();
	}
}

上面的代码我们捋一下：

1. LinuxCondition实现了Condition接口并实现了matches方法，而matches方法则判断@ConditionalOnLinux的注解属性environment是否"linux"，是则返回true，否则false。
2. 然后我们再定义了一个注解@ConditionalOnLinux，这个注解是@Conditional的派生注解，与@Conditional(LinuxCondition.class)等价，注意@ConditionalOnLinux注解定义了一个属性environment。而我们最终可以利用LinuxCondition的matches方法中的参数AnnotatedTypeMetadata来获取@ConditionalOnLinux的注解属性environment的值，从而用来判断值是否为linux"。
3. 最后我们又定义了一个配置类ConditionConfig，在linuxEnvironment方法上标注了@ConditionalOnLinux(environment = "linux")。因此，这里只有 LinuxCondition的matches方法返回true才会创建bean。

学会了如何自定义@ConditionalOnXXX注解后，我们现在再来看下Condition接口的源码：

@FunctionalInterface
public interface Condition {
   
	boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
}

Condition接口主要有一个matches方法，该方法决定了是否要注册相应的bean对象。其中matches方法中有两个参数，参数类型分别是ConditionContext和AnnotatedTypeMetadata，这两个参数非常重要。它们分别用来获取一些环境信息和注解元数据从而用在matches方法中判断是否符合条件。

ConditionContext，顾名思义，主要是跟Condition的上下文有关，主要用来获取Registry,BeanFactory,Environment,ResourceLoader和ClassLoader等。那么获取这些用来干什么呢？举个栗子，比如OnResourceCondition需要靠ConditionContext来获取ResourceLoader来加载指定资源，OnClassCondition需要靠ConditionContext来获取ClassLoader来加载指定类等，下面看下其源码：

public interface ConditionContext {
   
    BeanDefinitionRegistry getRegistry();
    @Nullable
    ConfigurableListableBeanFactory getBeanFactory();
    Environment getEnvironment();
    ResourceLoader getResourceLoader();
    @Nullable
    ClassLoader getClassLoader();
}

AnnotatedTypeMetadata，这个跟注解元数据有关，利用AnnotatedTypeMetadata可以拿到某个注解的一些元数据，而这些元数据就包含了某个注解里面的属性，比如前面的栗子，利用AnnotatedTypeMetadata可以拿到@ConditionalOnLinux的注解属性environment的值。下面看下其源码：

public interface AnnotatedTypeMetadata {
   
	boolean isAnnotated(String annotationName);
	Map<String, Object> getAnnotationAttributes(String annotationName);
	Map<String, Object> getAnnotationAttributes(String annotationName, boolean classValuesAsString);
	MultiValueMap<String, Object> getAllAnnotationAttributes(String annotationName);
	MultiValueMap<String, Object> getAllAnnotationAttributes(String annotationName, boolean classValuesAsString);
}

回到刚才的栗子，我们知道@ConditionalOnLinux注解真正起作用的是Condition接口的具体实现类LinuxCondition的matches方法，那么这个matches方法是在何时被调用的呢？

通过idea调试看调用的栈帧，如下图：

发现是在ConditionEvaluator的shouldSkip方法中调用了LinuxCondition的matches方法，自然我们再去看看ConditionEvaluator的shouldSkip的方法执行了什么逻辑。

// 这个方法主要是如果是解析阶段则跳过，如果是注册阶段则不跳过
public boolean shouldSkip(@Nullable AnnotatedTypeMetadata metadata, @Nullable ConfigurationPhase phase) {
   
	// 若没有被@Conditional或其派生注解所标注，则不会跳过
	if (metadata == null || !metadata.isAnnotated(Conditional.class.getName())) {
   
		return false;
	}
	// 没有指定phase，注意phase可以分为PARSE_CONFIGURATION或REGISTER_BEAN类型
	if (phase == null) {
   
		// 若标有@Component，@Import，@Bean或@Configuration等注解的话，则说明是PARSE_CONFIGURATION类型
		if (metadata instanceof AnnotationMetadata &&
				ConfigurationClassUtils.isConfigurationCandi