ConfigurationClassPostProcessor —— Spring中最！最！最！重要的後置處理器！沒有之一！！！

時間  2019-11-24
標籤 configurationclasspostprocessor spring 重要 後置 處理器 沒有 之一 欄目 Spring 简体版
原文   原文鏈接

ConfigurationClassPostProcessor源碼解析

掃描文末二維碼或者微信搜索公衆號菜鳥飛呀飛，便可關注微信公衆號，閱讀更多Spring源碼分析文章java

0. 疑惑

在閱讀本文以前，能夠先思考一下如下幾個問題。spring

  • (1) @Configuration註解的做用是什麼，Spring是如何解析加了@Configuration註解的類？
  • (2) Spring在何時對@ComponentScan、@ComponentScans註解進行了解析？
  • (3) Spring何時解析了@Import註解，如何解析的？
  • (4) Spring何時解析了@Bean註解？

1. 做用

其實上面的四個問題，均可以一個類來解釋，即本文的主角： ConfigurationClassPostProcessor。那麼這個類到底是如何來解決這些問題的呢？微信

  • ConfigurationClassPostProcessor是一個BeanFactory的後置處理器，所以它的主要功能是參與BeanFactory的建造，在這個類中，會解析加了@Configuration的配置類，還會解析@ComponentScan、@ComponentScans註解掃描的包，以及解析@Import等註解。app

  • ConfigurationClassPostProcessor 實現了 BeanDefinitionRegistryPostProcessor 接口，而 BeanDefinitionRegistryPostProcessor 接口繼承了 BeanFactoryPostProcessor 接口，因此 ConfigurationClassPostProcessor 中須要重寫 postProcessBeanDefinitionRegistry() 方法和 postProcessBeanFactory()方法。而ConfigurationClassPostProcessor類的做用就是經過這兩個方法去實現的。 ide

    UML

  • ConfigurationClassPostProcessor這個類是Spring內置的一個BeanFactory後置處理器，是在this()方法中將其添加到BeanDefinitionMap中的(能夠參考筆者的另外一篇文章 mp.weixin.qq.com/s/q6zs7xRjp… )。在執行過程當中，會先執行postProcessBeanDefinitionRegistry()，而後執行postProcessBeanFactory()。源碼分析

  • 文章有點長，先用一張圖簡單描述一下執行流程。 post

    ConfigurationClassPostProcessor執行流程

2. postProcessBeanDefinitionRegistry()

  • postProcessBeanDefinitionRegistry()方法中調用了processConfigBeanDefinitions()，因此核心邏輯在processConfigBeanDefinition()方法中。
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry){
    processConfigBeanDefinitions(registry);
}
複製代碼

processConfigBeanDefinitions()方法代碼以下(省略了部分不重要的代碼)，源碼中添加了許多註釋，解釋了部分重要方法的做用。ui

public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
	List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
	String[] candidateNames = registry.getBeanDefinitionNames();

	for (String beanName : candidateNames) {
		BeanDefinition beanDef = registry.getBeanDefinition(beanName);
		if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||
				ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {
			// log 日誌
		}
        // checkConfigurationClassCandidate()會判斷一個是不是一個配置類,併爲BeanDefinition設置屬性爲lite或者full。
        // 在這兒爲BeanDefinition設置lite和full屬性值是爲了後面在使用
        // 若是加了@Configuration，那麼對應的BeanDefinition爲full;
        // 若是加了@Bean,@Component,@ComponentScan,@Import,@ImportResource這些註解，則爲lite。
        //lite和full均表示這個BeanDefinition對應的類是一個配置類
		else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
			configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
		}
	}
	// ... 省略部分代碼
	SingletonBeanRegistry sbr = null;
	if (registry instanceof SingletonBeanRegistry) {
		sbr = (SingletonBeanRegistry) registry;
		if (!this.localBeanNameGeneratorSet) {
			// beanName的生成器，由於後面會掃描出全部加入到spring容器中calss類，而後把這些class
			// 解析成BeanDefinition類，此時須要利用BeanNameGenerator爲這些BeanDefinition生成beanName
			BeanNameGenerator generator = (BeanNameGenerator) sbr.getSingleton(CONFIGURATION_BEAN_NAME_GENERATOR);
			if (generator != null) {
				this.componentScanBeanNameGenerator = generator;
				this.importBeanNameGenerator = generator;
			}
		}
	}
	// ... 省略部分代碼

	// 解析全部加了@Configuration註解的類
	ConfigurationClassParser parser = new ConfigurationClassParser(
			this.metadataReaderFactory, this.problemReporter, this.environment,
			this.resourceLoader, this.componentScanBeanNameGenerator, registry);

	Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
	Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
	do {
		// 解析配置類，在此處會解析配置類上的註解(ComponentScan掃描出的類，@Import註冊的類，以及@Bean方法定義的類)
        // 注意：這一步只會將加了@Configuration註解以及經過@ComponentScan註解掃描的類纔會加入到BeanDefinitionMap中
        // 經過其餘註解(例如@Import、@Bean)的方式，在parse()方法這一步並不會將其解析爲BeanDefinition放入到BeanDefinitionMap中，而是先解析成ConfigurationClass類
        // 真正放入到map中是在下面的this.reader.loadBeanDefinitions()方法中實現的
		parser.parse(candidates);
		parser.validate();

		Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
		configClasses.removeAll(alreadyParsed);

		// Read the model and create bean definitions based on its content
		if (this.reader == null) {
			this.reader = new ConfigurationClassBeanDefinitionReader(
					registry, this.sourceExtractor, this.resourceLoader, this.environment,
					this.importBeanNameGenerator, parser.getImportRegistry());
		}
		// 將上一步parser解析出的ConfigurationClass類加載成BeanDefinition
		// 實際上通過上一步的parse()後，解析出來的bean已經放入到BeanDefinition中了，可是因爲這些bean可能會引入新的bean，例如實現了ImportBeanDefinitionRegistrar或者ImportSelector接口的bean，或者bean中存在被@Bean註解的方法
		// 所以須要執行一次loadBeanDefinition()，這樣就會執行ImportBeanDefinitionRegistrar或者ImportSelector接口的方法或者@Bean註釋的方法
		this.reader.loadBeanDefinitions(configClasses);
		alreadyParsed.addAll(configClasses);

		candidates.clear();
		// 這裏判斷registry.getBeanDefinitionCount() > candidateNames.length的目的是爲了知道reader.loadBeanDefinitions(configClasses)這一步有沒有向BeanDefinitionMap中添加新的BeanDefinition
		// 實際上就是看配置類(例如AppConfig類會向BeanDefinitionMap中添加bean)
		// 若是有，registry.getBeanDefinitionCount()就會大於candidateNames.length
		// 這樣就須要再次遍歷新加入的BeanDefinition，並判斷這些bean是否已經被解析過了，若是未解析，須要從新進行解析
		// 這裏的AppConfig類向容器中添加的bean，實際上在parser.parse()這一步已經所有被解析了
		// 因此爲何還須要作這個判斷，目前沒看懂，彷佛沒有任何意義。
		if (registry.getBeanDefinitionCount() > candidateNames.length) {
			String[] newCandidateNames = registry.getBeanDefinitionNames();
			Set<String> oldCandidateNames = new HashSet<>(Arrays.asList(candidateNames));
			Set<String> alreadyParsedClasses = new HashSet<>();
			for (ConfigurationClass configurationClass : alreadyParsed) {
				alreadyParsedClasses.add(configurationClass.getMetadata().getClassName());
			}
			// 若是有未解析的類，則將其添加到candidates中，這樣candidates不爲空，就會進入到下一次的while的循環中
			for (String candidateName : newCandidateNames) {
				if (!oldCandidateNames.contains(candidateName)) {
					BeanDefinition bd = registry.getBeanDefinition(candidateName);
					if (ConfigurationClassUtils.checkConfigurationClassCandidate(bd, this.metadataReaderFactory) &&
							!alreadyParsedClasses.contains(bd.getBeanClassName())) {
						candidates.add(new BeanDefinitionHolder(bd, candidateName));
					}
				}
			}
			candidateNames = newCandidateNames;
		}
	}
	while (!candidates.isEmpty());

	// Register the ImportRegistry as a bean in order to support ImportAware @Configuration classes
	if (sbr != null && !sbr.containsSingleton(IMPORT_REGISTRY_BEAN_NAME)) {
		sbr.registerSingleton(IMPORT_REGISTRY_BEAN_NAME, parser.getImportRegistry());
	}

	if (this.metadataReaderFactory instanceof CachingMetadataReaderFactory) {
		((CachingMetadataReaderFactory) this.metadataReaderFactory).clearCache();
	}
}
複製代碼
2.1 ConfigurationClassUtils.checkConfigurationClassCandidate()
  • 該方法是用來判斷一個是不是一個配置類，併爲BeanDefinition設置屬性爲lite或者full。若是加了@Configuration，那麼對應的BeanDefinition爲full，若是加了@Bean，@Component，@ComponentScan，@Import，@ImportResource這些註解，則爲lite。lite和full均表示這個BeanDefinition對應的類是一個配置類。
  • 部分代碼以下：
public static boolean checkConfigurationClassCandidate(BeanDefinition beanDef, MetadataReaderFactory metadataReaderFactory) {
	// ... 省略部分不重要的代碼
	if (isFullConfigurationCandidate(metadata)) {
		// 含有@Configuration註解，那麼對應的BeanDefinition的configurationClass屬性值設置爲full
		beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);
	}
	else if (isLiteConfigurationCandidate(metadata)) {
		// 含有@Bean,@Component,@ComponentScan,@Import,@ImportResource註解
		// configurationClass屬性值設置爲lite
		beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);
	}
	else {
		return false;
	}
	return true;
}
複製代碼
  • isFullConfigurationCandidate()方法用來判斷一個類是否加了@Configuration註解
// 含有@Configuration註解
public static boolean isFullConfigurationCandidate(AnnotationMetadata metadata) {
	return metadata.isAnnotated(Configuration.class.getName());
}
複製代碼
  • isLiteConfigurationCandidate()方法用來判斷類是否加了@Bean,@Component,@ComponentScan,@Import,@ImportResource註解
// 判斷是否含有candidateIndicators這個集合中的註解
public static boolean isLiteConfigurationCandidate(AnnotationMetadata metadata) {
	// candidateIndicators 是一個靜態常量，在初始化時，包含了四個元素
	// 分別爲@Component,@ComponentScan,@Import,@ImportResource這四個註解
	// 只要這個類上添加了這四種註解中的一個，就即是這個類是一個配置類，
	// 這個類對應的BeanDefinition中的configurationClass屬性值爲lite
	for (String indicator : candidateIndicators) {
		if (metadata.isAnnotated(indicator)) {
			return true;
		}
	}
        // 查找有沒有加了@Bean註解的方法
	try {
		return metadata.hasAnnotatedMethods(Bean.class.getName());
	}
	catch (Throwable ex) {
		return false;
	}
}

private static final Set<String> candidateIndicators = new HashSet<>(8);

// 類加載至JVM時，向集合中添加了四個元素
static {
	candidateIndicators.add(Component.class.getName());
	candidateIndicators.add(ComponentScan.class.getName());
	candidateIndicators.add(Import.class.getName());
	candidateIndicators.add(ImportResource.class.getName());
}
複製代碼
2.2 parser.pase()

該方法調用的是ConfigurationClassParser.parse()，ConfigurationClassParser類，根據類名就能猜想出，這個類是用來解析配置類的。this

  • parse()方法會解析配置類上的註解(ComponentScan掃描出的類，@Import註冊的類，以及@Bean方法定義的類)，解析完之後(解析成ConfigurationClass類)，會將解析出的結果放入到parser的configurationClasses這個屬性中(這個屬性是個Map)。parse會將@Import註解要註冊的類解析爲BeanDefinition，可是不會把解析出來的BeanDefinition放入到BeanDefinitionMap中，真正放入到map中是在這一行代碼實現的: this.reader.loadBeanDefinitions(configClasses)lua

  • 下面先看下parse()的具體代碼parser.parse(candidates)， parse()方法須要一個參數，參數candidates是一個集合，集合中的元素個數由咱們寫的這一行代碼決定：

AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
複製代碼
  • 在AnnotationConfigApplicationContext的構造方法中，咱們傳入了一個AppConfig類，那麼candidates的大小爲1，裏面的元素爲AppConfig類所對應的BeanDefinitionHolder(或者說是BeanDefinition,BeanDefinitionHolder只是將BeanDefinition封裝了一下，能夠簡單的認爲二者等價)。AnnotationConfigApplicationContext構造方法能夠傳入多個類，對應的candidates的大小等於這裏傳入類的個數(這種說法其實不太嚴謹，由於AnnotationConfigApplicationContext.register()方法也能像容器中註冊配置類)
  • parse()具體代碼
public void parse(Set<BeanDefinitionHolder> configCandidates) {
	this.deferredImportSelectors = new LinkedList<>();
    // 根據BeanDefinition類型的不一樣，調用parse()不一樣的重載方法
    // 實際上最終都是調用processConfigurationClass()方法
	for (BeanDefinitionHolder holder : configCandidates) {
		BeanDefinition bd = holder.getBeanDefinition();
		try {
			if (bd instanceof AnnotatedBeanDefinition) {
				parse(((AnnotatedBeanDefinition) bd).getMetadata(), holder.getBeanName());
			}else if (bd instanceof AbstractBeanDefinition && ((AbstractBeanDefinition) bd).hasBeanClass()) {
				parse(((AbstractBeanDefinition) bd).getBeanClass(), holder.getBeanName());
			}else {
				parse(bd.getBeanClassName(), holder.getBeanName());
			}
		}
	}
	// 處理延遲importSelector
	processDeferredImportSelectors();
}
複製代碼
2.2.1 processConfigurationClass() 核心代碼

該方法的核心方法爲doProcessConfigurationClass

protected void processConfigurationClass(ConfigurationClass configClass) throws IOException {
	// 處理配置類，因爲配置類可能存在父類(若父類的全類名是以java開頭的，則除外)，全部須要將configClass變成sourceClass去解析，而後返回sourceClass的父類。
	// 若是此時父類爲空，則不會進行while循環去解析，若是父類不爲空，則會循環的去解析父類
	// SourceClass的意義：簡單的包裝類，目的是爲了以統一的方式去處理帶有註解的類，無論這些類是如何加載的
	// 若是沒法理解，能夠把它當作一個黑盒，不會影響看spring源碼的主流程
	SourceClass sourceClass = asSourceClass(configClass);
	do {
    // 核心處理邏輯
		sourceClass = doProcessConfigurationClass(configClass, sourceClass);
	}
	while (sourceClass != null);
    // 將解析的配置類存儲起來，這樣回到parse()方法時，能取到值
	this.configurationClasses.put(configClass, configClass);
}
複製代碼
2.2.2 doProcessConfigurationClass()代碼

doProcessConfigurationClass()方法中，執行流程以下:

  • (1) 處理內部類，若是內部類也是一個配置類(判斷一個類是不是一個配置類，經過ConfigurationClassUtils.checkConfigurationClassCandidate()能夠判斷)。
  • (2) 處理屬性資源文件，加了@PropertySource註解。
  • (3) 首先解析出類上的@ComponentScan和@ComponentScans註解，而後根據配置的掃描包路徑，利用ASM技術(ASM技術是一種操做字節碼的技術，有興趣的朋友能夠去網上了解下)掃描出全部須要交給Spring管理的類，因爲掃描出的類中可能也被加了@ComponentScan和@ComponentScans註解，所以須要進行遞歸解析，直到全部加了這兩個註解的類被解析完成。
  • (4) 處理@Import註解。經過@Import註解，有三種方式能夠將一個Bean註冊到Spring容器中。
  • (5) 處理@ImportResource註解，解析配置文件。
  • (6) 處理加了@Bean註解的方法。
  • (7) 經過processInterfaces()處理接口的默認方法，從JDK8開始，接口中的方法能夠有本身的默認實現，所以，若是這個接口中的方法也加了@Bean註解，也須要被解析。(不多用)
  • (8) 解析父類，若是被解析的配置類繼承了某個類，那麼配置類的父類也會被進行解析doProcessConfigurationClass()(父類是JDK內置的類例外，即全類名以java開頭的)。

關於第(7)步，舉個例子解釋下。以下代碼示例，AppConfig類加了Configuration註解，是一個配置類，且實現了AppConfigInterface接口，這個接口中有一個默認的實現方法(JDK8開始，接口中的方法能夠有默認實現)，該方法上添加了@Bean註解。這個時候，通過第(7)步的解析，會想spring容器中添加一個InterfaceMethodBean類型的bean。

@Configuration
public class AppConfig implements AppConfigInterface{
}

public interface AppConfigInterface {
	@Bean
	default InterfaceMethodBean interfaceMethodBean() {
		return new InterfaceMethodBean();
	}
}
複製代碼

doProcessConfigurationClass()的源碼以下，源碼中加了中文註釋

protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass) throws IOException {

	// 一、首先處理內部類，處理內部類時，最終仍是調用doProcessConfigurationClass()方法
	processMemberClasses(configClass, sourceClass);
	// 二、處理屬性資源文件，加了@PropertySource註解
	for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
			sourceClass.getMetadata(), PropertySources.class,
			org.springframework.context.annotation.PropertySource.class)) {
		if (this.environment instanceof ConfigurableEnvironment) {
			processPropertySource(propertySource);
		}
	}
	// 三、處理@ComponentScan或者@ComponentScans註解
	// 3.1 先找出類上的@ComponentScan和@ComponentScans註解的全部屬性(例如basePackages等屬性值)
	Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
			sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class);
	if (!componentScans.isEmpty() &&
			!this.conditionEvaluator.shouldSkip(sourceClass.getMetadata(), ConfigurationPhase.REGISTER_BEAN)) {
		for (AnnotationAttributes componentScan : componentScans) {
			// 3.2 解析@ComponentScan和@ComponentScans配置的掃描的包所包含的類
			// 好比 basePackages = com.tiantang.study, 那麼在這一步會掃描出這個包及子包下的class，而後將其解析成BeanDefinition
			// (BeanDefinition能夠理解爲等價於BeanDefinitionHolder)
			Set<BeanDefinitionHolder> scannedBeanDefinitions =
					this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
			// 3.3 經過上一步掃描包com.tiantang.com下的類，有可能掃描出來的bean中可能也添加了ComponentScan或者ComponentScans註解.
			//因此這裏須要循環遍歷一次，進行遞歸(parse)，繼續解析，直到解析出的類上沒有ComponentScan和ComponentScans
			// (這時3.1這一步解析出componentScans爲空列表，不會進入到if語句，遞歸終止)
			for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
				BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
				if (bdCand == null) {
					bdCand = holder.getBeanDefinition();
				}
				// 一樣，這裏會調用ConfigurationClassUtils.checkConfigurationClassCandidate()方法來判斷類是不是一個配置類
				if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
					parse(bdCand.getBeanClassName(), holder.getBeanName());
				}
			}
		}
	}
	// 4.處理Import註解註冊的bean，這一步只會將import註冊的bean變爲ConfigurationClass,不會變成BeanDefinition
	// 而是在loadBeanDefinitions()方法中變成BeanDefinition，再放入到BeanDefinitionMap中
	// 關於Import註解,後面會單獨寫文章介紹
	processImports(configClass, sourceClass, getImports(sourceClass), true);

	// 5.處理@ImportResource註解引入的配置文件
	AnnotationAttributes importResource =
			AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
	if (importResource != null) {
		String[] resources = importResource.getStringArray("locations");
		Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
		for (String resource : resources) {
			String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
			configClass.addImportedResource(resolvedResource, readerClass);
		}
	}
	// 處理加了@Bean註解的方法
	Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
	for (MethodMetadata methodMetadata : beanMethods) {
		configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
	}
	// ... 省略部分代碼
	// No superclass -> processing is complete
	return null;
}
複製代碼
2.3 this.reader.loadBeanDefinitions()

該方法其實是將經過@Import、@Bean等註解方式註冊的類解析成BeanDefinition，而後註冊到BeanDefinitionMap中。

public void loadBeanDefinitions(Set<ConfigurationClass> configurationModel) {
	TrackedConditionEvaluator trackedConditionEvaluator = new TrackedConditionEvaluator();
	for (ConfigurationClass configClass : configurationModel) {
    // 循環調用loadBeanDefinitionsForConfigurationClass()
		loadBeanDefinitionsForConfigurationClass(configClass, trackedConditionEvaluator);
	}
}

private void loadBeanDefinitionsForConfigurationClass( ConfigurationClass configClass, TrackedConditionEvaluator trackedConditionEvaluator) {
	// 省略部分代碼 ... 

	// 若是一個bean是經過@Import(ImportSelector)的方式添加到容器中的，那麼此時configClass.isImported()返回的是true
	// 並且configClass的importedBy屬性裏面存儲的是ConfigurationClass就是將bean導入的類
	// 這一步的目的是
	if (configClass.isImported()) {
		registerBeanDefinitionForImportedConfigurationClass(configClass);
	}
	// 判斷當前的bean中是否含有@Bean註解的方法，若是有，須要把這些方法產生的bean放入到BeanDefinitionMap當中
	for (BeanMethod beanMethod : configClass.getBeanMethods()) {
		loadBeanDefinitionsForBeanMethod(beanMethod);
	}
	loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());
	// 若是bean上存在@Import註解，且import的是一個實現了ImportBeanDefinitionRegistrar接口,則執行ImportBeanDefinitionRegistrar的registerBeanDefinitions()方法
	loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
}
複製代碼

3. postProcessBeanFactory()方法

該方法是對BeanFactory進行處理，用來干預BeanFactory的建立過程。主要乾了兩件事，(1)對加了@Configuration註解的類進行CGLIB代理。(2)向Spring中添加一個後置處理器ImportAwareBeanPostProcessor。

public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
	int factoryId = System.identityHashCode(beanFactory);
	if (this.factoriesPostProcessed.contains(factoryId)) {
		throw new IllegalStateException(
				"postProcessBeanFactory already called on this post-processor against " + beanFactory);
	}
	this.factoriesPostProcessed.add(factoryId);
	// 下面的if語句不會進入，由於在執行BeanFactoryPostProcessor時，會先執行BeanDefinitionRegistryPostProcessor的postProcessorBeanDefinitionRegistry()方法
	// 而在執行postProcessorBeanDefinitionRegistry方法時，都會調用processConfigBeanDefinitions方法，這與postProcessorBeanFactory()方法的執行邏輯是同樣的
	// postProcessorBeanFactory()方法也會調用processConfigBeanDefinitions方法，爲了不重複執行，因此在執行方法以前會先生成一個id，將id放入到一個set當中，每次執行以前
	// 先判斷id是否存在，因此在此處，永遠不會進入到if語句中
	if (!this.registriesPostProcessed.contains(factoryId)) {
		// BeanDefinitionRegistryPostProcessor hook apparently not supported...
		// Simply call processConfigurationClasses lazily at this point then.
		// 該方法在這裏不會被執行到
		processConfigBeanDefinitions((BeanDefinitionRegistry) beanFactory);
	}
	// 對加了@Configuration註解的配置類進行Cglib代理
	enhanceConfigurationClasses(beanFactory);
	// 添加一個BeanPostProcessor後置處理器
	beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
}
複製代碼
3.1 CGLIB加強Configuration類
  • 利用enhanceConfigurationClasses(beanFactory)方法對Configuration類進行加強，採用CGLIB來建立動態代理
public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) {
	// 省去部分代碼...
	ConfigurationClassEnhancer enhancer = new ConfigurationClassEnhancer();
	for (Map.Entry<String, AbstractBeanDefinition> entry : configBeanDefs.entrySet()) {
		// 省去部分代碼...
        
        // 調用ConfigurationClassEnhancer.enhance()方法建立加強類
		Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);
		// 省去部分代碼...
	}
}
複製代碼
  • ConfigurationClassEnhancer.enhance()方法
public Class<?> enhance(Class<?> configClass, @Nullable ClassLoader classLoader) {
	// 省略部分代碼。。。。
    // 核心代碼爲 newEnHancer()
	Class<?> enhancedClass = createClass(newEnhancer(configClass, classLoader));
	// 省略部分代碼。。。。
	return enhancedClass;
}
複製代碼
  • ConfigurationClassEnhancer.newEnhancer()方法
private Enhancer newEnhancer(Class<?> configSuperClass, @Nullable ClassLoader classLoader) {
	Enhancer enhancer = new Enhancer();
    // CGLIB的動態代理基於繼承
	enhancer.setSuperclass(configSuperClass);
    // 爲新建立的代理對象設置一個父接口
	enhancer.setInterfaces(new Class<?>[] {EnhancedConfiguration.class});
	enhancer.setUseFactory(false);
	enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
	enhancer.setStrategy(new BeanFactoryAwareGeneratorStrategy(classLoader));
	// 添加了兩個MethodInterceptor。(BeanMethodInterceptor和BeanFactoryAwareMethodInterceptor)
	// 經過這兩個類的名稱，能夠猜出，前者是對加了@Bean註解的方法進行加強，後者是爲代理對象的beanFactory屬性進行加強
	// 被代理的對象，如何對方法進行加強呢？就是經過MethodInterceptor攔截器實現的
	// 相似於SpringMVC中的攔截器，每次執行請求時，都會對通過攔截器。
	// 一樣，加了MethodInterceptor，那麼在每次代理對象的方法時，都會先通過MethodInterceptor中的方法
	enhancer.setCallbackFilter(CALLBACK_FILTER);
	enhancer.setCallbackTypes(CALLBACK_FILTER.getCallbackTypes());
	return enhancer;
}
複製代碼
  • CGLIB建立動態代理是基於繼承來是實現的(JDK的動態代理是基於接口實現)，所以enhancer.setSupperclass(configSuperClass)這一行代碼，就是爲即將產生的代理對象設置父類，同時爲產生的代理對象實現EnhancedConfiguration.class接口，實現該接口的目的，是爲了該Configuration類在實例化、初始化過程當中，執行相關的BeanPostProcessor。
  • 例如在執行ImportAwareBeanPostProcessor後置處理器時，postProcessPropertyValues()方法，會對EnhancedConfiguration類進行屬性設置，實際就是爲EnhancedConfiguration實現類的beanfactory屬性賦值
3.2 添加ImportAwareBeanPostProcessor後置處理器
  • ConfigurationClassPostProcessor類的postProcessBeanFactory()方法在最後會向spring容器中添加一個Bean後置處理器：ImportAwareBeanPostProcessor，Bean後置處理器最終會在Bean實例化和初始化的過程當中執行，參與Bean的建立過程。在上面已經經過源碼分析了該後置處理器postProcessPropertyValues()方法，其做用是爲EnhanceConfiguration類的beanFactory屬性賦值。
  • ImportAwareBeanPostProcessor代碼
private static class ImportAwareBeanPostProcessor extends InstantiationAwareBeanPostProcessorAdapter {

	private final BeanFactory beanFactory;

	public ImportAwareBeanPostProcessor(BeanFactory beanFactory) {
		this.beanFactory = beanFactory;
	}

	@Override
	public PropertyValues postProcessPropertyValues( PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) {
            // 爲被CGLIB加強時實現了EnhancedConfiguration接口的代理類，設置beanFactory屬性
		if (bean instanceof EnhancedConfiguration) {
			((EnhancedConfiguration) bean).setBeanFactory(this.beanFactory);
		}
		return pvs;
	}

	@Override
	public Object postProcessBeforeInitialization(Object bean, String beanName) {
		if (bean instanceof ImportAware) {
			ImportRegistry ir = this.beanFactory.getBean(IMPORT_REGISTRY_BEAN_NAME, ImportRegistry.class);
			AnnotationMetadata importingClass = ir.getImportingClassFor(bean.getClass().getSuperclass().getName());
			if (importingClass != null) {
				((ImportAware) bean).setImportMetadata(importingClass);
			}
		}
		return bean;
	}
}
複製代碼

4. 總結

  • 本文主要分析了 ConfigurationClassPostProcessor 類的做用，因爲該類實現了 BeanFactoryPostProcessor 接口和 BeanDefinitionRegistryPostProcessor 接口，因此會重寫 postProcessBeanDefinitionRegistry() 方法和 postProcessBeanFactory() 方法。
  • 在postProcessBeanDefinitionRegistry()方法中解析了加了Configuration註解的類，同時解析出 @ComponentScan 和 @ComponentScans 掃描出的Bean，也會解析出加了 @Bean 註解的方法所註冊的Bean，以及經過 @Import 註解註冊的Bean和 @ImportResource 註解導入的配置文件中配置的Bean。在 postProcessBeanDefinitionRegistry() 方法中，經過源碼分析了兩個十分重要的方法:ConfigurationClassParser.parse()和this.reader.loadBeanDefinitions()
  • 在postProcessBeanFactory()方法中，會利用CGLIB對加了@Configuration註解的類建立動態代理，進行加強。最後還會向spring容器中添加一個Bean後置處理器：ImportAwareBeanPostProcessor

5. 本文的坑

事先說明，這些坑後面會單獨寫文章發佈到該微信公衆號中解釋，有興趣的朋友能夠先本身研究下。

  • (1) 一個配置類必須加@Configuration註解？不加就不能被Spring解析了嗎？例如以下代碼:
@ComponentScan("com.tiantang.study")
public class AppConfig {
}

public class MainApplication {

	public static void main(String[] args) {
		AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
	}

}
複製代碼
  • (2) 爲何加了@Configuration註解的類須要被CGLIB進行加強?
  • (3) 結合(2)，看下下面的代碼，應該打印幾回注入UserDao？1次仍是2次？去掉@Configuration呢?

下面的代碼中，AppConfig類加了Configuration註解，而後經過@Bean註解註冊了兩個Bean，最後在orderDao()方法中調用了userDao()方法。

@Configuration
public class AppConfig {

	@Bean
	public UserDao userDao(){
		// 會被打印幾回 ？？
		System.out.println("注入UserDao");
		return new UserDao();
	}

	@Bean
	public OrderDao orderDao(){
		// 在這裏調用userDao()方法
		userDao();
		return new OrderDao();
	}

}
// 啓動容器
public class MainApplication {

	public static void main(String[] args) {
		AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
	}

}
複製代碼

掃描下方二維碼或者微信搜索公衆號菜鳥飛呀飛，便可關注微信公衆號，閱讀更多Spring源碼分析文章

微信公衆號
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程