Spring條件注解@ConditionnalOnClass的原理分析
前言
用過(guò)springboot的小伙伴們都知道,相比于spring,它最大的優(yōu)勢(shì)是幫我們省去了一大堆超大一堆繁瑣的配置。比如在spring中,當(dāng)我們需要在項(xiàng)目中整合第三方插件(如redis、mybatis、rabbitmq)時(shí),往往需要在xml配置文件中去配置這些插件的ConnectionFactory等將其與spring進(jìn)行整合。而在springboot中,他會(huì)根據(jù)項(xiàng)目中引入哪些插件自動(dòng)地將插件進(jìn)行整合,這都得益于springboot的自動(dòng)裝配 或稱為 自動(dòng)配置。
那么springboot是如何知道我們項(xiàng)目中引入了哪些插件,又怎么知道需要幫助我們配置哪些插件呢?
介紹
所謂@ConditionalOnClass注解,翻譯過(guò)來(lái)就是基于class的條件,它為所標(biāo)注的類或方法添加限制條件,當(dāng)該條件的值為true時(shí),其所標(biāo)注的類或方法才能生效?;赾lass的意思是在類路徑classpath中存在value()屬性指定的類或存在name()屬性指定的類名。
為了讓上面的介紹更加容易理解,我們就舉個(gè)例子吧
在rabbitmq的自動(dòng)配置類RabbitAutoConfiguration中,有一行注解為@ConditionalOnClass({ RabbitTemplate.class, Channel.class }),則表示當(dāng)類路徑classpath中存在 RabbitTemplate 和 Channel這兩個(gè)類時(shí),該條件注解才會(huì)通過(guò),rabbitmq的自動(dòng)配置RabbitAutoConfiguration才會(huì)生效。如下圖所示。由于我項(xiàng)目中已經(jīng)引入了rabbitmq的依賴,該依賴中存在著兩個(gè)類,因此該條件是通過(guò)的。

在redis的自動(dòng)配置類RedisAutoConfiguration中,有一行注解為@ConditionalOnClass(RedisOperations.class),則表示當(dāng)類路徑classpath中存在 RedisOperations 這個(gè)類時(shí),該條件注解才會(huì)通過(guò),redis的自動(dòng)配置RedisAutoConfiguration才會(huì)生效。如下圖所示。由于我項(xiàng)目中沒(méi)有引入redis的依賴,類路徑classpath中不存在RedisOperations,因此該條件是不通過(guò)的,從代碼爆紅即可得知。

正文
是否覺(jué)得這個(gè)注解如此流批?今天我們從源碼扒開它神秘的面紗。
先看一下該注解的源碼,該注解只提供給我們兩個(gè)屬性,實(shí)現(xiàn)條件的邏輯在哪呢?
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnClassCondition.class)
public @interface ConditionalOnClass {
// The classes that must be present.
Class<?>[] value() default {};
// The classes names that must be present.
String[] name() default {};
}
我們應(yīng)當(dāng)注意到該注解上還有另一個(gè)注解@Conditional(OnClassCondition.class),它才是@ConditionalOnClass注解的核心所在。
那么我們就看一下@Conditional()注解的源碼。該注解通過(guò)value()屬性接收一個(gè)Condition數(shù)組的參數(shù)。
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Conditional {
/**
* All {@link Condition} classes that must {@linkplain Condition#matches match}
* in order for the component to be registered.
*/
Class<? extends Condition>[] value();
}
那么Condition又是什么?繼續(xù)看源碼。從源碼中我們知道,Condition是一個(gè)接口,其內(nèi)部聲明一個(gè)方法matches(),且返回boolean類型的值。
@FunctionalInterface
public interface Condition {
/**
* 決定條件是否通過(guò)
* @param context - 條件上下文
* @param metadata - 元數(shù)據(jù),里面標(biāo)注該注解的類或方法
* @return true-通過(guò),false-不通過(guò)
**/
boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
}至此,通過(guò)兩個(gè)注解 + 一個(gè)接口,我們可以對(duì)@ConditionalOnClass注解得出以下結(jié)論:
@Conditional注解接收Condition類型的參數(shù),通過(guò)其matches()方法的返回值判斷條件是否通過(guò),而在@ConditionalOnClass注解上向@Conditional注解傳入的實(shí)際類型為Condition的實(shí)現(xiàn)類OnClassCondition。
現(xiàn)在,我們只需要把目光轉(zhuǎn)移到Condition接口的實(shí)現(xiàn)類OnClassCondition上面來(lái)。
OnClassCondition類
OnClassCondition類表示為基于classpath類路徑下的條件,因此它在對(duì)條件進(jìn)行判斷時(shí),都是從classpath類路徑中進(jìn)行判斷的。這一點(diǎn)從命名上可以看出。 先看一下該類的UML圖吧,對(duì)源碼的閱讀有所幫助。

從圖中我們看到,中間兩個(gè)類SpringBootCondition 和 FilteringSpringBootCondition均為抽象類,而OnClassCondition為具體實(shí)現(xiàn)類,因此我們猜測(cè)這里定有模版方法的設(shè)計(jì)模式,這使代碼讀起來(lái)可能有點(diǎn)跳來(lái)跳去。
那么我們看一下OnClassCondition是如何實(shí)現(xiàn)接口Condition的matches()方法的。但是找來(lái)找去并為找到matches()方法,其實(shí)該方法是在其父類SpringBootCondition中實(shí)現(xiàn)的。
public abstract class SpringBootCondition implements Condition {
private final Log logger = LogFactory.getLog(getClass());
/**
* matches()方法的實(shí)現(xiàn)————決定條件是否通過(guò)
* @param context - 條件上下文
* @param metadata - 元數(shù)據(jù),里面標(biāo)注該注解的類或方法
* @return true-通過(guò),false-不通過(guò)
**/
@Override
public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
// 獲取方法名或類名
String classOrMethodName = getClassOrMethodName(metadata);
try {
// 對(duì)元數(shù)據(jù)進(jìn)行判斷,看是否符合要求。
// ConditionOutcome中封裝了判斷的結(jié)果和相應(yīng)的結(jié)果信息,
ConditionOutcome outcome = getMatchOutcome(context, metadata);
// 日志,
logOutcome(classOrMethodName, outcome);
// 記錄
recordEvaluation(context, classOrMethodName, outcome);
// 如果isMatch()的值為true,則表示條件通過(guò)
return outcome.isMatch();
}
catch (NoClassDefFoundError ex) {
// 拋出IllegalStateException異常
}
catch (RuntimeException ex) {
// 拋出IllegalStateException異常
}
}
public abstract ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata);
}從SpringBootCondition抽象類中實(shí)現(xiàn)的matches()方法來(lái)看,它只是提供了一個(gè)模版,而真正對(duì)條件進(jìn)行判斷的邏輯在其抽象方法getMatchOutcome()中,OnClassCondition類對(duì)該抽象方法提供了實(shí)現(xiàn)。這就是設(shè)計(jì)模式—模版方法的體現(xiàn)。
class OnClassCondition extends FilteringSpringBootCondition {
// 該方法分三部分
// 1. 處理ConditionalOnClass注解
// 2. 處理ConditionalOnMissingClass注解
// 3. 返回條件判斷的結(jié)果
@Override
public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
ClassLoader classLoader = context.getClassLoader();
// 通過(guò)靜態(tài)方法,創(chuàng)建一個(gè)ConditionMessage實(shí)例,用來(lái)保存條件判斷結(jié)果對(duì)應(yīng)的信息
ConditionMessage matchMessage = ConditionMessage.empty();
// 1. 處理ConditionalOnClass注解
// 獲取該元數(shù)據(jù)表示的類或方法上的ConditionalOnClass注解中標(biāo)注的類的限定名,
// 表示這些類應(yīng)當(dāng)在classpath類路徑中存在,所以叫onClass
// 例如:@ConditionalOnClass({ RabbitTemplate.class, Channel.class }),
// 則返回RabbitTemplate和Channel的全限定類名
List<String> onClasses = getCandidates(metadata, ConditionalOnClass.class);
if (onClasses != null) {
// filter()方法內(nèi)部 對(duì)onClass表示的類進(jìn)行反射,條件為MISSING,
// 如果得到的集合不為空,則說(shuō)明類路徑中不存在ConditionalOnClass注解中標(biāo)注的類
// 這種情況下直接通過(guò)ConditionOutcome.noMatch()封裝ConditionOutcome條件判斷的結(jié)果并返回,noMatch()即表示不通過(guò)。
List<String> missing = filter(onClasses, ClassNameFilter.MISSING, classLoader);
if (!missing.isEmpty()) {
return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class)
.didNotFind("required class", "required classes").items(Style.QUOTE, missing));
}
// 對(duì)ConditionalOnClass注解的條件判斷通過(guò),并保存對(duì)應(yīng)的信息到matchMessage
matchMessage = matchMessage.andCondition(ConditionalOnClass.class)
.found("required class", "required classes")
.items(Style.QUOTE, filter(onClasses, ClassNameFilter.PRESENT, classLoader));
}
// 2. 處理ConditionalOnMissingClass注解
// 獲取該元數(shù)據(jù)表示的類或方法上的ConditionalOnMissingClass注解中標(biāo)注的類的限定名,
// 表示這些類應(yīng)當(dāng)在classpath類路徑中不存在,所以叫onMissingClass
// 例如:@ConditionalOnMissingClass({ RabbitTemplate.class, Channel.class }),
// 則返回RabbitTemplate和Channel的全限定類名
List<String> onMissingClasses = getCandidates(metadata, ConditionalOnMissingClass.class);
if (onMissingClasses != null) {
// filter()方法內(nèi)部 對(duì)onMissingClasses表示的類進(jìn)行反射,條件為PRESENT,
// 如果得到的集合不為空,則說(shuō)明類路徑中存在ConditionalOnMissingClass注解中標(biāo)注的類
// 這種情況下直接通過(guò)ConditionOutcome.noMatch()封裝ConditionOutcome條件判斷的結(jié)果并返回,noMatch()即表示不通過(guò)。
List<String> present = filter(onMissingClasses, ClassNameFilter.PRESENT, classLoader);
if (!present.isEmpty()) {
return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class)
.found("unwanted class", "unwanted classes").items(Style.QUOTE, present));
}
// 對(duì)ConditionalOnMissingClass注解的條件判斷通過(guò),并保存對(duì)應(yīng)的信息到matchMessage
matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class)
.didNotFind("unwanted class", "unwanted classes")
.items(Style.QUOTE, filter(onMissingClasses, ClassNameFilter.MISSING, classLoader));
}
// 3. 返回條件判斷的結(jié)果,到這一步,就說(shuō)明ConditionalOnClass注解和ConditionalOnMissingClass注解上的條件都已經(jīng)通過(guò)了。
return ConditionOutcome.match(matchMessage);
}
}到這里,我們把抽象父類SpringBootCondition的matches()模版方法,和具體實(shí)現(xiàn)類OnClassCondition的getMatchOutcome()真正方法搞定后,就已經(jīng)對(duì)@ConditionalOnClass和@ConditionalOnMissingClass這兩個(gè)注解的實(shí)現(xiàn)原理搞清楚了。
調(diào)用場(chǎng)景
上面我們搞清楚@ConditionalOnClass和@ConditionalOnMissingClass這兩個(gè)注解了,但他們內(nèi)部的邏輯是如何調(diào)用的呢?也就是說(shuō)springboot在啟動(dòng)過(guò)程中,如果通過(guò)這兩個(gè)注解實(shí)現(xiàn)自動(dòng)裝配的呢?
一般我們能想到的是通過(guò)AOP對(duì)這兩個(gè)注解實(shí)現(xiàn)切面,在切面里進(jìn)行裝配。但其實(shí)不是的,我們繼續(xù)往下看。
要想知道m(xù)atches()方法如何被調(diào)用起來(lái),打個(gè)斷點(diǎn)不就行了。
如下圖所示,我在OnClassCondition的getMatchOutcome()方法上打個(gè)條件斷點(diǎn),以rabbitmq的自動(dòng)裝配為例,給該斷點(diǎn)添加條件,當(dāng)方法參數(shù)metadata表示的類為RabbitAutoConfiguration時(shí),進(jìn)入斷點(diǎn)。

下面我們啟動(dòng)項(xiàng)目,當(dāng)springboot要對(duì)rabbitmq進(jìn)行自動(dòng)裝配時(shí),我們可以看到進(jìn)入斷點(diǎn)了。

那如何查看該方法是被誰(shuí)調(diào)用的呢?在上面源碼的解析中,我們知道該方法是被其抽象父類的模版方法matches()所調(diào)用的。那matches()方法又是誰(shuí)調(diào)用的呢?這就涉及到框架源碼的閱讀技巧了。把目光放在idea的左下方,可以看到方法的調(diào)用棧,而棧頂就是斷點(diǎn)的方法getMatchOutcome(),點(diǎn)擊下面的一層就可以回到抽象父類的模版方法matches()

再點(diǎn)擊調(diào)用棧下面的一層,就可以看到調(diào)用matches()方法的地方

shouldSkip()方法是springboot啟動(dòng)過(guò)程中重要的一環(huán)。大家都知道springboot在啟動(dòng)過(guò)程中會(huì)將很多類作為spring的Bean放在IOC容器中,但有些類是不需要添加到容器中的,這種情況下shouldSkip()方法就返回true表示應(yīng)當(dāng)跳過(guò)當(dāng)前類不要把它放到IOC容器中。
而在shouldSkip()方法中,判斷當(dāng)前類應(yīng)當(dāng)跳過(guò)的重要依據(jù)就是matches()方法返回false(即條件判斷不通過(guò))。
到此這篇關(guān)于Spring條件注解@ConditionnalOnClass的原理分析的文章就介紹到這了,更多相關(guān)條件注解@ConditionnalOnClass內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Intellij IDEA 2019 最新亂碼問(wèn)題及解決必殺技(必看篇)
大家在使用Intellij IDEA 的時(shí)候會(huì)經(jīng)常遇到各種亂碼問(wèn)題,今天小編給大家分享一些關(guān)于Intellij IDEA 2019 最新亂碼問(wèn)題及解決必殺技,感興趣的朋友跟隨小編一起看看吧2020-04-04
java實(shí)現(xiàn)IP地址轉(zhuǎn)換
這篇文章主要為大家詳細(xì)介紹了java實(shí)現(xiàn)IP地址轉(zhuǎn)換,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2021-11-11
Java實(shí)現(xiàn)在線考試系統(tǒng)與設(shè)計(jì)(學(xué)生功能)
這篇文章主要介紹了Java實(shí)現(xiàn)在線考試系統(tǒng)與設(shè)計(jì)(學(xué)生功能),本文通過(guò)實(shí)例代碼給大家介紹的非常詳細(xì),具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-02-02
SpringBoot詳細(xì)分析自動(dòng)裝配原理并實(shí)現(xiàn)starter
相對(duì)于傳統(tǒng)意義上的Spring項(xiàng)目,SpringBoot具有開箱即用,簡(jiǎn)化配置,內(nèi)置Tomcat等等等等一系列的特點(diǎn)。在這些特點(diǎn)中,最重要的兩條就是約定優(yōu)于配置和自動(dòng)裝配2022-07-07
關(guān)于MyBatisSystemException異常產(chǎn)生的原因及解決過(guò)程
文章講述了在使用MyBatis進(jìn)行數(shù)據(jù)庫(kù)操作時(shí)遇到的異常及其解決過(guò)程,首先考慮了事務(wù)問(wèn)題,但未解決,接著懷疑是MyBatis的一級(jí)緩存問(wèn)題,關(guān)閉緩存后問(wèn)題依舊存在,最終發(fā)現(xiàn)是SQL映射文件中的參數(shù)傳遞錯(cuò)誤,使用了錯(cuò)誤的標(biāo)簽導(dǎo)致循環(huán)插入2025-01-01

