你知道Spring是怎麼解析配置類的嗎？
徹底讀懂Spring（二）你知道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掃描速度非常快，但通過在編譯時創建候選靜態列表，可以提高大型應用程式的啟動性能。在這種模式下，應用程式的所有模組都必須使用這種機制，因為當 ApplicationContext檢測到這樣的索引時，它將自動使用它而不是掃描類路徑。
要生成索引，只需向包含組件掃描指令目標組件的每個模組添加附加依賴項即可：
Maven：
org.springframework
spring-context-indexer
5.0.6.RELEASE true
大家有興趣的話可以參考官網：//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.spring
String 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元資訊以及註解元資訊）得到一個ScannedGenericBeanDefinition
ScannedGenericBeanDefinition 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
跟徹底讀懂Spring（一）讀源碼，我們可以從第一行讀起的註冊邏輯是一樣的
通過上面的分析，我們已經知道了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();
// 實際上獲取的就是一個DefaultListableBeanFactory
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 為bean工廠設置一些屬性
prepareBeanFactory(beanFactory);
try {
// 提供給子類複寫的方法，允許子類在這一步對beanFactory做一些後置處理
postProcessBeanFactory(beanFactory);
// 執行已經註冊在容器中的bean工廠的後置處理器，在這裡完成的掃描
invokeBeanFactoryPostProcessors(beanFactory);
// 後面的程式碼跟掃描無關，我們在之後的文章再介紹
}
// .....
}
}
大部分的程式碼都寫了很詳細的注釋，對於其中兩個比較複雜的方法我們單獨分析
- prepareBeanFactory
- invokeBeanFactoryPostProcessors
prepareBeanFactory做了什麼？
protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
// 設置classLoader,一般就是appClassLoader
beanFactory.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));
// 自動注入模型下，如果bean中存在以下類型的依賴，不進行注入
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);
// 添加一個後置處理器，用於處理ApplicationListener
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));
// 是否配置了LTW,也就是在類載入時期進行織入，一般都不會配置
if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
// 載入時期織入會配置一個臨時的類載入器
beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
}
// 配置一些默認的環境相關的bean
if (!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) {
// 生成一個註冊表ID
int 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) {
// 根據名稱獲取到對應BeanDefinition
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
// 省略日誌列印
// 檢查是否是配置類，在這裡會將對應的bd標記為FullConfigurationClass或者LiteConfigurationClass
else 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()) {
// 拿到位元組碼重新解析獲取到一個AnnotationMetadata
Class<?> beanClass = ((AbstractBeanDefinition) beanDef).getBeanClass();
metadata = new StandardAnnotationMetadata(beanClass, true);
}
else {
try {
// class屬性都沒有，就根據className利用ASM位元組碼技術獲取到這個AnnotationMetadata
MetadataReader metadataReader = metadataReaderFactory.getMetadataReader(className);
metadata = metadataReader.getAnnotationMetadata();
}
catch (IOException ex) {
return false;
}
}
// 如果被@Configuration註解標註了，說明是一個FullConfigurationCandidate
if (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());
// 移除已經解析過的配置類，防止重複載入了配置類中的bd
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());
}
// 將通過解析@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可以感知到是哪個類導入的A
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、解析源碼分析
在上面的源碼分析中，我們已經能夠確定了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時不會為null
BeanDefinition 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 recurse
return sourceClass.getSuperClass();
}
}
// No superclass -> processing is complete
return 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) {
@Override
protected 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) {
// 如果要導入的類是一個ImportSelector
if (candidate.isAssignable(ImportSelector.class)) {
// Candidate class is an ImportSelector -> delegate to it to determine imports
// 反射創建這個ImportSelector
Class<?> candidateClass = candidate.loadClass();
ImportSelector selector = BeanUtils.instantiateClass(candidateClass, ImportSelector.class);
// 執行xxxAware方法
ParserStrategyUtils.invokeAwareMethods(
selector, this.environment, this.resourceLoader, this.registry);
// 如果是一個DeferredImportSelector，添加到deferredImportSelectors集合中去
// 在所有的配置類完成解析後再去處理deferredImportSelectors集合中的ImportSelector
if (this.deferredImportSelectors != null && selector instanceof DeferredImportSelector) {
this.deferredImportSelectors.add(
new DeferredImportSelectorHolder(configClass, (DeferredImportSelector) selector));
}
else {
// 不是一個DeferredImportSelector，那麼通過這個ImportSelector獲取到要導入的類名
String[] importClassNames = selector.selectImports(currentSourceClass.getMetadata());
// 將其轉換成SourceClass
Collection<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
// 先通過反射創建這個ImportBeanDefinitionRegistrar
Class<?> 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標註的方法
到此為止，我們分析完了整個解析的過程。可以發現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,默認會取方法名稱作為beanName
List<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全是ConfigurationClassBeanDefinition
ConfigurationClassBeanDefinition beanDef = new ConfigurationClassBeanDefinition(configClass, metadata);
beanDef.setResource(configClass.getResource());
beanDef.setSource(this.sourceExtractor.extractSource(metadata, configClass.getResource()));
// @Bean是靜態的，那麼只需要知道靜態方法所在類名以及方法名就能執行這個方法了
if (metadata.isStatic()) {
// static @Bean method
beanDef.setBeanClassName(configClass.getMetadata().getClassName());
beanDef.setFactoryMethodName(methodName);
}
else {
//
// instance @Bean method
beanDef.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（一）讀源碼，我們可以從第一行讀起整理下目前Spring的執行流程
原圖地址： 原圖
清晰的知道了執行的流程，我們再來回想下postProcessBeanDefinitionRegistry做了什麼。
碼字不易，對你有幫助的話記得點個贊，關注一波哦，萬分感謝！
