Spring執行流程圖如下：

Spring執行流程圖

這個流程圖會隨著我們的學習不斷的變得越來越詳細，也會越來越復雜，希望在這個過程中我們都能朝著精通Spring的目標不斷前進！

?

在上篇文章我們學習了Spring中的第一行代碼，我們已經知道了Spring中的第一行代碼其實就是創建了一個AnnotatedBeanDefinitionReader對象，這個對象的主要作用就是注冊bd（BeanDefinition）到容器中。并且在創建這個對象的過程中，Spring還為容器注冊了開天辟地的幾個bd，包括ConfigurationClassPostProcessor，AutowiredAnnotationBeanPostProcessor等等。

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

”

Spring中的第二行代碼

第二行代碼在上面的流程圖中已經標注的非常明白了，就是

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

只是簡單的創建了一個ClassPathBeanDefinitionScanner對象。**那么這個ClassPathBeanDefinitionScanner有什么作用呢？從名字上來看好像就是這個對象來完成Spring中的掃描的，真的是這樣嗎？**希望同學們能帶著這兩個問題往下看

ClassPathBeanDefinitionScanner源碼分析

這個類名直譯過來就是：類路徑下的BeanDefinition的掃描器，所以我們就直接關注其掃描相關的方法，就是其中的doScan方法。其代碼如下：

//?這個方法會完成對指定包名下的class文件的掃描 // basePackages：指定包名，是一個可變參數 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這個方法是實際完成掃描的方法，也是接下來我們要分析的方法Set<BeanDefinition>?candidates?=?findCandidateComponents(basePackage);for?(BeanDefinition?candidate?:?candidates)?{、//?上篇文章中我們已經分析過了，完成了@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.如果你對BeanDefinition有一定了解的話，你肯定會知道這個判斷一定會成立的，這意味著????//?所有掃描出來的bd都會執行postProcessBeanDefinition方法進行一些后置處理??????postProcessBeanDefinition((AbstractBeanDefinition)?candidate,?beanName);}???????????????????????????if?(candidate?instanceof?AnnotatedBeanDefinition)?{??//?3.?是不是一個AnnotatedBeanDefinition，如果是的話，還需要進行額外的處理?AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition)?candidate);}//?4.檢查容器中是否已經有這個bd了，如果有就不進行注冊了?????????????????????????????????if?(checkCandidate(beanName,?candidate))?{//?下面這段邏輯在上篇文章中都已經分析過了，這里就直接跳過了BeanDefinitionHolder?definitionHolder?=?new?BeanDefinitionHolder(candidate,?beanName);definitionHolder?=AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata,?definitionHolder,?this.registry);beanDefinitions.add(definitionHolder);registerBeanDefinition(definitionHolder,?this.registry);}}}return?beanDefinitions; }

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

通過findCandidateComponents方法完成掃描

判斷掃描出來的bd是否是一個AbstractBeanDefinition，如果是的話執行postProcessBeanDefinition方法

判斷掃描出來的bd是否是一個AnnotatedBeanDefinition，如果是的話執行processCommonDefinitionAnnotations方法

檢查容器中是否已經有這個bd了，如果有就不進行注冊了

接下來我們就一步步分析這個方法，搞明白ClassPathBeanDefinitionScanner到底能起到什么作用

1、通過findCandidateComponents方法完成掃描

findCandidateComponents方法源碼如下：

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

• addCandidateComponentsFromIndex

?

不用過多關注這個方法。正常情況下Spring都是采用掃描classpath下的class文件來完成掃描，但是雖然基于classpath掃描速度非?？?#xff0c;但通過在編譯時創建候選靜態列表，可以提高大型應用程序的啟動性能。在這種模式下，應用程序的所有模塊都必須使用這種機制，因為當 ApplicationContext檢測到這樣的索引時，它將自動使用它而不是掃描類路徑。要生成索引，只需向包含組件掃描指令目標組件的每個模塊添加附加依賴項即可：Maven：

org.springframeworkspring-context-indexer5.0.6.RELEASEtrue

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

這個依賴實在太大了，半天了拉不下來，我這里就不演示了

”

• scanCandidateComponents(basePackage)

正常情況下我們的應用都是通過這個方法完成掃描的，其代碼如下：

?private?Set<BeanDefinition>?scanCandidateComponents(String?basePackage)?{//?用來存儲返回的bd的集合Set<BeanDefinition>?candidates?=?new?LinkedHashSet<>();try?{//?拼接成這種形式：classpath*:com.dmz.springString?packageSearchPath?=?ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX?+resolveBasePackage(basePackage)?+?'/'?+?this.resourcePattern;//?獲取到所有的class文件封裝而成的Resource對象Resource[]?resources?=?getResourcePatternResolver().getResources(packageSearchPath);//?遍歷得到的所有class文件封裝而成的Resource對象for?(Resource?resource?:?resources)?{if?(traceEnabled)?{logger.trace("Scanning?"?+?resource);}if?(resource.isReadable())?{try?{//?通過Resource構建一個MetadataReader對象，這個MetadataReader對象包含了對應class文件的解析出來的class的元信息以及注解元信息MetadataReader?metadataReader?=?getMetadataReaderFactory().getMetadataReader(resource);//?并不是所有的class文件文件都要被解析成為bd,只有被添加了注解（@Component,@Controller等）才是Spring中的組件if?(isCandidateComponent(metadataReader))?{//?解析元信息（class元信息以及注解元信息）得到一個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官網閱讀（一）容器及實例化?一文中，我畫過這樣一張圖

從上圖中可以看出，java class + configuration metadata 最終會轉換為一個BenaDefinition，結合我們上面的代碼分析可以知道，java class + configuration metadata實際上就是一個MetadataReader對象，而轉換成一個BenaDefinition則是指通過這個MetadataReader對象創建一個ScannedGenericBeanDefinition。

2、執行postProcessBeanDefinition方法

protected?void?postProcessBeanDefinition(AbstractBeanDefinition?beanDefinition,?String?beanName)?{//?為bd中的屬性設置默認值beanDefinition.applyDefaults(this.beanDefinitionDefaults);//?注解模式下這個值必定為null,使用XML配置時，if?(this.autowireCandidatePatterns?!=?null)?{beanDefinition.setAutowireCandidate(PatternMatchUtils.simpleMatch(this.autowireCandidatePatterns,?beanName));} }//?設置默認值 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方法最主要的功能就是給掃描出來的bd設置默認值，進一步填充bd中的屬性

”

3、執行processCommonDefinitionAnnotations方法

?

這句代碼將進一步解析class上的注解信息，Spring在創建這個abd的信息時候就已經將當前的class放入其中了，所有這行代碼主要做的就是通過class對象獲取到上面的注解（包括@Lazy，@Primary，@DependsOn注解等等），然后將得到注解中對應的配置信息并放入到bd中的屬性中

”

4、注冊BeanDefinition

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

---

通過上面的分析，我們已經知道了ClassPathBeanDefinitionScanner的作用，毋庸置疑，Spring肯定是通過這個類來完成掃描的，但是問題是，Spring是通過第二步創建的這個對象來完成掃描的嗎？我們再來看看這個ClassPathBeanDefinitionScanner的創建過程：

//?第一步 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)?{//?注冊默認的掃描過濾規則(要被@Component注解修飾)registerDefaultFilters();}setEnvironment(environment);setResourceLoader(resourceLoader); }

在這個ClassPathBeanDefinitionScanner的創建過程中我們全程無法干涉，不能對這個ClassPathBeanDefinitionScanner進行任何配置。而我們在配置類上明明是可以對掃描的規則進行配置的，例如：

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

所以Spring中肯定不是使用在這里創建的這個ClassPathBeanDefinitionScanner對象。

實際上真正完成掃描的時機是在我們流程圖中的3-5-1步。完成掃描這個功能的類就是我們在上篇文章中所提到的ConfigurationClassPostProcessor。接下來我們就通過這個類，看看Spring到底是如何完成的掃描，這也是本文重點想要說明的問題

Spring是怎么解析配置類的？

1、解析時機分析

解析前Spring做了什么？

注冊配置類

在分析掃描時機之前我們先回顧下之前的代碼，整個程序的入口如下：

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

其中在this()空參構造中Spring實例化了兩個對象，一個是AnnotatedBeanDefinitionReader，在上篇文章中已經介紹過了，另外一個是ClassPathBeanDefinitionScanner，在前文中也進行了詳細的分析。

在完成這兩個對象的創建后，Spring緊接著就利用第一步中創建的AnnotatedBeanDefinitionReader去將配置類注冊到了容器中?？吹竭@里不知道大家有沒有一個疑問，既然Spring是直接通過這種方式來注冊配置類，為什么我們還非要在配置類上添加@Configuration注解呢？按照這個代碼的話，我不在配置類上添加任何注解，也能將配置類注冊到容器中，例如下面這樣：

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被注冊到了容器中} }

大家仔細想想我這個問題，不妨帶著這些疑問繼續往下看。

調用refresh方法

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

public?void?refresh()?throws?BeansException,?IllegalStateException?{synchronized?(this.startupShutdownMonitor)?{//?這個方法主要做了以下幾件事//?1.記錄容器的啟動時間，并將容器狀態更改為激活//?2.調用initPropertySources()方法，主要用于web環境下初始化封裝相關的web資源，比如將servletContext封裝成為ServletContextPropertySource//?3.校驗環境中必要的屬性是否存在//?4.提供了一個擴展點可以提前放入一些事件，當applicationEventMulticaster這個bean被注冊到容器中后就直接發布事件prepareRefresh();//?實際上獲取的就是一個DefaultListableBeanFactoryConfigurableListableBeanFactory?beanFactory?=?obtainFreshBeanFactory();//?為bean工廠設置一些屬性prepareBeanFactory(beanFactory);try?{//?提供給子類復寫的方法，允許子類在這一步對beanFactory做一些后置處理postProcessBeanFactory(beanFactory);//?執行已經注冊在容器中的bean工廠的后置處理器，在這里完成的掃描invokeBeanFactoryPostProcessors(beanFactory);//?后面的代碼跟掃描無關，我們在之后的文章再介紹}//?.....} } ?

大部分的代碼都寫了很詳細的注釋，對于其中兩個比較復雜的方法我們單獨分析

prepareBeanFactory

invokeBeanFactoryPostProcessors

”

prepareBeanFactory做了什么？

protected?void?prepareBeanFactory(ConfigurableListableBeanFactory?beanFactory)?{//?設置classLoader,一般就是appClassLoaderbeanFactory.setBeanClassLoader(getClassLoader());//?設置el表達式解析器beanFactory.setBeanExpressionResolver(new?StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));//?容器中添加一個屬性編輯器注冊表，關于屬性編輯在《Spring官網閱讀（十四）Spring中的BeanWrapper及類型轉換》有過詳細介紹，這里就不再贅述了beanFactory.addPropertyEditorRegistrar(new?ResourceEditorRegistrar(this,?getEnvironment()));//?添加了一個bean的后置處理器，用于執行xxxAware方法beanFactory.addBeanPostProcessor(new?ApplicationContextAwareProcessor(this));//?對以下類型的依賴，不進行依賴檢查，不進行依賴檢查也就不會進行自動注入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等一些對象直接注入到bean中呢？就是下面這段代碼的作用啦！//?Spring在進行屬性注入時會從resolvableDependencies的map中查找是否有對應類型的bean存在，如果有的話就直接注入，下面這段代碼就是將對應的bean放入到resolvableDependencies這個map中beanFactory.registerResolvableDependency(BeanFactory.class,?beanFactory);beanFactory.registerResolvableDependency(ResourceLoader.class,?this);beanFactory.registerResolvableDependency(ApplicationEventPublisher.class,?this);beanFactory.registerResolvableDependency(ApplicationContext.class,?this);//?添加一個后置處理器，用于處理ApplicationListenerbeanFactory.addBeanPostProcessor(new?ApplicationListenerDetector(this));//?是否配置了LTW,也就是在類加載時期進行織入，一般都不會配置if?(beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME))?{beanFactory.addBeanPostProcessor(new?LoadTimeWeaverAwareProcessor(beanFactory));//?加載時期織入會配置一個臨時的類加載器beanFactory.setTempClassLoader(new?ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));}//?配置一些默認的環境相關的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());} }

上面這段代碼整體來說還是非常簡單的，邏輯也很清晰，就是在為beanFactory做一些配置，我們需要注意的是跟后置處理器相關的內容，可以看到在這一步一共注冊了兩個后置處理器

• ApplicationContextAwareProcessor，用于執行xxxAware接口中的方法

• ApplicationListenerDetector，保證監聽器被添加到容器中

關于ApplicationListenerDetector請參考Spring官網閱讀（八）容器的擴展點（三）（BeanPostProcessor）

invokeBeanFactoryPostProcessors做了什么?

這個方法的執行流程在Spring官網閱讀（六）容器的擴展點（一）BeanFactoryPostProcessor?已經做過非常詳細的分析了，其執行流程如下

整的來說，它就是將容器中已經注冊的bean工廠的后置處理器按照一定的順序進行執行。

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

還記得我們在上篇文章中提到的ConfigurationClassPostProcessor嗎？在創建AnnotatedBeanDefinitionReader的過程中它對應的BeanDefinition就被注冊到容器中了。接下來我們就來分析ConfigurationClassPostProcessor這個類的源碼

ConfigurationClassPostProcessor源碼分析

它實現了BeanDefinitionRegistryPostProcessor，所以首先執行它的postProcessBeanDefinitionRegistry方法，其源碼如下

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

processConfigBeanDefinitions方法的代碼很長，我們拆分一段段分析，先看第一段

第一段

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

上面這段代碼有這么幾個問題：

當前容器中有哪些BeanDefinition

如果你看過上篇文章的話應該知道，在創建AnnotatedBeanDefinitionReader對象的時候Spring已經往容器中注冊了5個BeanDefinition，再加上注冊的配置類，那么此時容器中應該存在6個BeanDefinition，我們可以打個斷點驗證

不出所料，確實是6個

checkConfigurationClassCandidate

代碼如下：

?public?static?boolean?checkConfigurationClassCandidate(BeanDefinition?beanDef,?MetadataReaderFactory?metadataReaderFactory)?{String?className?=?beanDef.getBeanClassName();if?(className?==?null?||?beanDef.getFactoryMethodName()?!=?null)?{return?false;}//?下面這一段都是為了獲取一個AnnotationMetadata//?AnnotationMetadata包含了對應class上的注解元信息以及class元信息AnnotationMetadata?metadata;if?(beanDef?instanceof?AnnotatedBeanDefinition?&&className.equals(((AnnotatedBeanDefinition)?beanDef).getMetadata().getClassName()))?{//?已經解析過了，比如注冊的配置類就屬于這種，直接從bd中獲取metadata?=?((AnnotatedBeanDefinition)?beanDef).getMetadata();}else?if?(beanDef?instanceof?AbstractBeanDefinition?&&?((AbstractBeanDefinition)?beanDef).hasBeanClass())?{//?拿到字節碼重新解析獲取到一個AnnotationMetadataClass<?>?beanClass?=?((AbstractBeanDefinition)?beanDef).getBeanClass();metadata?=?new?StandardAnnotationMetadata(beanClass,?true);}else?{try?{//?class屬性都沒有，就根據className利用ASM字節碼技術獲取到這個AnnotationMetadataMetadataReader?metadataReader?=?metadataReaderFactory.getMetadataReader(className);metadata?=?metadataReader.getAnnotationMetadata();}catch?(IOException?ex)?{return?false;}}//?如果被@Configuration注解標注了，說明是一個FullConfigurationCandidateif?(isFullConfigurationCandidate(metadata))?{beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE,?CONFIGURATION_CLASS_FULL);}//?如果被這些注解標注了，@Component，@ComponentScan，@Import，@ImportResource//?或者方法上有@Bean注解，那么就是一個LiteConfigurationCandidate//?也就是說你想把這個類當配置類使用，但是沒有添加@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();}//?核心目的就是創建這個ConfigurationClassParser對象ConfigurationClassParser?parser?=?new?ConfigurationClassParser(this.metadataReaderFactory,?this.problemReporter,?this.environment,this.resourceLoader,?this.componentScanBeanNameGenerator,?registry);//?第三段 }

這段代碼核心目的就是為了創建一個ConfigurationClassParser,這個類主要用于后續的配置類的解析。

第三段

public?void?processConfigBeanDefinitions(BeanDefinitionRegistry?registry)?{//?第一段，第二段//?.....Set<BeanDefinitionHolder>?candidates?=?new?LinkedHashSet<>(configCandidates);Set<ConfigurationClass>?alreadyParsed?=?new?HashSet<>(configCandidates.size());do?{//?在第二段代碼中創建了一個ConfigurationClassParser，這里就是使用這個parser來解析配置類//?我們知道掃描就是通過@ComponentScan，@ComponentScans來完成的，那么不出意外必定是在這里完成的掃描parser.parse(candidates);//?校驗在解析過程是中是否發生錯誤，同時會校驗@Configuration注解的類中的@Bean方法能否被復寫（被final修飾或者訪問權限為private都不能被復寫），如果不能被復寫會拋出異常，因為cglib代理要通過復寫父類的方法來完成代理，后文會做詳細介紹parser.validate();//?已經解析過的配置類Set<ConfigurationClass>?configClasses?=?new?LinkedHashSet<>(parser.getConfigurationClasses());//?移除已經解析過的配置類，防止重復加載了配置類中的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());}//?將通過解析@Bean，@Import等注解得到相關信息解析成bd被注入到容器中this.reader.loadBeanDefinitions(configClasses);alreadyParsed.addAll(configClasses);candidates.clear();//?如果大于，說明容器中新增了一些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());//?注冊ImportRegistry到容器中//?當通過@Import注解導入一個全配置類A（被@Configuration注解修飾的類），A可以實現ImportAware接口//?通過這個Aware可以感知到是哪個類導入的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、解析源碼分析

在上面的源碼分析中，我們已經能夠確定了Spring是通過ConfigurationClassParser的parse方法來完成對配置類的解析的。Spring對類的取名可以說是很講究了，ConfigurationClassParser直譯過來就是配置類解析器。接著我們就來看看它的源碼

2.1、parse方法

public?void?parse(Set<BeanDefinitionHolder>?configCandidates)?{this.deferredImportSelectors?=?new?LinkedList<>();//?遍歷所有的配置類，一個個完成解析for?(BeanDefinitionHolder?holder?:?configCandidates)?{BeanDefinition?bd?=?holder.getBeanDefinition();try?{//?三個判斷最終都會進入到同一個方法---->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);}}//?對ImportSelector進行延遲處理processDeferredImportSelectors(); }

2.2、processConfigurationClass方法

?protected?void?processConfigurationClass(ConfigurationClass?configClass)?throws?IOException?{//?解析@Conditional注解，判斷是否需要解析if?(this.conditionEvaluator.shouldSkip(configClass.getMetadata(),?ConfigurationPhase.PARSE_CONFIGURATION))?{return;}//?判斷解析器是否已經解析過這個配置類了ConfigurationClass?existingClass?=?this.configurationClasses.get(configClass);//?不為null,說明已經解析過了if?(existingClass?!=?null)?{//?如果這個要被解析的配置類是被@Import注解導入的if?(configClass.isImported())?{//?并且解析過的配置類也是被導入的if?(existingClass.isImported())?{//?那么這個配置類的導入類集合中新增當前的配置類的導入類，（A通過@Import導入了B，那么A就是B的導入類，B被A導入）existingClass.mergeImportedBy(configClass);}//?Otherwise?ignore?new?imported?config?class;?existing?non-imported?class?overrides?it.//?如果已經解析過的配置類不是被導入的，那么直接忽略新增的這個被導入的配置類。也就是說如果一個配置類同時被@Import導入以及正常的//?添加到容器中，那么正常添加到容器中的配置類會覆蓋被導入的類return;}else?{//?Explicit?bean?definition?found,?probably?replacing?an?import.//?Let's?remove?the?old?one?and?go?with?the?new?one.//?就是說新要被解析的這個配置類不是被導入的，所以這種情況下，直接移除調原有的解析的配置類//?為什么不是remove(existingClass)呢？可以看看hashCode跟equals方法//?remove(existingClass)跟remove(configClass)是等價的this.configurationClasses.remove(configClass);this.knownSuperclasses.values().removeIf(configClass::equals);}}//?Recursively?process?the?configuration?class?and?its?superclass?hierarchy.//?下面這段代碼主要是遞歸的處理配置類及其父類//??將配置類封裝成一個SourceClass方便進行統一的處理SourceClass?sourceClass?=?asSourceClass(configClass);do?{//?doxxx方法，真正干活的方法，對配置類進行處理，返回值是當前這個類的父類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//?遞歸處理內部類processMemberClasses(configClass,?sourceClass);//?Process?any?@PropertySource?annotations//?處理@PropertySources跟@PropertySource注解，將對應的屬性資源添加容器中（實際上添加到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注解，真正進行掃描的地方就是這里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//?檢查掃描出來的bd是否是配置類，如果是配置類遞歸進行解析for?(BeanDefinitionHolder?holder?:?scannedBeanDefinitions)?{//?一般情況下getOriginatingBeanDefinition獲取到的都是null//?什么時候不為null呢？,參考：ScopedProxyUtils.createScopedProxy方法//?在創建一個代理的bd時不會為nullBeanDefinition?bdCand?=?holder.getBeanDefinition().getOriginatingBeanDefinition();if?(bdCand?==?null)?{bdCand?=?holder.getBeanDefinition();}//?判斷掃描出來的bd是否是一個配置類，如果是的話繼續遞歸處理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標注的方法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//?返回父類，進行遞歸處理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真正完成了對配置類的解析，一共做了下面幾件事

解析配置類中的內部類，看內部類中是否有配置類，如果有進行遞歸處理

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

處理@ComponentScan，@ComponentScans注解

處理@Import注解

處理@ImportResource注解

處理@Bean注解

處理接口中的default方法

返回父類，讓外部的循環繼續處理當前配置類的父類

我們逐一進行分析

2.4、處理配置類中的內部類

?

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

”

2.5、處理@PropertySource注解

?

代碼也非常簡單，根據注解中的信息加載對應的屬性文件然后添加到容器中

”

2.6、處理@ComponentScan注解

?

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

” ?public?Set<BeanDefinitionHolder>?parse(AnnotationAttributes?componentScan,?final?String?declaringClass)?{//?第一步就創建了一個ClassPathBeanDefinitionScanner對象//?在這里我們就知道了，Spring在進行掃描時沒有使用在最開始的時候創建的那個對象進行掃描ClassPathBeanDefinitionScanner?scanner?=?new?ClassPathBeanDefinitionScanner(this.registry,componentScan.getBoolean("useDefaultFilters"),?this.environment,?this.resourceLoader);//?解析成bd時采用的beanName的生成規則Class<??extends?BeanNameGenerator>?generatorClass?=?componentScan.getClass("nameGenerator");boolean?useInheritedGenerator?=?(BeanNameGenerator.class?==?generatorClass);scanner.setBeanNameGenerator(useInheritedGenerator???this.beanNameGenerator?:BeanUtils.instantiateClass(generatorClass));//?配置這個掃描規則下的ScopedProxyMode的默認值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));}//?配置掃描器的匹配規則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);}}//?配置默認是否進行懶加載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);}});//?在完成對掃描器的配置后，直接調用其doScan方法進行掃描return?scanner.doScan(StringUtils.toStringArray(basePackages));}

看到了吧，第一步就創建了一個ClassPathBeanDefinitionScanner,緊接著通過解析注解，對這個掃描器進行了各種配置，然后調用doScan方法完成了掃描。

2.7、處理@Import注解

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

2.8、處理@ImportResource注解

?

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

”

2.9、處理@Bean注解

?

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

”

2.10、處理接口中的default方法

?

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

”

到此為止，我們分析完了整個解析的過程?？梢园l現Spring將所有解析到的配置信息都存儲在了ConfigurationClass類中，但是到目前為止這些存儲的信息都沒有進行使用。那么Spring是在哪里使用的這些信息呢？回到我們的第三段代碼，其中有一行代碼如圖所示：

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

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

//?configurationModel:被解析完成了配置類集合，其中保存了@Bean注解解析信息，@Import注解解析信息等等 public?void?loadBeanDefinitions(Set<ConfigurationClass>?configurationModel)?{TrackedConditionEvaluator?trackedConditionEvaluator?=?new?TrackedConditionEvaluator();for?(ConfigurationClass?configClass?:?configurationModel)?{//?調用這個方法完成的加載loadBeanDefinitionsForConfigurationClass(configClass,?trackedConditionEvaluator);} } private?void?loadBeanDefinitionsForConfigurationClass(ConfigurationClass?configClass,?TrackedConditionEvaluator?trackedConditionEvaluator)?{//?判斷是否需要跳過，例如A導入了B，A不滿足加載的條件需要被跳過，那么B也應該被跳過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;}//?判斷配置類是否是被導入進來的，實際的代碼就是判斷解析出來的configclass中的importedBy集合是否為空//?那么這個importedBy集合是做什么的呢？//?例如A通過@Import導入了B，那么解析B得到得configclass中得importedBy集合就包含了A//?簡而言之，importedBy集合就是導入了這個類的其它類（可能同時被多個類導入）//?在前文中我們也分析過了，被多個類同時導入時會調用mergeImportedBy方法在集合中添加一個元素if?(configClass.isImported())?{registerBeanDefinitionForImportedConfigurationClass(configClass);}//?解析@Bean標注的Method得到對應的BeanDefinition并注冊到容器中for?(BeanMethod?beanMethod?:?configClass.getBeanMethods())?{loadBeanDefinitionsForBeanMethod(beanMethod);}//?解析導入的配置文件，并將從中得到的bd注冊到容器中loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());//?執行configClass中的所有ImportBeanDefinitionRegistrar的registerBeanDefinitions方法loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars()); }

這段代碼閱讀起來還是非常簡單的，這里我就跟大家一起看下BeanMethod的相關代碼，主要是為了讓大家對BeanDefinition的理解能夠更加深入，其源碼如下：

?private?void?loadBeanDefinitionsForBeanMethod(BeanMethod?beanMethod)?{ConfigurationClass?configClass?=?beanMethod.getConfigurationClass();MethodMetadata?metadata?=?beanMethod.getMetadata();String?methodName?=?metadata.getMethodName();//?根據@Conditional注解判斷是否需要跳過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");//?從這里可以看出，如果沒有配置beanName,默認會取方法名稱作為beanNameList<String>?names?=?new?ArrayList<>(Arrays.asList(bean.getStringArray("name")));String?beanName?=?(!names.isEmpty()???names.remove(0)?:?methodName);//?注冊別名for?(String?alias?:?names)?{this.registry.registerAlias(beanName,?alias);}//?isOverriddenByExistingDefinition這個方法判斷的是當前注冊的bd是否被原有的存在的bd所覆蓋了//?什么是覆蓋呢？后文中我們詳細分析if?(isOverriddenByExistingDefinition(beanMethod,?beanName))?{//?滿足下面這個if的話意味著@Bean創建的bean跟@Bean標注的方法所所在的配置類的名稱一樣了，這種情況下直接拋出異常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;}//?創建一個ConfigurationClassBeanDefinition，從這里可以看出通過@Bean創建的Bean所對應的bd全是ConfigurationClassBeanDefinitionConfigurationClassBeanDefinition?beanDef?=?new?ConfigurationClassBeanDefinition(configClass,?metadata);beanDef.setResource(configClass.getResource());beanDef.setSource(this.sourceExtractor.extractSource(metadata,?configClass.getResource()));//?@Bean是靜態的，那么只需要知道靜態方法所在類名以及方法名就能執行這個方法了if?(metadata.isStatic())?{//?static?@Bean?methodbeanDef.setBeanClassName(configClass.getMetadata().getClassName());beanDef.setFactoryMethodName(methodName);}else?{//?//?instance?@Bean?methodbeanDef.setFactoryBeanName(configClass.getBeanName());beanDef.setUniqueFactoryMethodName(methodName);}//?接下來的代碼就是設置一些bd的屬性，然后將bd注冊到容器中，相關的源碼在之前的文章中已經分析過了//?這里我就不在分析了，參考本文推薦閱讀文章的《讀源碼，我們可以從第一行讀起》//.....}

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

正因為如此，所有它們有一個很大的不同點在于BeanDefinition中BeanClasss屬性的設置。可以看到，對于@Bean形式創建的Bean其BeanDefinition中是沒有設置BeanClasss屬性的，但是額外設置了其它的屬性

• 靜態方法下，設置了BeanClassName以及FactoryMethodName屬性，其中的BeanClassName是靜態方法所在類的類名，FactoryMethodName是靜態方法的方法名

• 實例方法下，設置了FactoryBeanName以及FactoryMethodName屬性，其中FactoryBeanName是實例對應的Bean的名稱，而FactoryMethodName是實例中對應的方法名

之所以不用設置BeanClasss屬性是因為，通過指定的靜態方法或者指定的實例中的方法也能唯一確定一個Bean。

除此之外，注冊@Bean形式得到的BeanDefinition時，還進行了一個isOverriddenByExistingDefinition(beanMethod, beanName)方法的判斷，這個方法的主要作用是判斷當前要注冊的bean是否被之前已經存在的Bean覆蓋了。但是在直接通過AnnotatedBeanDefinitionReader#doRegisterBean方法注冊Bean時是沒有進行這個判斷的，如果存在就直接覆蓋了，而不會用之前的bd來覆蓋現在要注冊的bd。這是為什么呢？據筆者自己的理解，是因為Spring將Bean也是分成了三六九等的，通過@Bean方式得到的bd可以覆蓋掃描出來的普通bd(ScannedGenericBeanDefinition),但是不能覆蓋配置類，所以當已經存在的bd是一個ScannedGenericBeanDefinition時，那么直接進行覆蓋，但是當已經存在的bd是一個配置類時，就不能進行覆蓋了，要使用已經存在的bd來覆蓋本次要注冊的bd。

到此為止，我們就完成了Spring中的整個配置類解析、注冊的相關源碼分析，不過還沒完，我們還得解決一個問題，就是為什么要在配置類上添加@Configuration注解，在之前的源碼分析中我們知道，添加@Configuration注解的作用就是講配置類標志成了一個full configurationClass，這個的目的是什么呢？本來是打算一篇文章寫完的，不過實在是太長了，接近6w字，所以還是拆成了兩篇，預知后事如何，請看下文：配置類為什么要添加@Configuration注解呢？

總結

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

清晰的知道了執行的流程，我們再來回想下postProcessBeanDefinitionRegistry做了什么。碼字不易，對你有幫助的話記得點個贊，關注一波哦，萬分感謝！

總結

以上是生活随笔為你收集整理的Spring 是解析配置类过程详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。