往期文章
- 用最简单的话讲最明白的红黑树
- java源码阅读 - HashMap
- 数据结构 - 堆与堆排序
目录
文章目录
前言
用过springboot的小伙伴们都知道,相比于spring,它最大的优势是帮我们省去了一大堆超大一堆繁琐的配置。比如在spring中,当我们需要在项目中整合第三方插件(如redis、mybatis、rabbitmq)时,往往需要在xml配置文件中去配置这些插件的
ConnectionFactory
等将其与spring进行整合。而在springboot中,他会根据项目中引入哪些插件自动地将插件进行整合,这都得益于springboot的自动装配 或称为 自动配置。
那么springboot是如何知道我们项目中引入了哪些插件,又怎么知道需要帮助我们配置哪些插件呢?
介绍
所谓@ConditionalOnClass注解,翻译过来就是基于class的条件,它为所标注的类或方法添加限制条件,当该条件的值为true时,其所标注的类或方法才能生效。基于class的意思是在类路径
classpath
中存在
value()属性
指定的类或存在
name()属性
指定的类名。
为了让上面的介绍更加容易理解,我们就举个例子吧
- 在rabbitmq的自动配置类
RabbitAutoConfiguration
中,有一行注解为@ConditionalOnClass({ RabbitTemplate.class, Channel.class })
,则表示当类路径classpath
中存在RabbitTemplate
和Channel
这两个类时,该条件注解才会通过,rabbitmq的自动配置RabbitAutoConfiguration
才会生效。如下图所示。由于我项目中已经引入了rabbitmq的依赖,该依赖中存在着两个类,因此该条件是通过的。
- 在redis的自动配置类
RedisAutoConfiguration
中,有一行注解为@ConditionalOnClass(RedisOperations.class)
,则表示当类路径classpath
中存在RedisOperations
这个类时,该条件注解才会通过,redis的自动配置RedisAutoConfiguration
才会生效。如下图所示。由于我项目中没有引入redis的依赖,类路径classpath
中不存在RedisOperations
,因此该条件是不通过的,从代码爆红即可得知。
正文
是否觉得这个注解如此流批?今天我们从源码扒开它神秘的面纱。
先看一下该注解的源码,该注解只提供给我们两个属性,实现条件的逻辑在哪呢?
@Target({ElementType.TYPE,ElementType.METHOD })@Retention(RetentionPolicy.RUNTIME)@Documented@Conditional(OnClassCondition.class)public@interfaceConditionalOnClass{// The classes that must be present.Class<?>[]value()default{};// The classes names that must be present.String[]name()default{};}
我们应当注意到该注解上还有另一个注解
@Conditional(OnClassCondition.class)
,它才是
@ConditionalOnClass
注解的核心所在。
那么我们就看一下
@Conditional()
注解的源码。该注解通过
value()
属性接收一个
Condition数组
的参数。
@Target({ElementType.TYPE,ElementType.METHOD})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic@interfaceConditional{/**
* All {@link Condition} classes that must {@linkplain Condition#matches match}
* in order for the component to be registered.
*/Class<?extendsCondition>[]value();}
那么Condition又是什么?继续看源码。从源码中我们知道,
Condition
是一个接口,其内部声明一个方法
matches()
,且返回boolean类型的值。
@FunctionalInterfacepublicinterfaceCondition{/**
* 决定条件是否通过
* @param context - 条件上下文
* @param metadata - 元数据,里面标注该注解的类或方法
* @return true-通过,false-不通过
**/booleanmatches(ConditionContext context,AnnotatedTypeMetadata metadata);}
至此,通过两个注解 + 一个接口,我们可以对
@ConditionalOnClass
注解得出以下结论:
**
@Conditional
注解接收
Condition
类型的参数,通过其
matches()
方法的返回值判断条件是否通过,而在
@ConditionalOnClass
注解上向
@Conditional
注解传入的实际类型为
Condition
的实现类
OnClassCondition
。**
现在,我们只需要把目光转移到
Condition
接口的实现类
OnClassCondition
上面来。
OnClassCondition类
OnClassCondition类表示为基于
classpath
类路径下的条件,因此它在对条件进行判断时,都是从
classpath
类路径中进行判断的。这一点从命名上可以看出。 先看一下该类的UML图吧,对源码的阅读有所帮助。
从图中我们看到,中间两个类
SpringBootCondition
和
FilteringSpringBootCondition
均为抽象类,而
OnClassCondition
为具体实现类,因此我们猜测这里定有模版方法的设计模式,这使代码读起来可能有点跳来跳去。
那么我们看一下
OnClassCondition
是如何实现接口
Condition
的
matches()
方法的。但是找来找去并为找到
matches()
方法,其实该方法是在其父类
SpringBootCondition
中实现的。
publicabstractclassSpringBootConditionimplementsCondition{privatefinalLog logger =LogFactory.getLog(getClass());/**
* matches()方法的实现————决定条件是否通过
* @param context - 条件上下文
* @param metadata - 元数据,里面标注该注解的类或方法
* @return true-通过,false-不通过
**/@Overridepublicfinalbooleanmatches(ConditionContext context,AnnotatedTypeMetadata metadata){// 获取方法名或类名String classOrMethodName =getClassOrMethodName(metadata);try{// 对元数据进行判断,看是否符合要求。// ConditionOutcome中封装了判断的结果和相应的结果信息,ConditionOutcome outcome =getMatchOutcome(context, metadata);// 日志,logOutcome(classOrMethodName, outcome);// 记录recordEvaluation(context, classOrMethodName, outcome);// 如果isMatch()的值为true,则表示条件通过return outcome.isMatch();}catch(NoClassDefFoundError ex){// 抛出IllegalStateException异常}catch(RuntimeException ex){// 抛出IllegalStateException异常}}publicabstractConditionOutcomegetMatchOutcome(ConditionContext context,AnnotatedTypeMetadata metadata);}
从
SpringBootCondition
抽象类中实现的
matches()
方法来看,它只是提供了一个模版,而真正对条件进行判断的逻辑在其抽象方法
getMatchOutcome()
中,
OnClassCondition
类对该抽象方法提供了实现。这就是设计模式—模版方法的体现。
classOnClassConditionextendsFilteringSpringBootCondition{// 该方法分三部分// 1. 处理ConditionalOnClass注解// 2. 处理ConditionalOnMissingClass注解// 3. 返回条件判断的结果@OverridepublicConditionOutcomegetMatchOutcome(ConditionContext context,AnnotatedTypeMetadata metadata){ClassLoader classLoader = context.getClassLoader();// 通过静态方法,创建一个ConditionMessage实例,用来保存条件判断结果对应的信息ConditionMessage matchMessage =ConditionMessage.empty();// 1. 处理ConditionalOnClass注解// 获取该元数据表示的类或方法上的ConditionalOnClass注解中标注的类的限定名,// 表示这些类应当在classpath类路径中存在,所以叫onClass// 例如:@ConditionalOnClass({ RabbitTemplate.class, Channel.class }),// 则返回RabbitTemplate和Channel的全限定类名List<String> onClasses =getCandidates(metadata,ConditionalOnClass.class);if(onClasses !=null){// filter()方法内部 对onClass表示的类进行反射,条件为MISSING,// 如果得到的集合不为空,则说明类路径中不存在ConditionalOnClass注解中标注的类// 这种情况下直接通过ConditionOutcome.noMatch()封装ConditionOutcome条件判断的结果并返回,noMatch()即表示不通过。List<String> missing =filter(onClasses,ClassNameFilter.MISSING, classLoader);if(!missing.isEmpty()){returnConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class).didNotFind("required class","required classes").items(Style.QUOTE, missing));}// 对ConditionalOnClass注解的条件判断通过,并保存对应的信息到matchMessage
matchMessage = matchMessage.andCondition(ConditionalOnClass.class).found("required class","required classes").items(Style.QUOTE,filter(onClasses,ClassNameFilter.PRESENT, classLoader));}// 2. 处理ConditionalOnMissingClass注解// 获取该元数据表示的类或方法上的ConditionalOnMissingClass注解中标注的类的限定名,// 表示这些类应当在classpath类路径中不存在,所以叫onMissingClass// 例如:@ConditionalOnMissingClass({ RabbitTemplate.class, Channel.class }),// 则返回RabbitTemplate和Channel的全限定类名List<String> onMissingClasses =getCandidates(metadata,ConditionalOnMissingClass.class);if(onMissingClasses !=null){// filter()方法内部 对onMissingClasses表示的类进行反射,条件为PRESENT,// 如果得到的集合不为空,则说明类路径中存在ConditionalOnMissingClass注解中标注的类// 这种情况下直接通过ConditionOutcome.noMatch()封装ConditionOutcome条件判断的结果并返回,noMatch()即表示不通过。List<String> present =filter(onMissingClasses,ClassNameFilter.PRESENT, classLoader);if(!present.isEmpty()){returnConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class).found("unwanted class","unwanted classes").items(Style.QUOTE, present));}// 对ConditionalOnMissingClass注解的条件判断通过,并保存对应的信息到matchMessage
matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class).didNotFind("unwanted class","unwanted classes").items(Style.QUOTE,filter(onMissingClasses,ClassNameFilter.MISSING, classLoader));}// 3. 返回条件判断的结果,到这一步,就说明ConditionalOnClass注解和ConditionalOnMissingClass注解上的条件都已经通过了。returnConditionOutcome.match(matchMessage);}}
到这里,我们把抽象父类
SpringBootCondition
的
matches()
模版方法,和具体实现类
OnClassCondition
的
getMatchOutcome()
真正方法搞定后,就已经对
@ConditionalOnClass
和
@ConditionalOnMissingClass
这两个注解的实现原理搞清楚了。
调用场景
上面我们搞清楚
@ConditionalOnClass
和
@ConditionalOnMissingClass
这两个注解了,但他们内部的逻辑是如何调用的呢?也就是说springboot在启动过程中,如果通过这两个注解实现自动装配的呢?
一般我们能想到的是通过
AOP
对这两个注解实现切面,在切面里进行装配。但其实不是的,我们继续往下看。
要想知道
matches()
方法如何被调用起来,打个断点不就行了。
如下图所示,我在
OnClassCondition
的
getMatchOutcome()
方法上打个条件断点,以rabbitmq的自动装配为例,给该断点添加条件,当方法参数
metadata
表示的类为
RabbitAutoConfiguration
时,进入断点。
下面我们启动项目,当springboot要对rabbitmq进行自动装配时,我们可以看到进入断点了。
那如何查看该方法是被谁调用的呢?在上面源码的解析中,我们知道该方法是被其抽象父类的模版方法
matches()
所调用的。那
matches()
方法又是谁调用的呢?这就涉及到框架源码的阅读技巧了。把目光放在idea的左下方,可以看到方法的调用栈,而栈顶就是断点的方法
getMatchOutcome()
,点击下面的一层就可以回到抽象父类的模版方法
matches()
再点击调用栈下面的一层,就可以看到调用
matches()
方法的地方
shouldSkip()
方法是springboot启动过程中重要的一环。大家都知道springboot在启动过程中会将很多类作为spring的Bean放在IOC容器中,但有些类是不需要添加到容器中的,这种情况下
shouldSkip()
方法就返回true表示应当跳过当前类不要把它放到IOC容器中。
而**在
shouldSkip()
方法中,判断当前类应当跳过的重要依据就是
matches()
方法返回false(即条件判断不通过)。**
springboot的启动流程以及
shouldSkip()
方法我们留到以后再聊。拜拜
纸上得来终觉浅,绝知此事要躬行。
————————————————我是万万岁,我们下期再见————————————————
版权归原作者 理想万岁万万岁 所有, 如有侵权,请联系我们删除。