你知道什么是 @Component 注解的派生性嗎?
對于 @Component? 注解在日常的工作中相信很多小伙伴都會使用到,作為一種 Spring? 容器托管的通用模式組件,任何被 @Component? 注解標注的組件都會被 Spring 容器掃描。
那么有的小伙伴就要問了,很多時候我們并沒有直接寫 @Component? 注解呀,寫的是類似于 @Service,@RestController,@Configuration? 等注解,不也是一樣可以被掃描到嗎?那這個 @Component 有什么特別的嗎?
元注解
在回答上面的問題之前,我們先來了解一下什么叫元注解,所謂元注解就是指一個能聲明在其他注解上的注解,換句話說就是如果一個注解被標注在其他注解上,那么它就是元注解。
要說明的是這個元注解并不是 Spring? 領(lǐng)域的東西, 而是 Java? 領(lǐng)域的,像 Java? 中的很多注解比如 @Document,@Repeatable? ,@Target 等都屬于元注解。
根據(jù)上面的解釋我們可以發(fā)現(xiàn)在 Spring? 容器里 @Component
Configuration
controller
@Component 的派生性
通過上面的內(nèi)容我們是不是可以猜測一下那就是 @Component? 注解的特性被"繼承"下來了?這就可以解釋為什么我們可以直接寫@Service,@RestController? 注解也是可以被掃描到的。但是由于 Java 的注解是不支持繼承的,比如你想通過下面的方式來實現(xiàn)注解的繼承是不合法的。
@interface
為了驗證我們的猜想,可以通過跟蹤源代碼來驗證一下,我們的目的是研究為什么不直接使用 @Component? 注解也能被 Spring? 掃描到,換句話說就是使用 @Service? 和 @RestController? 的注解也能成為 Spring Bean。
那我們很自然的就可以想到,在掃描的時候一定是根據(jù)注解來進行了判斷是否要初始化成 Spring Bean 的。我們只要找到了判斷條件就可以解決我們的疑惑了。
由于 SpringBoot? 項目是通過 main? 方法進行啟動的,調(diào)試起來還是很方便的,阿粉這邊準備了一個簡單的 SpringBoot? 工程,里面除了啟動類之外只有一個DemoController.java 代碼如下
啟動類如下
Debug run? 方法,我們可以定位到 org.springframework.boot.SpringApplication#run(java.lang.String...) ?方法,該方法里面會初始化 SpringBoot? 上下文 context。
默認情況下會進到下面的方法,并創(chuàng)建 AnnotationConfigServletWebServerApplicationContext? 并且其構(gòu)造函數(shù)中構(gòu)造了 ClassPathBeanDefinitionScanner 類路徑 Bean 掃描器。此處已經(jīng)越來越接近掃描相關(guān)的內(nèi)容了。
org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext.Factory#create
context? 上下文創(chuàng)建完成過后,接下來我們我們會接入到 org.springframework.context.support.AbstractApplicationContext#refresh?,再到 org.springframework.context.support.AbstractApplicationContext#invokeBeanFactoryPostProcessors
org.springframework.context.annotation.ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry
org.springframework.context.annotation.ConfigurationClassPostProcessor#processConfigBeanDefinitions
經(jīng)過上面的步驟,最終可以可以定位到掃描的代碼在下面的方法 org.springframework.context.annotation.ComponentScanAnnotationParser#parse? 里面,調(diào)用前面上下文初始化的掃描器的 org.springframework.context.annotation.ClassPathBeanDefinitionScanner#doScan 方法,
到這里我們已經(jīng)定位到了掃描具體包路徑的方法,這個方法里面主要看 findCandidateComponents(basePackage); 方法的內(nèi)容,這個方法就是返回合法的候選組件。說明這個方法會最終返回需要被注冊成 Spring Bean 的候選組件,那我們重點就要看這個方法的實現(xiàn)。
跟蹤這個方法 org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider#findCandidateComponents? 進去我們可以看到通過加進類路徑里面的資源文件,然后再根據(jù)資源文件生成 MetadataReader? 對象,最后判斷這個 MetadataReader? 對象是否滿足候選組件的條件,如果滿足就添加到 Set 集合中進行返回。
繼續(xù)追蹤源碼我們可以找到具體的判斷方法在 org.springframework.core.type.filter.AnnotationTypeFilter#matchSelf? 方法中,如下所示,可以看到這里對 MetadataReader? 對象進行了判斷是否有元注解 @Component?。在調(diào)試的時候我們會發(fā)現(xiàn) DemoController? 在此處會返回 true?,并且該 MetadataReader? 對象里面還有多個 mappings? ,其實這些 mappings? 對應(yīng)的就是 Spring 的注解。
這個 mappings? 里面的注解確實包含了 @Component? 注解,因此會返回 true?。那么接下來問題就轉(zhuǎn)換成,我們的 DemoController? 對應(yīng)的 MetadataReader 對象是如何創(chuàng)建的。
我們看回到 org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider#scanCandidateComponents? 方法,看看具體 MetadataReader 對象是如何創(chuàng)建的,MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);
通過構(gòu)造方法 org.springframework.core.type.classreading.SimpleMetadataReader#SimpleMetadataReader? 進行 MetadataReader? 對象的創(chuàng)建,org.springframework.core.type.classreading.SimpleAnnotationMetadataReadingVisitor#visitEnd?,最終定位到 org.springframework.core.annotation.MergedAnnotationsCollection#MergedAnnotationsCollection? 這里進行 mappings 賦值。
繼續(xù)定位到 org.springframework.core.annotation.AnnotationTypeMappings.Cache#createMappings,org.springframework.core.annotation.AnnotationTypeMappings#addAllMappings,addAllmappings? 方法,內(nèi)部使用了一個 while? 循環(huán)和 Deque? 來循環(huán)查詢元注解進行賦值,代碼如下所示,重點是這一行 Annotation[] metaAnnotations = AnnotationsScanner.getDeclaredAnnotations(source.getAnnotationType(), false);
綜上所述我們可以發(fā)現(xiàn)盡管我們沒有直接寫 @Component? 注解,只要我們加了類似于 @Service,@RestController? 等注解也是可以成功被 Spring? 掃描到注冊成 Spring Bean? 的,本質(zhì)的原因是因為這些注解底層都使用了 @Component? 作為元注解,經(jīng)過源碼分析我們發(fā)現(xiàn)了只要有 @Component 元注解標注的注解類也是同樣會被進行掃描的。
總結(jié)
上面的源碼追蹤過程可能會比較枯燥和繁瑣,最后我們來簡單總結(jié)一下上面的內(nèi)容:
- 方法org.springframework.boot.SpringApplication#run(java.lang.String...) ?中進行 Spring 上下文的創(chuàng)建;
- 在初始化上下文的時候會創(chuàng)建掃描器ClassPathBeanDefinitionScanner;
- 在org.springframework.context.support.AbstractApplicationContext#refresh? 進行 beanFactory 準備;
- org.springframework.context.annotation.ClassPathBeanDefinitionScanner#doScan 進行資源掃描
- 在org.springframework.core.annotation.MergedAnnotationsCollection#MergedAnnotationsCollection? 進行注解 mappings 的賦值;
- org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider#scanCandidateComponents 方法中進行候選組件的判斷;
上面追蹤的過程可能會比較復(fù)雜,但是只要我們理解了原理還是可以慢慢跟上的,因為我們只要把握好了方向,知道首先肯定會進行資源掃描,掃描完了肯定是根據(jù)注解之間的關(guān)系進行判斷,最終得到我們需要的候選組件集合。至于如何創(chuàng)建 MetadataReader 和如何獲取元注解,只要我們一步步看下去就是可以找到的。
最后說明一下,Spring Framework? 每個版本的具體實現(xiàn)會有差異,阿粉使用的版本是 5.3.24 ,所以如果小伙伴看到自己的代碼追蹤的效果跟阿粉的不一樣也不會奇怪,可能是因為版本不一樣而已,不過本質(zhì)上都是一樣的。