品Spring:負責bean定義註冊的兩個「排頭兵」

  • 2019 年 10 月 3 日
  • 筆記

別看Spring現在玩的這麼花,其實它的“籌碼”就兩個,“容器”和“bean定義”。

只有先把bean定義註冊到容器里,後續的一切可能才有可能成為可能。

所以在進階的路上如果要想走的順暢些,徹底搞清楚bean定義註冊的所有細節至關重要。

畢竟這是萬里長征的第一步。有句話怎麼說來著,“勿在浮沙築高台”。


Spring步入註解和Java配置的時代也有些時日了。而且也旗幟鮮明的表達了bean的註冊方法。

這不,就是這個介面,AnnotationConfigRegistry,如下圖01:


再來看下這個介面的名字,有三個單片語成,Annotation、Config、Registry。

第一個表示註解,第二個表示Java配置,第三個表示註冊。

合起來的意思可以理解為,基於註解和Java配置的bean定義註冊。當然,這是我猜的,哈哈哈。

這是一個很牛X的介面,理由見下圖02:

 

納尼,所有的容器類都實現了它。

不管是web的、非web的,傳統Spring的、SpringBoot的,響應式的、Servlet的。

簡直是老少通吃、婦孺皆宜啊。淡定、淡定。

這個介面的兩個方法非常簡約:

一個是直接把一個類(Class<?>)進行註冊。

一個是通過掃描指定的包(Package)里的類進行註冊。

請注意我剛剛使用了“簡約”而沒有使用“簡單”,因為簡約往往並不等於簡單,反而更多時候等於難。


講了這麼多,終於可以讓今天的主角登場了,來來來,掌聲響起來。

就是這兩個類:

AnnotatedBeanDefinitionReader

ClassPathBeanDefinitionScanner

第一個類就是站在介面第一個方法register背後默默付出的。

第二個類就是負責搞定介面第二個方法scan後面所有事情的。

下面開始進行具體的講解,只需要知道都幹了什麼即可,至於怎麼乾的,不需要了解。

看第一個類,如下圖03:

 

第一個欄位類型是BeanDefinitionRegistry,這是容器(或bean factory)會實現的介面。

用於把一個BeanDefinition(bean定義)註冊到容器中,看下它的這個方法,如下圖04:

 

編程新說注:對“bean定義”這個概念不清楚的,可以在文末查看本系列《品Spring》文章的頭幾篇。

剛剛應該看到在註冊bean定義時需要一個bean名稱(即beanName),因此該第二個欄位發揮作用了。

它就是BeanNameGenerator。例如,有一個類是UserController,它上面標了註解@Controller("user")。

首先它會把註解的value屬性作為名稱,此時就是user啦。

如果沒有指定value屬性,就像這樣@Controller,此時就是類的短名稱且首字母小寫,即userController。

這就是bean名稱的生成策略,在實際開發中不就是這樣的嘛。

第三個欄位是ScopeMetadataResolver,是來決定bean實例的範圍(即生命周期)的。

常見的生命周期有四種,PROTOTYPE(原型)、SINGLETON(單例)、REQUEST(請求)、SESSION(會話)。

就是通過檢查類上有沒有@Scope這個註解。如果有的話,就按指定的走,沒有的話,就按單例走。

第四個欄位是ConditionEvaluator,條件計算器,根據“條件”判斷一個bean定義該不該被註冊。

這可是SpringBoot自動配置(AutoConfiguration)的基石啊。

就是去檢測類上有沒有標@Conditional這個註解。如果沒有的話,bean定義會被註冊。

如果有的話,需要再去計算具體的“條件”,然後才能確定bean定義到底要不要註冊。

哎呀,註冊一個bean定義好麻煩啊,喘口氣,繼續吧。嘿嘿。


下面開始真正進入註冊的方法,先看下方法的參數吧,如下圖05:

 

 

方法共有5個參數,只有第一個是必須的,後面的都可以為空。

第一個參數,annotatedClass,是Class<?>,表示要被註冊的類。

第二個參數,instanceSupplier,是一個函數式介面,Supplier<T>,可以提供這個bean的實例對象,這樣就不再需要通過反射調用構造函數了。

第三個參數,name,bean名稱,如果傳的話就不用再生成了。

第四個參數,qualifiers,是一組用作限定修飾符的註解,Class<? extends Annotation>[]。

第五個參數,definitionCustomizers,是一組可以自定義bean定義的介面,BeanDefinitionCustomizer。

整個處理過程分為九步,如下圖06:

 

第一步,先把類轉變為bean定義,即把Class<?>轉變為BeanDefinition。具體是AnnotatedGenericBeanDefinition這個類。

第二步,使用條件計算器來確定是否要註冊這個bean定義。

第三步,確定這個bean的生命周期。

第四步,確定這個bean的名稱。

第五步,處理定義的公共註解資訊。如下圖07:

 

就是@Lazy、@Primary、@DependsOn、@Role、@Description這五個註解。

從類上分別獲取這些註解,然後從註解中讀出需要的資訊,再把這些資訊設置到bean定義中。

第六步,處理限定修飾符,就是@Primary、@Lazy、@Qualifier這三個註解。

這個幾個註解是從方法參數傳入的,上一步的註解是從類上讀取的,它們不重複也不衝突。

編程新說注:這些註解的含義和用法,這裡就不說了,畢竟這是“追求深度”的文章。

第七步,應用bean定義自定義器,對bean定義進行一些自定義。

第八步,根據bean的生命周期,使用AOP技術為該bean定義生成代理。

第九步,把這個bean定義註冊到容器中。

這就是一個bean定義的完整註冊過程。媽呀,讓我歇會兒。

編程新說注:第二個類註冊bean定義的整體邏輯和第一個類完全一樣。只是獲取bean定義的方式不同。

下面看第二個類,如下圖08:

 

首先可以看到,它掃描的都是jar包中的.class文件。

然後還有兩個過濾器集合,決定哪些被排除、哪些被包含。

當然,類中也給出了默認情況下包含的,如下圖09:

 

第一,@Component註解以及用它定義的其它註解,如@Configuration等。

第二,JSR-250裡面的@javax.annotation.ManagedBean註解。

第三,JSR-330裡面的@javax.inject.Named註解。

標了這三個註解的類都會被註冊,第一個註解是Spring的,後兩個是Java的。

默認情況下,排除過濾器沒有指定,也就是不進行任何顯式的排除。

具體收集bean定義的過程,分為七步,如下圖10:

 

第一步,拼接資源路徑,形式就是這樣classpath*:org/cnt/ts/**/*.class。

它表示搜索類路徑下所有的jar包里,以org/cnt/ts開頭的包及其子包里的所有.class文件。

第二步,找出上一步中的那些.class文件,並把它們轉化為資源,即Resource類。

第三步,使用ASM框架逐個讀取這些資源(其實就是位元組碼文件啦)。

第四步,應用過濾器和條件計算器,來確定這個bean定義是否要被註冊。

如下圖11:

 

第五步,使用從位元組碼中讀出的內容來構建BeanDefinition,使用的是ScannedGenericBeanDefinition這個類。

第六步,確認下這個類是否符合要求,如下圖12:

 

一共有三項檢查:

第一,必須是獨立的。可以是頂級類(非內部類),可以是靜態內部類(即static class)。

第二,必須是具體的,即非抽象的。

第三,如果類是抽象的,它必須包含一個標有@Lookup註解的方法,來指定一個具體的bean。

第七步,收集好這個bean定義。

這些bean定義抽取好後,剩下的處理就和第一個類一樣了。

如下圖13:

 

 

也是確定生命周期,生成bean名稱,處理定義的公共註解資訊,根據生命周期生成代理,最後註冊到容器中。

最後聲明一點:

以上兩個類並不處理@Bean這個註解註冊的bean定義,也不處理由@Import註解引入的bean定義。

哪誰處理呢?後續文章見。

>>> 品Spring系列文章 <<<

 

品Spring:帝國的基石

品Spring:bean定義上梁山

品Spring:實現bean定義時採用的“先進生產力”

品Spring:註解終於“成功上位”

品Spring:能工巧匠們對註解的“加持”

品Spring:SpringBoot和Spring到底有沒有本質的不同?

 

作者是工作超過10年的碼農,現在任架構師。喜歡研究技術,崇尚簡單快樂。追求以通俗易懂的語言解說技術,希望所有的讀者都能看懂並記住。下面是公眾號和知識星球的二維碼,歡迎關注!

 

       

 

Tags: