配置類需要標註@Configuration卻不知原因？那這次就不能給你漲薪嘍
專注Java領域分享、成長，拒絕淺嘗輒止。關注公眾號【BAT的烏託邦】開啟專欄式學習，拒絕淺嘗輒止。本文 https://www.yourbatman.cn 已收錄，裡面一併有Spring技術棧、MyBatis、中介軟體等小而美的專欄供以學習哦。
目錄
前言
各位小夥伴大家好，我是A哥。這是繼上篇文章：真懂Spring的@Configuration配置類？你可能自我感覺太良好 的原理/原始碼解釋篇。按照本公眾號的定位，原理一般跑不了，雖然很枯燥，但還得做，畢竟做難事必有所得，真的掌握了才有底氣談漲薪嘛。
Tips：鑑於經常有些同學無法區分某個功能/某項能力屬於Spring Framework的還是Spring Boot，你可以參考文章裡的【版本約定】目錄，那裡會說明本文的版本依賴，也就是功能所屬嘍。比如本文內容它就屬於Spring Framework，和Spring Boot木有關係。
版本約定
本文內容若沒做特殊說明，均基於以下版本：
- JDK：
1.8 - Spring Framework：
5.2.2.RELEASE
正文
Spring的IoC就像個“大熔爐”，什麼都當作Bean放在裡面。然而，雖然它們都放在了一起，但是實際在功能上是有區別的，比如我們熟悉的BeanPostProcessor就屬於後置處理器功能的Bean，還有本文要討論的@Configuration配置Bean也屬於一種特殊的元件。
判斷一個Bean是否是Bean的後置處理器很方便，只需看它是否實現了BeanPostProcessor介面即可；那麼如何去確定一個Bean是否是@Configuration配置Bean呢？若是，如何區分是Full模式還是Lite模式呢？這便就是本文將要討論的內容。
如何判斷一個元件是否是@Configuration配置？
首先需要明確：@Configuration配置前提必須是IoC管理的一個元件（也就是常說的Bean）。Spring使用BeanDefinitionRegistry註冊中心管理著所有的Bean定義資訊，那麼對於這些Bean資訊哪些屬於@Configuration配置呢，這是需要甄選出來的。
判斷一個Bean是否是@Configuration配置類這個邏輯統一交由ConfigurationClassUtils這個工具類去完成。
ConfigurationClassUtils工具類
見名之意，它是和配置有關的一個工具類，提供幾個靜態工具方法供以使用。它是Spring 3.1新增，對於它的作用，官方給的解釋是：用於標識@Configuration類的實用程式(Utilities)。它主要提供了一個方法：checkConfigurationClassCandidate()用於檢查給定的Bean定義是否是配置類的候選物件（或者在配置/元件類中宣告的巢狀元件類），並做相應的標記。
checkConfigurationClassCandidate()
它是一個public static工具方法，用於判斷某個Bean定義是否是@Configuration配置。
ConfigurationClassUtils：
public static boolean checkConfigurationClassCandidate(BeanDefinition beanDef, MetadataReaderFactory metadataReaderFactory) {
...
// 根據Bean定義資訊，拿到器對應的註解元資料
AnnotationMetadata metadata = xxx;
...
// 根據註解元資料判斷該Bean定義是否是配置類。若是：那是Full模式還是Lite模式
Map<String, Object> config = metadata.getAnnotationAttributes(Configuration.class.getName());
if (config != null && !Boolean.FALSE.equals(config.get("proxyBeanMethods"))) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);
} else if (config != null || isConfigurationCandidate(metadata)) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);
} else {
return false;
}
...
// 到這。它肯定是一個完整配置（Full or Lite） 這裡進一步把@Order排序值放上去
Integer order = getOrder(metadata);
if (order != null) {
beanDef.setAttribute(ORDER_ATTRIBUTE, order);
}
return true;
}
步驟總結：
- 根據Bean定義資訊解析成為一個註解元資料物件
AnnotationMetadata metadata- 可能是個
AnnotatedBeanDefinition，也可能是個StandardAnnotationMetadata
- 可能是個
- 根據註解元資料metadata判斷是否是個
@Configuration配置類，有如下三種可能case：- 標註有
@Configuration註解並且該註解的proxyBeanMethods = false，那麼mark一下它是Full模式的配置。否則進入下一步判斷 - 標註有
@Configuration註解或者符合Lite模式的條件（上文有說一共有5種可能是Lite模式，原始碼處在isConfigurationCandidate(metadata)這個方法裡表述），那麼mark一下它是Lite模式的配置。否則進入下一步判斷 - 不是配置類，並且返回結果
return false
- 標註有
- 能進行到這一步，說明該Bean肯定是個配置類了（Full模式或者Lite模式），那就取出其
@Order值（若有的話），然後mark進Bean定義裡面去
這個mark動作很有意義：後面判斷一個配置類是Full模式還是Lite模式，甚至判斷它是否是個配置類均可通過beanDef.getAttribute(CONFIGURATION_CLASS_ATTRIBUTE)這樣完成判斷。
方法使用處
知曉了checkConfigurationClassCandidate()能夠判斷一個Bean(定義)是否是一個配置類，那麼它在什麼時候會被使用呢？通過查詢可以發現它被如下兩處使用到：
- 使用處：
ConfigurationClassPostProcessor.processConfigBeanDefinitions()處理配置Bean定義階段。
ConfigurationClassPostProcessor：
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
// 拿出當前所有的Bean定義資訊，一個個的檢查是否是配置類
String[] candidateNames = registry.getBeanDefinitionNames();
for (String beanName : candidateNames) {
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) {
logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);
}
// 如果該Bean定義不是配置類，那就繼續判斷一次它是否是配置類，若是就加入結果集合裡
else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
}
...
}
ConfigurationClassPostProcessor是個BeanDefinitionRegistryPostProcessor，會在BeanFactory 準備好後執行生命週期方法。因此自然而然的，checkConfigurationClassCandidate()會在此階段呼叫，用於區分出哪些是配置Bean。
值得注意的是：ConfigurationClassPostProcessor的執行時期是非常早期的（BeanFactory準備好後就執行嘛），這個時候容器內的Bean定義很少。這個時候只有主配置類才被註冊了進來，那些想通過@ComponentScan掃進來的配置類都還沒到“時間”，這個時間節點很重要，請注意區分。為了方便你理解，我分別把Spring和Spring Boot在此階段的Bean定義資訊截圖展示如下：
以上是Spring環境，對應程式碼為：
new AnnotationConfigApplicationContext(AppConfig.class);
以上是Spring Boot環境，對應程式碼為：
@SpringBootApplication
public class Boot2Demo1Application {
public static void main(String[] args) {
SpringApplication.run(Boot2Demo1Application.class, args);
}
}
相比之下，Spring Boot裡多了
internalCachingMetadataReaderFactory這個Bean定義。原因是SB定義了一個CachingMetadataReaderFactoryPostProcessor把它放進去的，由於此Processor也是個BeanDefinitionRegistryPostProcessor並且order值為Ordered.HIGHEST_PRECEDENCE，所以它會優先於ConfigurationClassPostProcessor執行把它註冊進去~
- 使用處：
ConfigurationClassParser.doProcessConfigurationClass()解析@Configuration配置類階段。所處的大階段同上使用處，仍舊是ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry()階段
ConfigurationClassParser：
@Nullable
protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass) throws IOException {
... // 先解析nested內部類（內部類會存在@Bean方法嘛~）
... // 解析@PropertySource資源，加入到environment環境
... // 解析@ComponentScan註解，把元件掃描進來
scannedBeanDefinitions = ComponentScanAnnotationParser.parse(componentScan, ...);
// 把掃描到的Bean定義資訊依舊需要一個個的判斷，是否是配置類
// 若是配置類，就繼續當作一個@Configuration配置類來解析parse() 遞迴嘛
for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
...
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
parse(bdCand.getBeanClassName(), holder.getBeanName());
}
}
... // 解析@Import註解
... // 解析@ImportResource註解
... // 解析當前配置裡配置的@Bean方法
... // 解析介面預設方法（因為配置類可能實現介面，然後介面預設方法可能標註有@Bean ）
... // 處理父類（遞迴，直到父類為java.打頭的為止）
}
這個方法是Spring對配置類解析的最核心步驟，通過它順帶也能夠解答你的疑惑了吧：為何你僅需在類上標註一個@Configuration註解即可讓它成為一個配置類？因為被Scan掃描進去了嘛~
通過以上兩個使用處的分析和對比，對於@Configuration配置類的理解，你至少應該掌握瞭如下訊息：
@Configuration配置類肯定是個元件，存在於IoC容器裡@Configuration配置類是有主次之分的，主配置類是驅動整個程式的入口，可以是一個，也可以是多個（若存在多個，支援使用@Order排序）- 我們平時一般只書寫次配置類（而且一般寫多個），它一般是藉助主配置類的
@ComponentScan能力完成載入進而解析的（當然也可能是@Import、又或是被其它次配置類驅動的） - 配置類可以存在巢狀（如內部類），繼承，實現介面等特性
聊完了最為重要的checkConfigurationClassCandidate()方法，當然還有必要看看ConfigurationClassUtils的另一個工具方法isConfigurationCandidate()。
isConfigurationCandidate()
它是一個public static工具方法，通過給定的註解元資料資訊來判斷它是否是一個Configuration。
ConfigurationClassUtils：
static {
candidateIndicators.add(Component.class.getName());
candidateIndicators.add(ComponentScan.class.getName());
candidateIndicators.add(Import.class.getName());
candidateIndicators.add(ImportResource.class.getName());
}
public static boolean isConfigurationCandidate(AnnotationMetadata metadata) {
// 不考慮介面 or 註解 說明：註解的話也是一種“特殊”的介面哦
if (metadata.isInterface()) {
return false;
}
// 只要該類上標註有以上4個註解任意一個，都算配置類
for (String indicator : candidateIndicators) {
if (metadata.isAnnotated(indicator)) {
return true;
}
}
// 若一個註解都沒標註，那就看有木有@Bean方法 若有那也算配置類
return metadata.hasAnnotatedMethods(Bean.class.getName());
}
步驟總結：
- 若是介面型別（含註解型別），直接不予考慮，返回false。否則繼續判斷
- 若此類上標註有
@Component、@ComponentScan、@Import、@ImportResource任意一個註解，就判斷成功返回true。否則繼續判斷 - 到此步，就說明此類上沒有標註任何註解。若存在@Bean方法，返回true，否則返回false。
需要特別特別特別注意的是：此方法它的並不考慮@Configuration註解，是“輕量級”判斷，這是它和checkConfigurationClassCandidate()方法的最主要區別。當然，後者依賴於前者，依賴它來根據註解元資料判斷是否是Lite模式的配置。
Spring 5.2.0版本變化說明
因為本文的講解和程式碼均是基於Spring 5.2.2.RELEASE的，而並不是所有小夥伴都會用到這麼新的版本。關於此部分的實現，以Spring 5.2.0版本為分界線實現上有些許差異，所以在此處做出說明。
proxyBeanMethods屬性的作用
proxyBeanMethods屬性是Spring 5.2.0版本為@Configuration註解新增加的一個屬性：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {
@AliasFor(annotation = Component.class)
String value() default "";
// @since 5.2
boolean proxyBeanMethods() default true;
}
它的作用是：是否允許代理@Bean方法。說白了：決定此配置使用Full模式還是Lite模式。為了保持向下相容，proxyBeanMethods的預設值是true，使用Full模式配置。
Spring 5.2提出了這個屬性項，是期望你在已經瞭解了它的作用之後，顯示的把它置為false的，因為在雲原生將要到來的今天，啟動速度方面Spring一直在做著努力，也希望你能配合嘛。這不Spring Boot就“配合”得很好，它在2.2.0版本（依賴於Spring 5.2.0）起就把它的所有的自動配置類的此屬性改為了false，即@Configuration(proxyBeanMethods = false)。
Full模式/Lite模式實現上的差異
由於Spring 5.2.0新增了proxyBeanMethods屬性來控制模式，因此實現上也有些許詫異，請各位注意甄別：
Spring 5.2.0+版本判斷實現：
ConfigurationClassUtils：
Map<String, Object> config = metadata.getAnnotationAttributes(Configuration.class.getName());
if (config != null && !Boolean.FALSE.equals(config.get("proxyBeanMethods"))) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);
} else if (config != null || isConfigurationCandidate(metadata)) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);
} else {
return false;
}
Spring 5.2.0-版本判斷實現：
ConfigurationClassUtils：
if (isFullConfigurationCandidate(metadata)) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);
} else if (isLiteConfigurationCandidate(metadata)) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);
} else {
return false;
}
思考題？
- 既然
isConfigurationCandidate()判斷方法是為checkConfigurationClassCandidate()服務，那Spring為何也把它設計為public static呢？ ConfigurationClassUtils裡還存在對@Order順序的解析方法，不是說Spring的Bean是無序的嗎？這又如何理解呢？
總結
本文作為上篇文章的續篇，解釋了@Configuration配置的Full模式和Lite模式的判斷原理，同時順帶的也介紹了什麼叫主配置配和次配置類，這個概念（雖然官方並不這麼叫）對你理解Spring Framework是非常有幫助的。如果你使用是基於Spring 5.2.0+的版本，在瞭解了這兩篇文章內容的基礎上，建議你的配置類均採用Lite模式去做，即顯示設定proxyBeanMethods = false。
另外關於此部分內容，有些更為感興趣的小夥伴問到：為什麼Full模式下通過方法呼叫指向的仍舊是原來的Bean，保證了只會執行一次呢？開啟的是Full模式這只是表象原因，想要回答此問題需要涉及到CGLIB增強實現的深水區內容，為了滿足這些好奇（好學）的娃子，計劃會在下篇文章繼續再拿一篇專程講解（預計篇幅不短，萬字以上），你可訂閱我的公眾號持續保持關注。