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

專註Java領域分享、成長，拒絕淺嘗輒止。關注公眾號【BAT的烏托邦】開啟專欄式學習，拒絕淺嘗輒止。本文 //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;
	}

步驟總結：

  1. 根據Bean定義資訊解析成為一個註解元數據對象AnnotationMetadata metadata
    1. 可能是個AnnotatedBeanDefinition，也可能是個StandardAnnotationMetadata
  2. 根據註解元數據metadata判斷是否是個@Configuration配置類，有如下三種可能case：
    1. 標註有@Configuration註解並且該註解的proxyBeanMethods = false，那麼mark一下它是Full模式的配置。否則進入下一步判斷
    2. 標註有@Configuration註解或者符合Lite模式的條件（上文有說一共有5種可能是Lite模式，源碼處在isConfigurationCandidate(metadata)這個方法里表述），那麼mark一下它是Lite模式的配置。否則進入下一步判斷
    3. 不是配置類，並且返回結果return false
  3. 能進行到這一步，說明該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配置類的理解，你至少應該掌握了如下訊息：

  1. @Configuration配置類肯定是個組件，存在於IoC容器里
  2. @Configuration配置類是有主次之分的，主配置類是驅動整個程式的入口，可以是一個，也可以是多個（若存在多個，支援使用@Order排序）
  3. 我們平時一般只書寫次配置類（而且一般寫多個），它一般是藉助主配置類的@ComponentScan能力完成載入進而解析的（當然也可能是@Import、又或是被其它次配置類驅動的）
  4. 配置類可以存在嵌套（如內部類），繼承，實現介面等特性

聊完了最為重要的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());
	}

步驟總結：

  1. 若是介面類型（含註解類型），直接不予考慮，返回false。否則繼續判斷
  2. 若此類上標註有@Component、@ComponentScan、@Import、@ImportResource任意一個註解，就判斷成功返回true。否則繼續判斷
  3. 到此步，就說明此類上沒有標註任何註解。若存在@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;
		}

思考題？

  1. 既然isConfigurationCandidate()判斷方法是為checkConfigurationClassCandidate()服務，那Spring為何也把它設計為public static呢？
  2. ConfigurationClassUtils里還存在對@Order順序的解析方法，不是說Spring的Bean是無序的嗎？這又如何理解呢？

總結

本文作為上篇文章的續篇，解釋了@Configuration配置的Full模式和Lite模式的判斷原理，同時順帶的也介紹了什麼叫主配置配和次配置類，這個概念（雖然官方並不這麼叫）對你理解Spring Framework是非常有幫助的。如果你使用是基於Spring 5.2.0+的版本，在了解了這兩篇文章內容的基礎上，建議你的配置類均採用Lite模式去做，即顯示設置proxyBeanMethods = false。

另外關於此部分內容，有些更為感興趣的小夥伴問到：為什麼Full模式下通過方法調用指向的仍舊是原來的Bean，保證了只會執行一次呢？開啟的是Full模式這只是表象原因，想要回答此問題需要涉及到CGLIB增強實現的深水區內容，為了滿足這些好奇（好學）的娃子，計劃會在下篇文章繼續再拿一篇專程講解（預計篇幅不短，萬字以上），你可訂閱我的公眾號持續保持關注。

Tags:

VirMach 便宜 VPS

QNews

QNews