**注：该源码分析对应SpringBoot版本为2.1.0.RELEASE** # 1 前言本篇接 [如何分析SpringBoot源码模块及结构？--SpringBoot源码（二）](https://juejin.cn/post/6844904070818463751) 上一篇分析了SpringBoot源码结构及各个模块pom之间的关系后，那么此篇开始就开始解开SpringBoot新特性之一--自动配置的神秘面纱了。因为SpringBoot自动配置原理是基于其大量的条件注解`ConditionalOnXXX`，因此，本节我们先来撸下Spring的条件注解的相关源码。 # 2 SpringBoot的派生条件注解我们都知道，SpringBoot自动配置是需要满足相应的条件才会自动配置,因此SpringBoot的自动配置大量应用了条件注解`ConditionalOnXXX`。如下图： ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/2/29/17090e0c01410985~tplv-t2oaga2asx-image.image) 那么上图的条件注解如何使用呢？ > 举个栗子，我们来看下如何使用`@ConditionalOnClass`和`@ConditionalOnProperty`这两个注解，先看下图代码： ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/2/29/17090e5311f91840~tplv-t2oaga2asx-image.image) `HelloWorldEnableAutoConfiguration`这个自动配置类应用了`@ConditionalOnClass`和`ConditionalOnProperty`两个条件注解，那么只有在满足:`classpath`中存在`HelloWorldComponent.class`和配置了`hello.world.name`和`hello.world.age`属性**这两个条件**的情况下才会创建`HelloWorldComponent`这个`bean`。其实SpringBoot的`@ConditionalOnXXX`等条件注解都是派生注解，那么什么是派生注解呢？就拿上面的栗子来说，以`@ConditionalOnClass(HelloWorldComponent.class)`为例，我们打开`ConditionalOnClass`注解源码，如下： ```java @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。定义了以下代码： ```java /** * 实现spring 的Condition接口，并且重写matches()方法，如果@ConditionalOnLinux的注解属性environment是linux就返回true * */ public class LinuxCondition implements Condition { @Override public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { // 获得注解@ConditionalOnLinux的所有属性 List 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; } } ``` ```java @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Documented @Conditional(LinuxCondition.class) public @interface ConditionalOnLinux { // 标注是哪个环境 String environment() default ""; } ``` ```java @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`接口的源码： ```java @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`来加载指定类等，下面看下其源码： ```java public interface ConditionContext { BeanDefinitionRegistry getRegistry(); @Nullable ConfigurableListableBeanFactory getBeanFactory(); Environment getEnvironment(); ResourceLoader getResourceLoader(); @Nullable ClassLoader getClassLoader(); } ``` >`AnnotatedTypeMetadata`，这个跟注解元数据有关，利用`AnnotatedTypeMetadata`可以拿到某个注解的一些元数据，而这些元数据就包含了某个注解里面的属性，比如前面的栗子，利用`AnnotatedTypeMetadata`可以拿到`@ConditionalOnLinux`的注解属性`environment`的值。下面看下其源码： ```java public interface AnnotatedTypeMetadata { boolean isAnnotated(String annotationName); Map getAnnotationAttributes(String annotationName); Map getAnnotationAttributes(String annotationName, boolean classValuesAsString); MultiValueMap getAllAnnotationAttributes(String annotationName); MultiValueMap getAllAnnotationAttributes(String annotationName, boolean classValuesAsString); } ``` 回到刚才的栗子，我们知道`@ConditionalOnLinux`注解真正起作用的是`Condition`接口的具体实现类`LinuxCondition`的`matches`方法，那么这个`matches`方法是在何时被调用的呢？通过idea调试看调用的栈帧，如下图： ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/2/29/1709120edd2e91bf~tplv-t2oaga2asx-image.image) 发现是在`ConditionEvaluator`的`shouldSkip`方法中调用了`LinuxCondition`的`matches`方法，自然我们再去看看`ConditionEvaluator`的`shouldSkip`的方法执行了什么逻辑。 ```java // 这个方法主要是如果是解析阶段则跳过，如果是注册阶段则不跳过 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.isConfigurationCandidate((AnnotationMetadata) metadata)) { return shouldSkip(metadata, ConfigurationPhase.PARSE_CONFIGURATION); } // 否则是REGISTER_BEAN类型 return shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN); } List conditions = new ArrayList<>(); // TODO 获得所有标有@Conditional注解或其派生注解里面的Condition接口实现类并实例化成对象。 // 比如@Conditional(OnBeanCondition.class)则获得OnBeanCondition.class，OnBeanCondition.class往往实现了Condition接口 for (String[] conditionClasses : getConditionClasses(metadata)) { // 将类实例化成对象 for (String conditionClass : conditionClasses) { Condition condition = getCondition(conditionClass, this.context.getClassLoader()); conditions.add(condition); } } // 排序，即按照Condition的优先级进行排序 AnnotationAwareOrderComparator.sort(conditions); for (Condition condition : conditions) { ConfigurationPhase requiredPhase = null; if (condition instanceof ConfigurationCondition) { // 从condition中获得对bean是解析还是注册 requiredPhase = ((ConfigurationCondition) condition).getConfigurationPhase(); } // 若requiredPhase为null或获取的阶段类型正是当前阶段类型且不符合condition的matches条件，则跳过 if ((requiredPhase == null || requiredPhase == phase) && !condition.matches(this.context, metadata)) { return true; } } return false; } ``` `shouldSkip`这个方法执行的逻辑主要是如果是解析阶段则跳过，如果是注册阶段则不跳过；如果是在注册阶段即`REGISTER_BEAN`阶段的话，此时会得到所有的`Condition`接口的具体实现类并实例化这些实现类，然后再执行下面关键的代码进行判断是否需要跳过。 ```java if ((requiredPhase == null || requiredPhase == phase) && !condition.matches(this.context, metadata)) { return true; } ``` 上面代码最重要的逻辑是调用了`Condition`接口的具体实现类的`matches`方法，若`matches`返回`false`，则跳过，不进行注册`bean`的操作；若`matches`返回`true`，则不跳过，进行注册`bean`的操作；好了，`Condition`的源码分析就到此为止，再往上翻调用方法的话应该就是Spring加载`bean`定义的相关源码了，不属于这里的分析范围。 ## 3.2 Spring的内置Condition接口实现类前面我们学会了如何自定义条件注解及`Condition`的源码分析，那么我们不禁好奇，Spring究竟内置了哪些`Condition`接口的实现类呢？那么看下Spring的`Condition`接口的具体实现类的类图： ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/2/29/1709141a3e769ea7~tplv-t2oaga2asx-image.image) 发现Spring内置的`Condition`接口的具体实现类虽然有多个，但只有`ProfileCondition`不是测试相关的，因此可以说真正的内置的`Condition`接口的具体实现类只有`ProfileCondition`一个，非常非常少,这跟SpringBoot的大量派生条件注解形成了鲜明的对比。`ProfileCondition`大家都知道，是跟环境有关，比如我们平时一般有`dev`,`test`和`prod`环境，而`ProfileCondition`就是判断我们项目配置了哪个环境的。下面是`ProfileCondition`的源码，很简单，这里就不分析了。 ```java class ProfileCondition implements Condition { @Override public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { MultiValueMap attrs = metadata.getAllAnnotationAttributes(Profile.class.getName()); if (attrs != null) { for (Object value : attrs.get("value")) { if (context.getEnvironment().acceptsProfiles(Profiles.of((String[]) value))) { return true; } } return false; } return true; } } ``` # 4 SpringBootCondition源码解析前面看到Spring对`Condition`的内置注解可以说只有`ProfileCondition`一个，但是我们都知道，SpringBoot则内置了大量的条件注解`ConditionalOnXXX`。在分析前，我们先来看一下`SpringBootCondition`的整体类图来个整体的理解，如下图： ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/2/29/1709155cbee8d6d7~tplv-t2oaga2asx-image.image) 可以看到`SpringBootCondition`作为SpringBoot条件注解的基类，处于整个类图的中心，它实现了`Condition`接口，然后又有很多具体的子类`OnXXXCondition`,这些`OnXXXCondition`其实就是`@ConditionalOnXXX`的条件类。我们先来看下`SpringBootCondition`这个父类是主要做了哪些事情，抽象了哪些共有的逻辑？ `SpringBootConditon`实现了`Condition`接口，作为SpringBoot众多条件注解`OnXXXCondtion`的父类，它的作用主要就是打印一些条件注解评估报告的日志，比如打印哪些配置类是符合条件注解的，哪些是不符合的。打印的日志形式如下图： ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/3/1/17093f131826efd2~tplv-t2oaga2asx-image.image) ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/3/1/17093f16b37685f2~tplv-t2oaga2asx-image.image) 因为`SpringBootConditon`实现了`Condition`接口，也实现了`matches`方法，因此该方法同样也是被`ConditionEvaluator`的`shouldSkip`方法中调用，因此我们就以`SpringBootConditon`的`matches`方法为入口去进行分析。直接上代码： ```java // SpringBootCondition.java public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { // 得到metadata的类名或方法名 String classOrMethodName = getClassOrMethodName(metadata); try { // 判断每个配置类的每个条件注解@ConditionalOnXXX是否满足条件，然后记录到ConditionOutcome结果中 // 注意getMatchOutcome是一个抽象模板方法，交给OnXXXCondition子类去实现 ConditionOutcome outcome = getMatchOutcome(context, metadata); // 打印condition评估的日志，哪些条件注解@ConditionalOnXXX是满足条件的，哪些是不满足条件的，这些日志都打印出来 logOutcome(classOrMethodName, outcome); // 除了打印日志外，这些是否匹配的信息还要记录到ConditionEvaluationReport中 recordEvaluation(context, classOrMethodName, outcome); // 最后返回@ConditionalOnXXX是否满足条件 return outcome.isMatch(); } catch (NoClassDefFoundError ex) { throw new IllegalStateException( "Could not evaluate condition on " + classOrMethodName + " due to " + ex.getMessage() + " not " + "found. Make sure your own configuration does not rely on " + "that class. This can also happen if you are " + "@ComponentScanning a springframework package (e.g. if you " + "put a @ComponentScan in the default package by mistake)", ex); } catch (RuntimeException ex) { throw new IllegalStateException( "Error processing condition on " + getName(metadata), ex); } } ``` 上面代码的注释已经非常详细，我们知道了`SpringBootCondition`抽象了所有其具体实现类`OnXXXCondition`的共有逻辑--`condition`评估信息打印，最重要的是封装了一个模板方法`getMatchOutcome(context, metadata)`，留给各个`OnXXXCondition`具体子类去覆盖实现属于自己的判断逻辑，然后再返回相应的匹配结果给`SpringBootCondition`用于日志打印。因此我们知道了`SpringBootCondition`其实就是用来打印`condition`评估信息的，对于其他枝节方法我们不必追究过深，免得丢了主线。我们现在的重点是放在交给`OnXXXCondition`子类实现的模板方法上`getMatchOutcome(context, metadata);`，因为这个方法将会由很多`OnXXXCondition`覆盖重写判断逻辑，这里是我们接下来分析的重点。因为`SpringBootCondition`有众多具体实现类，下面只挑`OnResourceCondition`，`OnBeanCondition`和`OnWebApplicationCondition`进行讲解，而`AutoConfigurationImportFilter`跟自动配置有关，则留到自动配置源码解析的时候再进行分析。 ## 4.1 OnResourceCondition源码分析现在先来看下一个逻辑及其简单的注解条件类`OnResourceCondition`，`OnResourceCondition`继承了`SpringBootCondition`父类，覆盖了其`getMatchOutcome`方法，用于`@ConditionalOnResource`注解指定的资源存在与否。`OnResourceCondition`的判断逻辑非常简单，主要拿到`@ConditionalOnResource`注解指定的资源路径后，然后用`ResourceLoader`根据指定路径去加载看资源存不存在。下面直接看代码: 先来看下`@ConditionalOnResource`的代码， ```java @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Documented @Conditional(OnResourceCondition.class) public @interface ConditionalOnResource { /** * The resources that must be present. * @return the resource paths that must be present. */ String[] resources() default {}; } ``` 再来看`OnResourceCondition`的代码： ```java @Order(Ordered.HIGHEST_PRECEDENCE + 20) class OnResourceCondition extends SpringBootCondition { private final ResourceLoader defaultResourceLoader = new DefaultResourceLoader(); @Override public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) { // 获得@ConditionalOnResource注解的属性元数据 MultiValueMap attributes = metadata .getAllAnnotationAttributes(ConditionalOnResource.class.getName(), true); // 获得资源加载器，若ConditionContext中有ResourceLoader则用ConditionContext中的，没有则用默认的 ResourceLoader loader = (context.getResourceLoader() != null) ? context.getResourceLoader() : this.defaultResourceLoader; List locations = new ArrayList<>(); // 将@ConditionalOnResource中定义的resources属性值取出来装进locations集合 collectValues(locations, attributes.get("resources")); Assert.isTrue(!locations.isEmpty(), "@ConditionalOnResource annotations must specify at " + "least one resource location"); // missing集合是装不存在指定资源的资源路径的 List missing = new ArrayList<>(); // 遍历所有的资源路径，若指定的路径的资源不存在则将其资源路径存进missing集合中 for (String location : locations) { // 这里针对有些资源路径是Placeholders的情况，即处理${} String resource = context.getEnvironment().resolvePlaceholders(location); if (!loader.getResource(resource).exists()) { missing.add(location); } } // 如果存在某个资源不存在，那么则报错 if (!missing.isEmpty()) { return ConditionOutcome.noMatch(ConditionMessage .forCondition(ConditionalOnResource.class) .didNotFind("resource", "resources").items(Style.QUOTE, missing)); } // 所有资源都存在，那么则返回能找到就提的资源 return ConditionOutcome .match(ConditionMessage.forCondition(ConditionalOnResource.class) .found("location", "locations").items(locations)); } // 将@ConditionalOnResource中定义的resources属性值取出来装进locations集合 private void collectValues(List names, List