文章目录
助力SpringBoot自动配置的条件注解原理揭秘 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();
}
}
上面的代码我们捋一下:
- LinuxCondition实现了Condition接口并实现了matches方法,而matches方法则判断@ConditionalOnLinux的注解属性environment是否"linux",是则返回true,否则false。
- 然后我们再定义了一个注解@ConditionalOnLinux,这个注解是@Conditional的派生注解,与@Conditional(LinuxCondition.class)等价,注意@ConditionalOnLinux注解定义了一个属性environment。而我们最终可以利用LinuxCondition的matches方法中的参数AnnotatedTypeMetadata来获取@ConditionalOnLinux的注解属性environment的值,从而用来判断值是否为linux"。
- 最后我们又定义了一个配置类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.isConfigurationCandidate((AnnotationMetadata) metadata)) {