Spring執(zhí)行流程圖如下：

Spring執(zhí)行流程圖

這個(gè)流程圖會(huì)隨著我們的學(xué)習(xí)不斷的變得越來(lái)越詳細(xì)，也會(huì)越來(lái)越復(fù)雜，希望在這個(gè)過(guò)程中我們都能朝著精通Spring的目標(biāo)不斷前進(jìn)！

?

在上篇文章我們學(xué)習(xí)了Spring中的第一行代碼，我們已經(jīng)知道了Spring中的第一行代碼其實(shí)就是創(chuàng)建了一個(gè)AnnotatedBeanDefinitionReader對(duì)象，這個(gè)對(duì)象的主要作用就是注冊(cè)bd（BeanDefinition）到容器中。并且在創(chuàng)建這個(gè)對(duì)象的過(guò)程中，Spring還為容器注冊(cè)了開(kāi)天辟地的幾個(gè)bd，包括ConfigurationClassPostProcessor，AutowiredAnnotationBeanPostProcessor等等。

那么在本文中，我們就一起來(lái)看看Spring中的第二行代碼又做了些什么？

”

Spring中的第二行代碼

第二行代碼在上面的流程圖中已經(jīng)標(biāo)注的非常明白了，就是

this.scanner?=?new?ClassPathBeanDefinitionScanner(this);

只是簡(jiǎn)單的創(chuàng)建了一個(gè)ClassPathBeanDefinitionScanner對(duì)象。**那么這個(gè)ClassPathBeanDefinitionScanner有什么作用呢？從名字上來(lái)看好像就是這個(gè)對(duì)象來(lái)完成Spring中的掃描的，真的是這樣嗎？**希望同學(xué)們能帶著這兩個(gè)問(wèn)題往下看

ClassPathBeanDefinitionScanner源碼分析

這個(gè)類名直譯過(guò)來(lái)就是：類路徑下的BeanDefinition的掃描器，所以我們就直接關(guān)注其掃描相關(guān)的方法，就是其中的doScan方法。其代碼如下：

//?這個(gè)方法會(huì)完成對(duì)指定包名下的class文件的掃描 // basePackages：指定包名，是一個(gè)可變參數(shù) protected?Set<BeanDefinitionHolder>?doScan(String...?basePackages)?{Assert.notEmpty(basePackages,?"At?least?one?base?package?must?be?specified");Set<BeanDefinitionHolder>?beanDefinitions?=?new?LinkedHashSet<>();for?(String?basePackage?:?basePackages)?{????//?1.findCandidateComponents這個(gè)方法是實(shí)際完成掃描的方法，也是接下來(lái)我們要分析的方法Set<BeanDefinition>?candidates?=?findCandidateComponents(basePackage);for?(BeanDefinition?candidate?:?candidates)?{、//?上篇文章中我們已經(jīng)分析過(guò)了，完成了@Scope注解的解析//?參考《徹底讀懂Spring（一）讀源碼，我們可以從第一行讀起》ScopeMetadata?scopeMetadata?=?this.scopeMetadataResolver.resolveScopeMetadata(candidate);candidate.setScope(scopeMetadata.getScopeName());String?beanName?=?this.beanNameGenerator.generateBeanName(candidate,?this.registry);if?(candidate?instanceof?AbstractBeanDefinition)?{//?2.如果你對(duì)BeanDefinition有一定了解的話，你肯定會(huì)知道這個(gè)判斷一定會(huì)成立的，這意味著????//?所有掃描出來(lái)的bd都會(huì)執(zhí)行postProcessBeanDefinition方法進(jìn)行一些后置處理??????postProcessBeanDefinition((AbstractBeanDefinition)?candidate,?beanName);}???????????????????????????if?(candidate?instanceof?AnnotatedBeanDefinition)?{??//?3.?是不是一個(gè)AnnotatedBeanDefinition，如果是的話，還需要進(jìn)行額外的處理?AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition)?candidate);}//?4.檢查容器中是否已經(jīng)有這個(gè)bd了，如果有就不進(jìn)行注冊(cè)了?????????????????????????????????if?(checkCandidate(beanName,?candidate))?{//?下面這段邏輯在上篇文章中都已經(jīng)分析過(guò)了，這里就直接跳過(guò)了BeanDefinitionHolder?definitionHolder?=?new?BeanDefinitionHolder(candidate,?beanName);definitionHolder?=AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata,?definitionHolder,?this.registry);beanDefinitions.add(definitionHolder);registerBeanDefinition(definitionHolder,?this.registry);}}}return?beanDefinitions; }

上面這段代碼主要做了四件事

通過(guò)findCandidateComponents方法完成掃描

判斷掃描出來(lái)的bd是否是一個(gè)AbstractBeanDefinition，如果是的話執(zhí)行postProcessBeanDefinition方法

判斷掃描出來(lái)的bd是否是一個(gè)AnnotatedBeanDefinition，如果是的話執(zhí)行processCommonDefinitionAnnotations方法

檢查容器中是否已經(jīng)有這個(gè)bd了，如果有就不進(jìn)行注冊(cè)了

接下來(lái)我們就一步步分析這個(gè)方法，搞明白ClassPathBeanDefinitionScanner到底能起到什么作用

1、通過(guò)findCandidateComponents方法完成掃描

findCandidateComponents方法源碼如下：

public?Set<BeanDefinition>?findCandidateComponents(String?basePackage)?{if?(this.componentsIndex?!=?null?&&?indexSupportsIncludeFilters())?{return?addCandidateComponentsFromIndex(this.componentsIndex,?basePackage);}else?{//?正常情況下都是進(jìn)入這個(gè)判斷，對(duì)classpath下的class文件進(jìn)行掃描return?scanCandidateComponents(basePackage);} }

• addCandidateComponentsFromIndex

?

不用過(guò)多關(guān)注這個(gè)方法。正常情況下Spring都是采用掃描classpath下的class文件來(lái)完成掃描，但是雖然基于classpath掃描速度非常快，但通過(guò)在編譯時(shí)創(chuàng)建候選靜態(tài)列表，可以提高大型應(yīng)用程序的啟動(dòng)性能。在這種模式下，應(yīng)用程序的所有模塊都必須使用這種機(jī)制，因?yàn)楫?dāng) ApplicationContext檢測(cè)到這樣的索引時(shí)，它將自動(dòng)使用它而不是掃描類路徑。要生成索引，只需向包含組件掃描指令目標(biāo)組件的每個(gè)模塊添加附加依賴項(xiàng)即可：Maven：

org.springframeworkspring-context-indexer5.0.6.RELEASEtrue

大家有興趣的話可以參考官網(wǎng)：https://docs.spring.io/spring/docs/5.1.14.BUILD-SNAPSHOT/spring-framework-reference/core.html#beans-scanning-index

這個(gè)依賴實(shí)在太大了，半天了拉不下來(lái)，我這里就不演示了

”

• scanCandidateComponents(basePackage)

正常情況下我們的應(yīng)用都是通過(guò)這個(gè)方法完成掃描的，其代碼如下：

?private?Set<BeanDefinition>?scanCandidateComponents(String?basePackage)?{//?用來(lái)存儲(chǔ)返回的bd的集合Set<BeanDefinition>?candidates?=?new?LinkedHashSet<>();try?{//?拼接成這種形式：classpath*:com.dmz.springString?packageSearchPath?=?ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX?+resolveBasePackage(basePackage)?+?'/'?+?this.resourcePattern;//?獲取到所有的class文件封裝而成的Resource對(duì)象Resource[]?resources?=?getResourcePatternResolver().getResources(packageSearchPath);//?遍歷得到的所有class文件封裝而成的Resource對(duì)象for?(Resource?resource?:?resources)?{if?(traceEnabled)?{logger.trace("Scanning?"?+?resource);}if?(resource.isReadable())?{try?{//?通過(guò)Resource構(gòu)建一個(gè)MetadataReader對(duì)象，這個(gè)MetadataReader對(duì)象包含了對(duì)應(yīng)class文件的解析出來(lái)的class的元信息以及注解元信息MetadataReader?metadataReader?=?getMetadataReaderFactory().getMetadataReader(resource);//?并不是所有的class文件文件都要被解析成為bd,只有被添加了注解（@Component,@Controller等）才是Spring中的組件if?(isCandidateComponent(metadataReader))?{//?解析元信息（class元信息以及注解元信息）得到一個(gè)ScannedGenericBeanDefinitionScannedGenericBeanDefinition?sbd?=?new?ScannedGenericBeanDefinition(metadataReader);sbd.setResource(resource);sbd.setSource(resource);if?(isCandidateComponent(sbd))?{if?(debugEnabled)?{logger.debug("Identified?candidate?component?class:?"?+?resource);}candidates.add(sbd);}//?省略多余的代碼return?candidates;}

在Spring官網(wǎng)閱讀（一）容器及實(shí)例化?一文中，我畫(huà)過(guò)這樣一張圖

從上圖中可以看出，java class + configuration metadata 最終會(huì)轉(zhuǎn)換為一個(gè)BenaDefinition，結(jié)合我們上面的代碼分析可以知道，java class + configuration metadata實(shí)際上就是一個(gè)MetadataReader對(duì)象，而轉(zhuǎn)換成一個(gè)BenaDefinition則是指通過(guò)這個(gè)MetadataReader對(duì)象創(chuàng)建一個(gè)ScannedGenericBeanDefinition。

2、執(zhí)行postProcessBeanDefinition方法

protected?void?postProcessBeanDefinition(AbstractBeanDefinition?beanDefinition,?String?beanName)?{//?為bd中的屬性設(shè)置默認(rèn)值beanDefinition.applyDefaults(this.beanDefinitionDefaults);//?注解模式下這個(gè)值必定為null,使用XML配置時(shí)，if?(this.autowireCandidatePatterns?!=?null)?{beanDefinition.setAutowireCandidate(PatternMatchUtils.simpleMatch(this.autowireCandidatePatterns,?beanName));} }//?設(shè)置默認(rèn)值 public?void?applyDefaults(BeanDefinitionDefaults?defaults)?{setLazyInit(defaults.isLazyInit());setAutowireMode(defaults.getAutowireMode());setDependencyCheck(defaults.getDependencyCheck());setInitMethodName(defaults.getInitMethodName());setEnforceInitMethod(false);setDestroyMethodName(defaults.getDestroyMethodName());setEnforceDestroyMethod(false); } ?

可以看出，postProcessBeanDefinition方法最主要的功能就是給掃描出來(lái)的bd設(shè)置默認(rèn)值，進(jìn)一步填充bd中的屬性

”

3、執(zhí)行processCommonDefinitionAnnotations方法

?

這句代碼將進(jìn)一步解析class上的注解信息，Spring在創(chuàng)建這個(gè)abd的信息時(shí)候就已經(jīng)將當(dāng)前的class放入其中了，所有這行代碼主要做的就是通過(guò)class對(duì)象獲取到上面的注解（包括@Lazy，@Primary，@DependsOn注解等等），然后將得到注解中對(duì)應(yīng)的配置信息并放入到bd中的屬性中

”

4、注冊(cè)BeanDefinition

跟讀源碼，我們可以從第一行讀起的注冊(cè)邏輯是一樣的

---

通過(guò)上面的分析，我們已經(jīng)知道了ClassPathBeanDefinitionScanner的作用，毋庸置疑，Spring肯定是通過(guò)這個(gè)類來(lái)完成掃描的，但是問(wèn)題是，Spring是通過(guò)第二步創(chuàng)建的這個(gè)對(duì)象來(lái)完成掃描的嗎？我們?cè)賮?lái)看看這個(gè)ClassPathBeanDefinitionScanner的創(chuàng)建過(guò)程：

//?第一步 public?ClassPathBeanDefinitionScanner(BeanDefinitionRegistry?registry)?{this(registry,?true); } //?第二步????????????????????????? public?ClassPathBeanDefinitionScanner(BeanDefinitionRegistry?registry,?boolean?useDefaultFilters)?{this(registry,?useDefaultFilters,?getOrCreateEnvironment(registry)); } //?第三步?? public?ClassPathBeanDefinitionScanner(BeanDefinitionRegistry?registry,?boolean?useDefaultFilters,Environment?environment)?{this(registry,?useDefaultFilters,?environment,(registry?instanceof?ResourceLoader???(ResourceLoader)?registry?:?null)); } //?第四步 public?ClassPathBeanDefinitionScanner(BeanDefinitionRegistry?registry,?boolean?useDefaultFilters,Environment?environment,?@Nullable?ResourceLoader?resourceLoader)?{Assert.notNull(registry,?"BeanDefinitionRegistry?must?not?be?null");this.registry?=?registry;if?(useDefaultFilters)?{//?注冊(cè)默認(rèn)的掃描過(guò)濾規(guī)則(要被@Component注解修飾)registerDefaultFilters();}setEnvironment(environment);setResourceLoader(resourceLoader); }

在這個(gè)ClassPathBeanDefinitionScanner的創(chuàng)建過(guò)程中我們?nèi)虩o(wú)法干涉，不能對(duì)這個(gè)ClassPathBeanDefinitionScanner進(jìn)行任何配置。而我們?cè)谂渲妙惿厦髅魇强梢詫?duì)掃描的規(guī)則進(jìn)行配置的，例如：

@ComponentScan(value?=?"com.spring.study.springfx.aop.service",?useDefaultFilters?=?true,excludeFilters?=?@ComponentScan.Filter(type?=?FilterType.ASSIGNABLE_TYPE,?classes?=?{IndexService.class}))

所以Spring中肯定不是使用在這里創(chuàng)建的這個(gè)ClassPathBeanDefinitionScanner對(duì)象。

實(shí)際上真正完成掃描的時(shí)機(jī)是在我們流程圖中的3-5-1步。完成掃描這個(gè)功能的類就是我們?cè)谏掀恼轮兴岬降腃onfigurationClassPostProcessor。接下來(lái)我們就通過(guò)這個(gè)類，看看Spring到底是如何完成的掃描，這也是本文重點(diǎn)想要說(shuō)明的問(wèn)題

Spring是怎么解析配置類的？

1、解析時(shí)機(jī)分析

解析前Spring做了什么？

注冊(cè)配置類

在分析掃描時(shí)機(jī)之前我們先回顧下之前的代碼，整個(gè)程序的入口如下：

public?AnnotationConfigApplicationContext(Class<?>...?annotatedClasses)?{this();register(annotatedClasses);refresh(); }

其中在this()空參構(gòu)造中Spring實(shí)例化了兩個(gè)對(duì)象，一個(gè)是AnnotatedBeanDefinitionReader，在上篇文章中已經(jīng)介紹過(guò)了，另外一個(gè)是ClassPathBeanDefinitionScanner，在前文中也進(jìn)行了詳細(xì)的分析。

在完成這兩個(gè)對(duì)象的創(chuàng)建后，Spring緊接著就利用第一步中創(chuàng)建的AnnotatedBeanDefinitionReader去將配置類注冊(cè)到了容器中。看到這里不知道大家有沒(méi)有一個(gè)疑問(wèn)，既然Spring是直接通過(guò)這種方式來(lái)注冊(cè)配置類，為什么我們還非要在配置類上添加@Configuration注解呢？按照這個(gè)代碼的話，我不在配置類上添加任何注解，也能將配置類注冊(cè)到容器中，例如下面這樣：

public?class?Config?{ }public?class?Main?{public?static?void?main(String[]?args)?throws?Exception?{AnnotationConfigApplicationContext?ac?=?new?AnnotationConfigApplicationContext(Config.class);System.out.println(ac.getBean("config"));//?程序輸出：com.spring.study.springfx.aop.Config@7b69c6ba//?意味著Config被注冊(cè)到了容器中} }

大家仔細(xì)想想我這個(gè)問(wèn)題，不妨帶著這些疑問(wèn)繼續(xù)往下看。

調(diào)用refresh方法

在將配置類注冊(cè)到容器中后，Spring緊接著又調(diào)用了refresh方法，其源碼如下：

public?void?refresh()?throws?BeansException,?IllegalStateException?{synchronized?(this.startupShutdownMonitor)?{//?這個(gè)方法主要做了以下幾件事//?1.記錄容器的啟動(dòng)時(shí)間，并將容器狀態(tài)更改為激活//?2.調(diào)用initPropertySources()方法，主要用于web環(huán)境下初始化封裝相關(guān)的web資源，比如將servletContext封裝成為ServletContextPropertySource//?3.校驗(yàn)環(huán)境中必要的屬性是否存在//?4.提供了一個(gè)擴(kuò)展點(diǎn)可以提前放入一些事件，當(dāng)applicationEventMulticaster這個(gè)bean被注冊(cè)到容器中后就直接發(fā)布事件prepareRefresh();//?實(shí)際上獲取的就是一個(gè)DefaultListableBeanFactoryConfigurableListableBeanFactory?beanFactory?=?obtainFreshBeanFactory();//?為bean工廠設(shè)置一些屬性prepareBeanFactory(beanFactory);try?{//?提供給子類復(fù)寫的方法，允許子類在這一步對(duì)beanFactory做一些后置處理postProcessBeanFactory(beanFactory);//?執(zhí)行已經(jīng)注冊(cè)在容器中的bean工廠的后置處理器，在這里完成的掃描invokeBeanFactoryPostProcessors(beanFactory);//?后面的代碼跟掃描無(wú)關(guān)，我們?cè)谥蟮奈恼略俳榻B}//?.....} } ?

大部分的代碼都寫了很詳細(xì)的注釋，對(duì)于其中兩個(gè)比較復(fù)雜的方法我們單獨(dú)分析

prepareBeanFactory

invokeBeanFactoryPostProcessors

”

prepareBeanFactory做了什么？

protected?void?prepareBeanFactory(ConfigurableListableBeanFactory?beanFactory)?{//?設(shè)置classLoader,一般就是appClassLoaderbeanFactory.setBeanClassLoader(getClassLoader());//?設(shè)置el表達(dá)式解析器beanFactory.setBeanExpressionResolver(new?StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));//?容器中添加一個(gè)屬性編輯器注冊(cè)表，關(guān)于屬性編輯在《Spring官網(wǎng)閱讀（十四）Spring中的BeanWrapper及類型轉(zhuǎn)換》有過(guò)詳細(xì)介紹，這里就不再贅述了beanFactory.addPropertyEditorRegistrar(new?ResourceEditorRegistrar(this,?getEnvironment()));//?添加了一個(gè)bean的后置處理器，用于執(zhí)行xxxAware方法beanFactory.addBeanPostProcessor(new?ApplicationContextAwareProcessor(this));//?對(duì)以下類型的依賴，不進(jìn)行依賴檢查，不進(jìn)行依賴檢查也就不會(huì)進(jìn)行自動(dòng)注入beanFactory.ignoreDependencyInterface(EnvironmentAware.class);beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);beanFactory.ignoreDependencyInterface(MessageSourceAware.class);beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);//?為什么我們能直接將ApplicationContext等一些對(duì)象直接注入到bean中呢？就是下面這段代碼的作用啦！//?Spring在進(jìn)行屬性注入時(shí)會(huì)從resolvableDependencies的map中查找是否有對(duì)應(yīng)類型的bean存在，如果有的話就直接注入，下面這段代碼就是將對(duì)應(yīng)的bean放入到resolvableDependencies這個(gè)map中beanFactory.registerResolvableDependency(BeanFactory.class,?beanFactory);beanFactory.registerResolvableDependency(ResourceLoader.class,?this);beanFactory.registerResolvableDependency(ApplicationEventPublisher.class,?this);beanFactory.registerResolvableDependency(ApplicationContext.class,?this);//?添加一個(gè)后置處理器，用于處理ApplicationListenerbeanFactory.addBeanPostProcessor(new?ApplicationListenerDetector(this));//?是否配置了LTW,也就是在類加載時(shí)期進(jìn)行織入，一般都不會(huì)配置if?(beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME))?{beanFactory.addBeanPostProcessor(new?LoadTimeWeaverAwareProcessor(beanFactory));//?加載時(shí)期織入會(huì)配置一個(gè)臨時(shí)的類加載器beanFactory.setTempClassLoader(new?ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));}//?配置一些默認(rèn)的環(huán)境相關(guān)的beanif?(!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME))?{beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME,?getEnvironment());}if?(!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME))?{beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME,?getEnvironment().getSystemProperties());}if?(!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME))?{beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME,?getEnvironment().getSystemEnvironment());} }

上面這段代碼整體來(lái)說(shuō)還是非常簡(jiǎn)單的，邏輯也很清晰，就是在為beanFactory做一些配置，我們需要注意的是跟后置處理器相關(guān)的內(nèi)容，可以看到在這一步一共注冊(cè)了兩個(gè)后置處理器

• ApplicationContextAwareProcessor，用于執(zhí)行xxxAware接口中的方法

• ApplicationListenerDetector，保證監(jiān)聽(tīng)器被添加到容器中

關(guān)于ApplicationListenerDetector請(qǐng)參考Spring官網(wǎng)閱讀（八）容器的擴(kuò)展點(diǎn)（三）（BeanPostProcessor）

invokeBeanFactoryPostProcessors做了什么?

這個(gè)方法的執(zhí)行流程在Spring官網(wǎng)閱讀（六）容器的擴(kuò)展點(diǎn)（一）BeanFactoryPostProcessor?已經(jīng)做過(guò)非常詳細(xì)的分析了，其執(zhí)行流程如下

整的來(lái)說(shuō)，它就是將容器中已經(jīng)注冊(cè)的bean工廠的后置處理器按照一定的順序進(jìn)行執(zhí)行。

那么到這一步為止，容器中已經(jīng)有哪些bean工廠的后置處理器呢？

還記得我們?cè)谏掀恼轮刑岬降腃onfigurationClassPostProcessor嗎？在創(chuàng)建AnnotatedBeanDefinitionReader的過(guò)程中它對(duì)應(yīng)的BeanDefinition就被注冊(cè)到容器中了。接下來(lái)我們就來(lái)分析ConfigurationClassPostProcessor這個(gè)類的源碼

ConfigurationClassPostProcessor源碼分析

它實(shí)現(xiàn)了BeanDefinitionRegistryPostProcessor，所以首先執(zhí)行它的postProcessBeanDefinitionRegistry方法，其源碼如下

public?void?postProcessBeanDefinitionRegistry(BeanDefinitionRegistry?registry)?{//?生成一個(gè)注冊(cè)表IDint?registryId?=?System.identityHashCode(registry);//.....//?表明這個(gè)工廠已經(jīng)經(jīng)過(guò)了后置處理器了this.registriesPostProcessed.add(registryId);//?從名字來(lái)看這個(gè)方法是再對(duì)配置類的bd進(jìn)行處理processConfigBeanDefinitions(registry); }

processConfigBeanDefinitions方法的代碼很長(zhǎng)，我們拆分一段段分析，先看第一段

第一段

public?void?processConfigBeanDefinitions(BeanDefinitionRegistry?registry)?{//?========第一段代碼========List<BeanDefinitionHolder>?configCandidates?=?new?ArrayList<>();//?大家可以思考一個(gè)問(wèn)題，當(dāng)前容器中有哪些BeanDefinition呢？//?這個(gè)地方應(yīng)該能獲取到哪些名字？String[]?candidateNames?=?registry.getBeanDefinitionNames();for?(String?beanName?:?candidateNames)?{//?根據(jù)名稱獲取到對(duì)應(yīng)BeanDefinitionBeanDefinition?beanDef?=?registry.getBeanDefinition(beanName);//?省略日志打印//?檢查是否是配置類，在這里會(huì)將對(duì)應(yīng)的bd標(biāo)記為FullConfigurationClass或者LiteConfigurationClasselse?if?(ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef,?this.metadataReaderFactory))?{//?是配置類的話，將這個(gè)bd添加到configCandidates中configCandidates.add(new?BeanDefinitionHolder(beanDef,?beanName));}}//?沒(méi)有配置類，直接返回if?(configCandidates.isEmpty())?{return;}//?根據(jù)@Order注解進(jìn)行排序configCandidates.sort((bd1,?bd2)?->?{int?i1?=?ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());int?i2?=?ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());return?Integer.compare(i1,?i2);});//?.....

上面這段代碼有這么幾個(gè)問(wèn)題：

當(dāng)前容器中有哪些BeanDefinition

如果你看過(guò)上篇文章的話應(yīng)該知道，在創(chuàng)建AnnotatedBeanDefinitionReader對(duì)象的時(shí)候Spring已經(jīng)往容器中注冊(cè)了5個(gè)BeanDefinition，再加上注冊(cè)的配置類，那么此時(shí)容器中應(yīng)該存在6個(gè)BeanDefinition，我們可以打個(gè)斷點(diǎn)驗(yàn)證

不出所料，確實(shí)是6個(gè)

checkConfigurationClassCandidate

代碼如下：

?public?static?boolean?checkConfigurationClassCandidate(BeanDefinition?beanDef,?MetadataReaderFactory?metadataReaderFactory)?{String?className?=?beanDef.getBeanClassName();if?(className?==?null?||?beanDef.getFactoryMethodName()?!=?null)?{return?false;}//?下面這一段都是為了獲取一個(gè)AnnotationMetadata//?AnnotationMetadata包含了對(duì)應(yīng)class上的注解元信息以及class元信息AnnotationMetadata?metadata;if?(beanDef?instanceof?AnnotatedBeanDefinition?&&className.equals(((AnnotatedBeanDefinition)?beanDef).getMetadata().getClassName()))?{//?已經(jīng)解析過(guò)了，比如注冊(cè)的配置類就屬于這種，直接從bd中獲取metadata?=?((AnnotatedBeanDefinition)?beanDef).getMetadata();}else?if?(beanDef?instanceof?AbstractBeanDefinition?&&?((AbstractBeanDefinition)?beanDef).hasBeanClass())?{//?拿到字節(jié)碼重新解析獲取到一個(gè)AnnotationMetadataClass<?>?beanClass?=?((AbstractBeanDefinition)?beanDef).getBeanClass();metadata?=?new?StandardAnnotationMetadata(beanClass,?true);}else?{try?{//?class屬性都沒(méi)有，就根據(jù)className利用ASM字節(jié)碼技術(shù)獲取到這個(gè)AnnotationMetadataMetadataReader?metadataReader?=?metadataReaderFactory.getMetadataReader(className);metadata?=?metadataReader.getAnnotationMetadata();}catch?(IOException?ex)?{return?false;}}//?如果被@Configuration注解標(biāo)注了，說(shuō)明是一個(gè)FullConfigurationCandidateif?(isFullConfigurationCandidate(metadata))?{beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE,?CONFIGURATION_CLASS_FULL);}//?如果被這些注解標(biāo)注了，@Component，@ComponentScan，@Import，@ImportResource//?或者方法上有@Bean注解，那么就是一個(gè)LiteConfigurationCandidate//?也就是說(shuō)你想把這個(gè)類當(dāng)配置類使用，但是沒(méi)有添加@Configuration注解else?if?(isLiteConfigurationCandidate(metadata))?{beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE,?CONFIGURATION_CLASS_LITE);}else?{return?false;}//?解析@Order注解，用于排序Integer?order?=?getOrder(metadata);if?(order?!=?null)?{beanDef.setAttribute(ORDER_ATTRIBUTE,?order);}return?true;}

第二段

public?void?processConfigBeanDefinitions(BeanDefinitionRegistry?registry)?{//?第一段//?.....SingletonBeanRegistry?sbr?=?null;if?(registry?instanceof?SingletonBeanRegistry)?{sbr?=?(SingletonBeanRegistry)?registry;//?beanName的生成策略，不重要if?(!this.localBeanNameGeneratorSet)?{BeanNameGenerator?generator?=?(BeanNameGenerator)?sbr.getSingleton(CONFIGURATION_BEAN_NAME_GENERATOR);if?(generator?!=?null)?{this.componentScanBeanNameGenerator?=?generator;this.importBeanNameGenerator?=?generator;}}}if?(this.environment?==?null)?{this.environment?=?new?StandardEnvironment();}//?核心目的就是創(chuàng)建這個(gè)ConfigurationClassParser對(duì)象ConfigurationClassParser?parser?=?new?ConfigurationClassParser(this.metadataReaderFactory,?this.problemReporter,?this.environment,this.resourceLoader,?this.componentScanBeanNameGenerator,?registry);//?第三段 }

這段代碼核心目的就是為了創(chuàng)建一個(gè)ConfigurationClassParser,這個(gè)類主要用于后續(xù)的配置類的解析。

第三段

public?void?processConfigBeanDefinitions(BeanDefinitionRegistry?registry)?{//?第一段，第二段//?.....Set<BeanDefinitionHolder>?candidates?=?new?LinkedHashSet<>(configCandidates);Set<ConfigurationClass>?alreadyParsed?=?new?HashSet<>(configCandidates.size());do?{//?在第二段代碼中創(chuàng)建了一個(gè)ConfigurationClassParser，這里就是使用這個(gè)parser來(lái)解析配置類//?我們知道掃描就是通過(guò)@ComponentScan，@ComponentScans來(lái)完成的，那么不出意外必定是在這里完成的掃描parser.parse(candidates);//?校驗(yàn)在解析過(guò)程是中是否發(fā)生錯(cuò)誤，同時(shí)會(huì)校驗(yàn)@Configuration注解的類中的@Bean方法能否被復(fù)寫（被final修飾或者訪問(wèn)權(quán)限為private都不能被復(fù)寫），如果不能被復(fù)寫會(huì)拋出異常，因?yàn)閏glib代理要通過(guò)復(fù)寫父類的方法來(lái)完成代理，后文會(huì)做詳細(xì)介紹parser.validate();//?已經(jīng)解析過(guò)的配置類Set<ConfigurationClass>?configClasses?=?new?LinkedHashSet<>(parser.getConfigurationClasses());//?移除已經(jīng)解析過(guò)的配置類，防止重復(fù)加載了配置類中的bdconfigClasses.removeAll(alreadyParsed);//?Read?the?model?and?create?bean?definitions?based?on?its?contentif?(this.reader?==?null)?{this.reader?=?new?ConfigurationClassBeanDefinitionReader(registry,?this.sourceExtractor,?this.resourceLoader,?this.environment,this.importBeanNameGenerator,?parser.getImportRegistry());}//?將通過(guò)解析@Bean，@Import等注解得到相關(guān)信息解析成bd被注入到容器中this.reader.loadBeanDefinitions(configClasses);alreadyParsed.addAll(configClasses);candidates.clear();//?如果大于，說(shuō)明容器中新增了一些bd,那么需要重新判斷新增的bd是否是配置類，如果是配置類，需要再次解析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());}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());//?注冊(cè)ImportRegistry到容器中//?當(dāng)通過(guò)@Import注解導(dǎo)入一個(gè)全配置類A（被@Configuration注解修飾的類），A可以實(shí)現(xiàn)ImportAware接口//?通過(guò)這個(gè)Aware可以感知到是哪個(gè)類導(dǎo)入的Aif?(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、解析源碼分析

在上面的源碼分析中，我們已經(jīng)能夠確定了Spring是通過(guò)ConfigurationClassParser的parse方法來(lái)完成對(duì)配置類的解析的。Spring對(duì)類的取名可以說(shuō)是很講究了，ConfigurationClassParser直譯過(guò)來(lái)就是配置類解析器。接著我們就來(lái)看看它的源碼

2.1、parse方法

public?void?parse(Set<BeanDefinitionHolder>?configCandidates)?{this.deferredImportSelectors?=?new?LinkedList<>();//?遍歷所有的配置類，一個(gè)個(gè)完成解析for?(BeanDefinitionHolder?holder?:?configCandidates)?{BeanDefinition?bd?=?holder.getBeanDefinition();try?{//?三個(gè)判斷最終都會(huì)進(jìn)入到同一個(gè)方法---->processConfigurationClass方法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());}}catch?(BeanDefinitionStoreException?ex)?{throw?ex;}catch?(Throwable?ex)?{throw?new?BeanDefinitionStoreException("Failed?to?parse?configuration?class?["?+?bd.getBeanClassName()?+?"]",?ex);}}//?對(duì)ImportSelector進(jìn)行延遲處理processDeferredImportSelectors(); }

2.2、processConfigurationClass方法

?protected?void?processConfigurationClass(ConfigurationClass?configClass)?throws?IOException?{//?解析@Conditional注解，判斷是否需要解析if?(this.conditionEvaluator.shouldSkip(configClass.getMetadata(),?ConfigurationPhase.PARSE_CONFIGURATION))?{return;}//?判斷解析器是否已經(jīng)解析過(guò)這個(gè)配置類了ConfigurationClass?existingClass?=?this.configurationClasses.get(configClass);//?不為null,說(shuō)明已經(jīng)解析過(guò)了if?(existingClass?!=?null)?{//?如果這個(gè)要被解析的配置類是被@Import注解導(dǎo)入的if?(configClass.isImported())?{//?并且解析過(guò)的配置類也是被導(dǎo)入的if?(existingClass.isImported())?{//?那么這個(gè)配置類的導(dǎo)入類集合中新增當(dāng)前的配置類的導(dǎo)入類，（A通過(guò)@Import導(dǎo)入了B，那么A就是B的導(dǎo)入類，B被A導(dǎo)入）existingClass.mergeImportedBy(configClass);}//?Otherwise?ignore?new?imported?config?class;?existing?non-imported?class?overrides?it.//?如果已經(jīng)解析過(guò)的配置類不是被導(dǎo)入的，那么直接忽略新增的這個(gè)被導(dǎo)入的配置類。也就是說(shuō)如果一個(gè)配置類同時(shí)被@Import導(dǎo)入以及正常的//?添加到容器中，那么正常添加到容器中的配置類會(huì)覆蓋被導(dǎo)入的類return;}else?{//?Explicit?bean?definition?found,?probably?replacing?an?import.//?Let's?remove?the?old?one?and?go?with?the?new?one.//?就是說(shuō)新要被解析的這個(gè)配置類不是被導(dǎo)入的，所以這種情況下，直接移除調(diào)原有的解析的配置類//?為什么不是remove(existingClass)呢？可以看看hashCode跟equals方法//?remove(existingClass)跟remove(configClass)是等價(jià)的this.configurationClasses.remove(configClass);this.knownSuperclasses.values().removeIf(configClass::equals);}}//?Recursively?process?the?configuration?class?and?its?superclass?hierarchy.//?下面這段代碼主要是遞歸的處理配置類及其父類//??將配置類封裝成一個(gè)SourceClass方便進(jìn)行統(tǒng)一的處理SourceClass?sourceClass?=?asSourceClass(configClass);do?{//?doxxx方法，真正干活的方法，對(duì)配置類進(jìn)行處理，返回值是當(dāng)前這個(gè)類的父類sourceClass?=?doProcessConfigurationClass(configClass,?sourceClass);}while?(sourceClass?!=?null);this.configurationClasses.put(configClass,?configClass);}

2.3、doProcessConfigurationClass方法

protected?final?SourceClass?doProcessConfigurationClass(ConfigurationClass?configClass,?SourceClass?sourceClass)throws?IOException?{//?Recursively?process?any?member?(nested)?classes?first//?遞歸處理內(nèi)部類processMemberClasses(configClass,?sourceClass);//?Process?any?@PropertySource?annotations//?處理@PropertySources跟@PropertySource注解，將對(duì)應(yīng)的屬性資源添加容器中（實(shí)際上添加到environment中）for?(AnnotationAttributes?propertySource?:?AnnotationConfigUtils.attributesForRepeatable(sourceClass.getMetadata(),?PropertySources.class,org.springframework.context.annotation.PropertySource.class))?{if?(this.environment?instanceof?ConfigurableEnvironment)?{processPropertySource(propertySource);}else?{logger.warn("Ignoring?@PropertySource?annotation?on?["?+?sourceClass.getMetadata().getClassName()?+"].?Reason:?Environment?must?implement?ConfigurableEnvironment");}}//?Process?any?@ComponentScan?annotations、//?處理@ComponentScan，@ComponentScans注解，真正進(jìn)行掃描的地方就是這里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)?{//?The?config?class?is?annotated?with?@ComponentScan?->?perform?the?scan?immediately//?核心代碼，在這里完成的掃描Set<BeanDefinitionHolder>?scannedBeanDefinitions?=this.componentScanParser.parse(componentScan,?sourceClass.getMetadata().getClassName());//?Check?the?set?of?scanned?definitions?for?any?further?config?classes?and?parse?recursively?if?needed//?檢查掃描出來(lái)的bd是否是配置類，如果是配置類遞歸進(jìn)行解析for?(BeanDefinitionHolder?holder?:?scannedBeanDefinitions)?{//?一般情況下getOriginatingBeanDefinition獲取到的都是null//?什么時(shí)候不為null呢？,參考：ScopedProxyUtils.createScopedProxy方法//?在創(chuàng)建一個(gè)代理的bd時(shí)不會(huì)為nullBeanDefinition?bdCand?=?holder.getBeanDefinition().getOriginatingBeanDefinition();if?(bdCand?==?null)?{bdCand?=?holder.getBeanDefinition();}//?判斷掃描出來(lái)的bd是否是一個(gè)配置類，如果是的話繼續(xù)遞歸處理if?(ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand,?this.metadataReaderFactory))?{parse(bdCand.getBeanClassName(),?holder.getBeanName());}}}}//?Process?any?@Import?annotations//?處理@Import注解processImports(configClass,?sourceClass,?getImports(sourceClass),?true);//?Process?any?@ImportResource?annotations//?處理@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);}}//?Process?individual?@Bean?methods//?處理@Bean注解//?獲取到被@Bean標(biāo)注的方法Set<MethodMetadata>?beanMethods?=?retrieveBeanMethodMetadata(sourceClass);for?(MethodMetadata?methodMetadata?:?beanMethods)?{//?添加到configClass中configClass.addBeanMethod(new?BeanMethod(methodMetadata,?configClass));}//?Process?default?methods?on?interfaces//?處理接口中的default方法processInterfaces(configClass,?sourceClass);//?Process?superclass,?if?any//?返回父類，進(jìn)行遞歸處理if?(sourceClass.getMetadata().hasSuperClass())?{String?superclass?=?sourceClass.getMetadata().getSuperClassName();if?(superclass?!=?null?&&?!superclass.startsWith("java")?&&!this.knownSuperclasses.containsKey(superclass))?{this.knownSuperclasses.put(superclass,?configClass);//?Superclass?found,?return?its?annotation?metadata?and?recursereturn?sourceClass.getSuperClass();}}//?No?superclass?->?processing?is?completereturn?null; }

可以看到，在doProcessConfigurationClass真正完成了對(duì)配置類的解析，一共做了下面幾件事

解析配置類中的內(nèi)部類，看內(nèi)部類中是否有配置類，如果有進(jìn)行遞歸處理

處理配置類上的@PropertySources跟@PropertySource注解

處理@ComponentScan，@ComponentScans注解

處理@Import注解

處理@ImportResource注解

處理@Bean注解

處理接口中的default方法

返回父類，讓外部的循環(huán)繼續(xù)處理當(dāng)前配置類的父類

我們逐一進(jìn)行分析

2.4、處理配置類中的內(nèi)部類

?

這段代碼非常簡(jiǎn)單，限于篇幅原因我這里就不再專門分析了，就是獲取到當(dāng)前配置類中的所有內(nèi)部類，然后遍歷所有的內(nèi)部類，判斷是否是一個(gè)配置類，如果是配置類的話就遞歸進(jìn)行解析

”

2.5、處理@PropertySource注解

?

代碼也非常簡(jiǎn)單，根據(jù)注解中的信息加載對(duì)應(yīng)的屬性文件然后添加到容器中

”

2.6、處理@ComponentScan注解

?

這個(gè)段我們就需要看一看了，Spring在這里完成的掃描，我們直接查看其核心方法，org.springframework.context.annotation.ComponentScanAnnotationParser#parse

” ?public?Set<BeanDefinitionHolder>?parse(AnnotationAttributes?componentScan,?final?String?declaringClass)?{//?第一步就創(chuàng)建了一個(gè)ClassPathBeanDefinitionScanner對(duì)象//?在這里我們就知道了，Spring在進(jìn)行掃描時(shí)沒(méi)有使用在最開(kāi)始的時(shí)候創(chuàng)建的那個(gè)對(duì)象進(jìn)行掃描ClassPathBeanDefinitionScanner?scanner?=?new?ClassPathBeanDefinitionScanner(this.registry,componentScan.getBoolean("useDefaultFilters"),?this.environment,?this.resourceLoader);//?解析成bd時(shí)采用的beanName的生成規(guī)則Class<??extends?BeanNameGenerator>?generatorClass?=?componentScan.getClass("nameGenerator");boolean?useInheritedGenerator?=?(BeanNameGenerator.class?==?generatorClass);scanner.setBeanNameGenerator(useInheritedGenerator???this.beanNameGenerator?:BeanUtils.instantiateClass(generatorClass));//?配置這個(gè)掃描規(guī)則下的ScopedProxyMode的默認(rèn)值ScopedProxyMode?scopedProxyMode?=?componentScan.getEnum("scopedProxy");if?(scopedProxyMode?!=?ScopedProxyMode.DEFAULT)?{scanner.setScopedProxyMode(scopedProxyMode);}else?{Class<??extends?ScopeMetadataResolver>?resolverClass?=?componentScan.getClass("scopeResolver");scanner.setScopeMetadataResolver(BeanUtils.instantiateClass(resolverClass));}//?配置掃描器的匹配規(guī)則scanner.setResourcePattern(componentScan.getString("resourcePattern"));//?配置掃描器需要掃描的組件for?(AnnotationAttributes?filter?:?componentScan.getAnnotationArray("includeFilters"))?{for?(TypeFilter?typeFilter?:?typeFiltersFor(filter))?{scanner.addIncludeFilter(typeFilter);}}//?配置掃描器不需要掃描的組件for?(AnnotationAttributes?filter?:?componentScan.getAnnotationArray("excludeFilters"))?{for?(TypeFilter?typeFilter?:?typeFiltersFor(filter))?{scanner.addExcludeFilter(typeFilter);}}//?配置默認(rèn)是否進(jìn)行懶加載boolean?lazyInit?=?componentScan.getBoolean("lazyInit");if?(lazyInit)?{scanner.getBeanDefinitionDefaults().setLazyInit(true);}//?配置掃描器掃描的包名Set<String>?basePackages?=?new?LinkedHashSet<>();String[]?basePackagesArray?=?componentScan.getStringArray("basePackages");for?(String?pkg?:?basePackagesArray)?{String[]?tokenized?=?StringUtils.tokenizeToStringArray(this.environment.resolvePlaceholders(pkg),ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);Collections.addAll(basePackages,?tokenized);}for?(Class<?>?clazz?:?componentScan.getClassArray("basePackageClasses"))?{basePackages.add(ClassUtils.getPackageName(clazz));}if?(basePackages.isEmpty())?{basePackages.add(ClassUtils.getPackageName(declaringClass));}//?排除自身scanner.addExcludeFilter(new?AbstractTypeHierarchyTraversingFilter(false,?false)?{@Overrideprotected?boolean?matchClassName(String?className)?{return?declaringClass.equals(className);}});//?在完成對(duì)掃描器的配置后，直接調(diào)用其doScan方法進(jìn)行掃描return?scanner.doScan(StringUtils.toStringArray(basePackages));}

看到了吧，第一步就創(chuàng)建了一個(gè)ClassPathBeanDefinitionScanner,緊接著通過(guò)解析注解，對(duì)這個(gè)掃描器進(jìn)行了各種配置，然后調(diào)用doScan方法完成了掃描。

2.7、處理@Import注解

?private?void?processImports(ConfigurationClass?configClass,?SourceClass?currentSourceClass,Collection<SourceClass>?importCandidates,?boolean?checkForCircularImports)?{//?沒(méi)有要導(dǎo)入的類，直接返回if?(importCandidates.isEmpty())?{return;}// checkForCircularImports：Spring中寫死的為true,需要檢查循環(huán)導(dǎo)入// isChainedImportOnStack方法：檢查導(dǎo)入棧中是否存在了這個(gè)configClass，如果存在了說(shuō)明//?出現(xiàn)了A?import?B,B?import?A的情況，直接拋出異常if?(checkForCircularImports?&&?isChainedImportOnStack(configClass))?{this.problemReporter.error(new?CircularImportProblem(configClass,?this.importStack));}else?{//?沒(méi)有出現(xiàn)循環(huán)導(dǎo)入，先將當(dāng)前的這個(gè)配置類加入到導(dǎo)入棧中this.importStack.push(configClass);try?{//?遍歷所有要導(dǎo)入的類for?(SourceClass?candidate?:?importCandidates)?{//?如果要導(dǎo)入的類是一個(gè)ImportSelectorif?(candidate.isAssignable(ImportSelector.class))?{//?Candidate?class?is?an?ImportSelector?->?delegate?to?it?to?determine?imports//?反射創(chuàng)建這個(gè)ImportSelectorClass<?>?candidateClass?=?candidate.loadClass();ImportSelector?selector?=?BeanUtils.instantiateClass(candidateClass,?ImportSelector.class);//?執(zhí)行xxxAware方法ParserStrategyUtils.invokeAwareMethods(selector,?this.environment,?this.resourceLoader,?this.registry);//?如果是一個(gè)DeferredImportSelector，添加到deferredImportSelectors集合中去//?在所有的配置類完成解析后再去處理deferredImportSelectors集合中的ImportSelectorif?(this.deferredImportSelectors?!=?null?&&?selector?instanceof?DeferredImportSelector)?{this.deferredImportSelectors.add(new?DeferredImportSelectorHolder(configClass,?(DeferredImportSelector)?selector));}else?{//?不是一個(gè)DeferredImportSelector，那么通過(guò)這個(gè)ImportSelector獲取到要導(dǎo)入的類名String[]?importClassNames?=?selector.selectImports(currentSourceClass.getMetadata());//?將其轉(zhuǎn)換成SourceClassCollection<SourceClass>?importSourceClasses?=?asSourceClasses(importClassNames);//?遞歸處理要導(dǎo)入的類，一般情況下這個(gè)時(shí)候進(jìn)入的就是另外兩個(gè)判斷了processImports(configClass,?currentSourceClass,?importSourceClasses,?false);}}else?if?(candidate.isAssignable(ImportBeanDefinitionRegistrar.class))?{//?Candidate?class?is?an?ImportBeanDefinitionRegistrar?->//?delegate?to?it?to?register?additional?bean?definitions//?如果是一個(gè)ImportBeanDefinitionRegistrar//?先通過(guò)反射創(chuàng)建這個(gè)ImportBeanDefinitionRegistrarClass<?>?candidateClass?=?candidate.loadClass();ImportBeanDefinitionRegistrar?registrar?=BeanUtils.instantiateClass(candidateClass,?ImportBeanDefinitionRegistrar.class);//?再執(zhí)行xxxAware方法ParserStrategyUtils.invokeAwareMethods(registrar,?this.environment,?this.resourceLoader,?this.registry);//?最后將其添加到configClass的importBeanDefinitionRegistrars集合中//?之后會(huì)統(tǒng)一調(diào)用其ImportBeanDefinitionRegistrar的registerBeanDefinitions方法，將對(duì)應(yīng)的bd注冊(cè)到容器中configClass.addImportBeanDefinitionRegistrar(registrar,?currentSourceClass.getMetadata());}else?{//?Candidate?class?not?an?ImportSelector?or?ImportBeanDefinitionRegistrar?->//?process?it?as?an?@Configuration?class//?既不是一個(gè)ImportSelector也不是一個(gè)ImportBeanDefinitionRegistrar，直接導(dǎo)入一個(gè)普通類//?并將這個(gè)類作為配置類進(jìn)行遞歸處理this.importStack.registerImport(currentSourceClass.getMetadata(),?candidate.getMetadata().getClassName());processConfigurationClass(candidate.asConfigClass(configClass));}}}catch?(BeanDefinitionStoreException?ex)?{throw?ex;}catch?(Throwable?ex)?{throw?new?BeanDefinitionStoreException("Failed?to?process?import?candidates?for?configuration?class?["?+configClass.getMetadata().getClassName()?+?"]",?ex);}finally?{//?在循環(huán)前我們將其加入了導(dǎo)入棧中，循環(huán)完成后將其彈出，主要是為了處理循環(huán)導(dǎo)入this.importStack.pop();}}}

2.8、處理@ImportResource注解

?

代碼也很簡(jiǎn)單，在指定的位置加載資源，然后添加到configClass中。一般情況下，我們通過(guò)@ImportResource注解導(dǎo)入的就是一個(gè)XML配置文件。將這個(gè)Resource添加到configClass后，Spring會(huì)在后文中解析這個(gè)XML配置文件然后將其中的bd注冊(cè)到容器中，可以參考o(jì)rg.springframework.context.annotation.ConfigurationClassBeanDefinitionReader#loadBeanDefinitions方法

”

2.9、處理@Bean注解

?

將配置類中所有的被@Bean標(biāo)注的方法添加到configClass的BeanMethod集合中

”

2.10、處理接口中的default方法

?

代碼也很簡(jiǎn)單，Java8中接口能定義default方法，這里就是處理接口中的default方法，看其是否有@Bean標(biāo)注的方法

”

到此為止，我們分析完了整個(gè)解析的過(guò)程。可以發(fā)現(xiàn)Spring將所有解析到的配置信息都存儲(chǔ)在了ConfigurationClass類中，但是到目前為止這些存儲(chǔ)的信息都沒(méi)有進(jìn)行使用。那么Spring是在哪里使用的這些信息呢？回到我們的第三段代碼，其中有一行代碼如圖所示：

也就是在這里Spring完成了對(duì)解析好的配置類的信息處理。

2.11、加載解析完成的配置信息

//?configurationModel:被解析完成了配置類集合，其中保存了@Bean注解解析信息，@Import注解解析信息等等 public?void?loadBeanDefinitions(Set<ConfigurationClass>?configurationModel)?{TrackedConditionEvaluator?trackedConditionEvaluator?=?new?TrackedConditionEvaluator();for?(ConfigurationClass?configClass?:?configurationModel)?{//?調(diào)用這個(gè)方法完成的加載loadBeanDefinitionsForConfigurationClass(configClass,?trackedConditionEvaluator);} } private?void?loadBeanDefinitionsForConfigurationClass(ConfigurationClass?configClass,?TrackedConditionEvaluator?trackedConditionEvaluator)?{//?判斷是否需要跳過(guò)，例如A導(dǎo)入了B，A不滿足加載的條件需要被跳過(guò)，那么B也應(yīng)該被跳過(guò)if?(trackedConditionEvaluator.shouldSkip(configClass))?{String?beanName?=?configClass.getBeanName();if?(StringUtils.hasLength(beanName)?&&?this.registry.containsBeanDefinition(beanName))?{this.registry.removeBeanDefinition(beanName);}this.importRegistry.removeImportingClass(configClass.getMetadata().getClassName());return;}//?判斷配置類是否是被導(dǎo)入進(jìn)來(lái)的，實(shí)際的代碼就是判斷解析出來(lái)的configclass中的importedBy集合是否為空//?那么這個(gè)importedBy集合是做什么的呢？//?例如A通過(guò)@Import導(dǎo)入了B，那么解析B得到得configclass中得importedBy集合就包含了A//?簡(jiǎn)而言之，importedBy集合就是導(dǎo)入了這個(gè)類的其它類（可能同時(shí)被多個(gè)類導(dǎo)入）//?在前文中我們也分析過(guò)了，被多個(gè)類同時(shí)導(dǎo)入時(shí)會(huì)調(diào)用mergeImportedBy方法在集合中添加一個(gè)元素if?(configClass.isImported())?{registerBeanDefinitionForImportedConfigurationClass(configClass);}//?解析@Bean標(biāo)注的Method得到對(duì)應(yīng)的BeanDefinition并注冊(cè)到容器中for?(BeanMethod?beanMethod?:?configClass.getBeanMethods())?{loadBeanDefinitionsForBeanMethod(beanMethod);}//?解析導(dǎo)入的配置文件，并將從中得到的bd注冊(cè)到容器中l(wèi)oadBeanDefinitionsFromImportedResources(configClass.getImportedResources());//?執(zhí)行configClass中的所有ImportBeanDefinitionRegistrar的registerBeanDefinitions方法loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars()); }

這段代碼閱讀起來(lái)還是非常簡(jiǎn)單的，這里我就跟大家一起看下BeanMethod的相關(guān)代碼，主要是為了讓大家對(duì)BeanDefinition的理解能夠更加深入，其源碼如下：

?private?void?loadBeanDefinitionsForBeanMethod(BeanMethod?beanMethod)?{ConfigurationClass?configClass?=?beanMethod.getConfigurationClass();MethodMetadata?metadata?=?beanMethod.getMetadata();String?methodName?=?metadata.getMethodName();//?根據(jù)@Conditional注解判斷是否需要跳過(guò)if?(this.conditionEvaluator.shouldSkip(metadata,?ConfigurationPhase.REGISTER_BEAN))?{configClass.skippedBeanMethods.add(methodName);return;}if?(configClass.skippedBeanMethods.contains(methodName))?{return;}//?獲取@Bean注解中的屬性AnnotationAttributes?bean?=?AnnotationConfigUtils.attributesFor(metadata,?Bean.class);Assert.state(bean?!=?null,?"No?@Bean?annotation?attributes");//?從這里可以看出，如果沒(méi)有配置beanName,默認(rèn)會(huì)取方法名稱作為beanNameList<String>?names?=?new?ArrayList<>(Arrays.asList(bean.getStringArray("name")));String?beanName?=?(!names.isEmpty()???names.remove(0)?:?methodName);//?注冊(cè)別名for?(String?alias?:?names)?{this.registry.registerAlias(beanName,?alias);}//?isOverriddenByExistingDefinition這個(gè)方法判斷的是當(dāng)前注冊(cè)的bd是否被原有的存在的bd所覆蓋了//?什么是覆蓋呢？后文中我們?cè)敿?xì)分析if?(isOverriddenByExistingDefinition(beanMethod,?beanName))?{//?滿足下面這個(gè)if的話意味著@Bean創(chuàng)建的bean跟@Bean標(biāo)注的方法所所在的配置類的名稱一樣了，這種情況下直接拋出異常if?(beanName.equals(beanMethod.getConfigurationClass().getBeanName()))?{throw?new?BeanDefinitionStoreException(beanMethod.getConfigurationClass().getResource().getDescription(),beanName,?"Bean?name?derived?from?@Bean?method?'"?+?beanMethod.getMetadata().getMethodName()?+"'?clashes?with?bean?name?for?containing?configuration?class;?please?make?those?names?unique!");}return;}//?創(chuàng)建一個(gè)ConfigurationClassBeanDefinition，從這里可以看出通過(guò)@Bean創(chuàng)建的Bean所對(duì)應(yīng)的bd全是ConfigurationClassBeanDefinitionConfigurationClassBeanDefinition?beanDef?=?new?ConfigurationClassBeanDefinition(configClass,?metadata);beanDef.setResource(configClass.getResource());beanDef.setSource(this.sourceExtractor.extractSource(metadata,?configClass.getResource()));//?@Bean是靜態(tài)的，那么只需要知道靜態(tài)方法所在類名以及方法名就能執(zhí)行這個(gè)方法了if?(metadata.isStatic())?{//?static?@Bean?methodbeanDef.setBeanClassName(configClass.getMetadata().getClassName());beanDef.setFactoryMethodName(methodName);}else?{//?//?instance?@Bean?methodbeanDef.setFactoryBeanName(configClass.getBeanName());beanDef.setUniqueFactoryMethodName(methodName);}//?接下來(lái)的代碼就是設(shè)置一些bd的屬性，然后將bd注冊(cè)到容器中，相關(guān)的源碼在之前的文章中已經(jīng)分析過(guò)了//?這里我就不在分析了，參考本文推薦閱讀文章的《讀源碼，我們可以從第一行讀起》//.....}

上面這個(gè)方法的主要目的就是將@Bean標(biāo)注的方法解析成BeandDefinition然后注冊(cè)到容器中。關(guān)于這個(gè)方法我們可以對(duì)比下之前分析過(guò)的org.springframework.context.annotation.AnnotatedBeanDefinitionReader#doRegisterBean方法。對(duì)比我們可以發(fā)現(xiàn)，這兩個(gè)方法最大的不同在于一個(gè)是基于Class對(duì)象的，而另一個(gè)則是基于Method對(duì)象的。

正因?yàn)槿绱?#xff0c;所有它們有一個(gè)很大的不同點(diǎn)在于BeanDefinition中BeanClasss屬性的設(shè)置。可以看到，對(duì)于@Bean形式創(chuàng)建的Bean其BeanDefinition中是沒(méi)有設(shè)置BeanClasss屬性的，但是額外設(shè)置了其它的屬性

• 靜態(tài)方法下，設(shè)置了BeanClassName以及FactoryMethodName屬性，其中的BeanClassName是靜態(tài)方法所在類的類名，FactoryMethodName是靜態(tài)方法的方法名

• 實(shí)例方法下，設(shè)置了FactoryBeanName以及FactoryMethodName屬性，其中FactoryBeanName是實(shí)例對(duì)應(yīng)的Bean的名稱，而FactoryMethodName是實(shí)例中對(duì)應(yīng)的方法名

之所以不用設(shè)置BeanClasss屬性是因?yàn)?#xff0c;通過(guò)指定的靜態(tài)方法或者指定的實(shí)例中的方法也能唯一確定一個(gè)Bean。

除此之外，注冊(cè)@Bean形式得到的BeanDefinition時(shí)，還進(jìn)行了一個(gè)isOverriddenByExistingDefinition(beanMethod, beanName)方法的判斷，這個(gè)方法的主要作用是判斷當(dāng)前要注冊(cè)的bean是否被之前已經(jīng)存在的Bean覆蓋了。但是在直接通過(guò)AnnotatedBeanDefinitionReader#doRegisterBean方法注冊(cè)Bean時(shí)是沒(méi)有進(jìn)行這個(gè)判斷的，如果存在就直接覆蓋了，而不會(huì)用之前的bd來(lái)覆蓋現(xiàn)在要注冊(cè)的bd。這是為什么呢？據(jù)筆者自己的理解，是因?yàn)镾pring將Bean也是分成了三六九等的，通過(guò)@Bean方式得到的bd可以覆蓋掃描出來(lái)的普通bd(ScannedGenericBeanDefinition),但是不能覆蓋配置類，所以當(dāng)已經(jīng)存在的bd是一個(gè)ScannedGenericBeanDefinition時(shí)，那么直接進(jìn)行覆蓋，但是當(dāng)已經(jīng)存在的bd是一個(gè)配置類時(shí)，就不能進(jìn)行覆蓋了，要使用已經(jīng)存在的bd來(lái)覆蓋本次要注冊(cè)的bd。

到此為止，我們就完成了Spring中的整個(gè)配置類解析、注冊(cè)的相關(guān)源碼分析，不過(guò)還沒(méi)完，我們還得解決一個(gè)問(wèn)題，就是為什么要在配置類上添加@Configuration注解，在之前的源碼分析中我們知道，添加@Configuration注解的作用就是講配置類標(biāo)志成了一個(gè)full configurationClass，這個(gè)的目的是什么呢？本來(lái)是打算一篇文章寫完的，不過(guò)實(shí)在是太長(zhǎng)了，接近6w字，所以還是拆成了兩篇，預(yù)知后事如何，請(qǐng)看下文：配置類為什么要添加@Configuration注解呢？

總結(jié)

我們結(jié)合上篇文章讀源碼，我們可以從第一行讀起整理下目前Spring的執(zhí)行流程

清晰的知道了執(zhí)行的流程，我們?cè)賮?lái)回想下postProcessBeanDefinitionRegistry做了什么。碼字不易，對(duì)你有幫助的話記得點(diǎn)個(gè)贊，關(guān)注一波哦，萬(wàn)分感謝！

總結(jié)

以上是生活随笔為你收集整理的你知道Spring是怎么解析配置类的吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。