當大潮退去，才知道誰在裸泳。
作者：A哥（YourBatman）
公衆號：BAT的烏托邦（ID：BAT-utopia）
文末是否有彩蛋：有

前言

各位小夥伴大家好，我是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
1. 可能是個AnnotatedBeanDefinition，也可能是個StandardAnnotationMetadata
根據註解元數據metadata判斷是否是個@Configuration配置類，有如下三種可能case：
1. 標註有@Configuration註解並且該註解的proxyBeanMethods = false，那麼mark一下它是Full模式的配置。否則進入下一步判斷
2. 標註有@Configuration註解或者符合Lite模式的條件（上文有說一共有5種可能是Lite模式，源碼處在isConfigurationCandidate(metadata)這個方法裏表述），那麼mark一下它是Lite模式的配置。否則進入下一步判斷
3. 不是配置類，並且返回結果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增強實現的深水區內容，爲了滿足這些好奇（好學）的娃子，計劃會在下篇文章繼續再拿一篇專程講解（預計篇幅不短，萬字以上），你可訂閱我的公衆號持續保持關注。

關於A哥

專欄式學習咱們小衆聊，拒絕淺嘗輒止。知識星球誠邀您掃碼入駐（提示：請務必先關注公衆號，回覆 知識星球 領取優惠券後再輕裝入駐）
私人微信，掃碼加A哥好友（備註：“公衆號”），邀你進入 Java高工、架構師 系列純技術羣（或關注公衆號，回覆加羣亦可直接加入）
文章在公衆號首發，其它平臺慢1-2天。也可關注A哥的個人博客：https://www.yourbatman.cn

碼字非常不易，不可以白嫖，點個在看就表示你支持A哥的原創嘍~

所屬專欄：Spring配置類，點擊查看該專欄下所有文章
原文鏈接：程序人生 | 春風得意馬蹄疾，一日看盡長安花
公衆號：BAT的烏托邦（ID：BAT-utopia）
個人博客：https://www.yourbatman.cn
關於A哥：關於A哥
CSDN：BAT的烏托邦
博客園：BAT的烏托邦
知乎：BAT的烏托邦
掘金：BAT的烏托邦
騰訊雲+社區：BAT的烏托邦
知識星球：BAT的烏托邦
Netflix OSS套件一站式學習驛站(Eureka、Hystrix、Ribbon、Feign、Zuul…)

配置類需要標註@Configuration卻不知原因？那這次就不能給你漲薪嘍

目錄

前言

版本約定

正文

如何判斷一個組件是否是@Configuration配置？

ConfigurationClassUtils工具類

checkConfigurationClassCandidate()

方法使用處

isConfigurationCandidate()

Spring 5.2.0版本變化說明

proxyBeanMethods屬性的作用

Full模式/Lite模式實現上的差異

思考題？

總結

關於A哥

自學編程兩個月，現在我月入 4 萬元

「實戰應用」如何用圖表控件LightningChart創建2D氣泡圖

百度安全多篇議題入選Blackhat Asia以硬技術發現“芯”問題

Google Chrome驅動程序 124.0.6367.62（正式版本）去哪下載？

2個週末，歷時100+小時，YourBatman新版Blog正式上線

每天 10 分鐘，保持技術精進的方法

IntelliJ IDEA 20週歲啦，爲期2天的週年慶活動對開發者免費開放

一文告訴你Java日期時間API到底有多爛

LocalDateTime、OffsetDateTime、ZonedDateTime互轉，這一篇絕對餵飽你

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結