來源：轉(zhuǎn)載 發(fā)布時間：2020-05-12 11:13:47 閱讀量：1439
文章目錄
Spring中的第二行代碼
ClassPathBeanDefinitionScanner源碼分析
1、通過findCandidateComponents方法完成掃描
2、執(zhí)行postProcessBeanDefinition方法
3、執(zhí)行processCommonDefinitionAnnotations方法
4、注冊BeanDefinition
Spring是怎么解析配置類的？
1、解析時機分析
解析前Spring做了什么？
注冊配置類
調(diào)用refresh方法
prepareBeanFactory做了什么？
invokeBeanFactoryPostProcessors做了什么?
ConfigurationClassPostProcessor源碼分析
第一段
第二段
第三段
2、解析源碼分析
2.1、parse方法
2.2、processConfigurationClass方法
2.3、doProcessConfigurationClass方法
2.4、處理配置類中的內(nèi)部類
2.5、處理@PropertySource注解
2.6、處理@ComponentScan注解
2.7、處理@Import注解
2.8、處理@ImportResource注解
2.9、處理@Bean注解
2.10、處理接口中的default方法
2.11、加載解析完成的配置信息
總結(jié)
推薦閱讀：
Spring官網(wǎng)閱讀系列
徹底讀懂Spring（一）讀源碼，我們可以從第一行讀起
Spring執(zhí)行流程圖如下：
如果圖片顯示不清楚可以訪問如下鏈接查看高清大圖：
Spring執(zhí)行流程圖
這個流程圖會隨著我們的學(xué)習(xí)不斷的變得越來越詳細，也會越來越復(fù)雜，希望在這個過程中我們都能朝著精通Spring的目標(biāo)不斷前進！
在上篇文章我們學(xué)習(xí)了Spring中的第一行代碼，我們已經(jīng)知道了Spring中的第一行代碼其實就是創(chuàng)建了一個AnnotatedBeanDefinitionReader對象，這個對象的主要作用就是注冊bd（BeanDefinition）到容器中。并且在創(chuàng)建這個對象的過程中，Spring還為容器注冊了開天辟地的幾個bd，包括ConfigurationClassPostProcessor，AutowiredAnnotationBeanPostProcessor等等。
那么在本文中，我們就一起來看看Spring中的第二行代碼又做了些什么？
Spring中的第二行代碼
第二行代碼在上面的流程圖中已經(jīng)標(biāo)注的非常明白了，就是
this.scanner = new ClassPathBeanDefinitionScanner(this);
1
只是簡單的創(chuàng)建了一個ClassPathBeanDefinitionScanner對象。**那么這個ClassPathBeanDefinitionScanner有什么作用呢？從名字上來看好像就是這個對象來完成Spring中的掃描的，真的是這樣嗎？**希望同學(xué)們能帶著這兩個問題往下看
ClassPathBeanDefinitionScanner源碼分析
這個類名直譯過來就是：類路徑下的BeanDefinition的掃描器，所以我們就直接關(guān)注其掃描相關(guān)的方法，就是其中的doScan方法。其代碼如下：
// 這個方法會完成對指定包名下的class文件的掃描
// basePackages：指定包名，是一個可變參數(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這個方法是實際完成掃描的方法，也是接下來我們要分析的方法
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {、
// 上篇文章中我們已經(jīng)分析過了，完成了@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都會執(zhí)行postProcessBeanDefinition方法進行一些后置處理
postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}
if (candidate instanceof AnnotatedBeanDefinition) {
// 3. 是不是一個AnnotatedBeanDefinition，如果是的話，還需要進行額外的處理
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
// 4.檢查容器中是否已經(jīng)有這個bd了，如果有就不進行注冊了
if (checkCandidate(beanName, candidate)) {
// 下面這段邏輯在上篇文章中都已經(jīng)分析過了，這里就直接跳過了
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，如果是的話執(zhí)行postProcessBeanDefinition方法
判斷掃描出來的bd是否是一個AnnotatedBeanDefinition，如果是的話執(zhí)行processCommonDefinitionAnnotations方法
檢查容器中是否已經(jīng)有這個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
不用過多關(guān)注這個方法。正常情況下Spring都是采用掃描classpath下的class文件來完成掃描，但是雖然基于classpath掃描速度非?？?，但通過在編譯時創(chuàng)建候選靜態(tài)列表，可以提高大型應(yīng)用程序的啟動性能。在這種模式下，應(yīng)用程序的所有模塊都必須使用這種機制，因為當(dāng) ApplicationContext檢測到這樣的索引時，它將自動使用它而不是掃描類路徑。
要生成索引，只需向包含組件掃描指令目標(biāo)組件的每個模塊添加附加依賴項即可：
Maven：
org.springframework spring-context-indexer 5.0.6.RELEASE true
大家有興趣的話可以參考官網(wǎng)：https://docs.spring.io/spring/docs/5.1.14.BUILD-SNAPSHOT/spring-framework-reference/core.html#beans-scanning-index
這個依賴實在太大了，半天了拉不下來，我這里就不演示了
scanCandidateComponents(basePackage)
正常情況下我們的應(yīng)用都是通過這個方法完成掃描的，其代碼如下：
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構(gòu)建一個MetadataReader對象，這個MetadataReader對象包含了對應(yīng)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官網(wǎng)閱讀（一）容器及實例化 一文中，我畫過這樣一張圖
從上圖中可以看出，java class + configuration metadata 最終會轉(zhuǎn)換為一個BenaDefinition，結(jié)合我們上面的代碼分析可以知道，java class + configuration metadata實際上就是一個MetadataReader對象，而轉(zhuǎn)換成一個BenaDefinition則是指通過這個MetadataReader對象創(chuàng)建一個ScannedGenericBeanDefinition。
2、執(zhí)行postProcessBeanDefinition方法
protected void postProcessBeanDefinition(AbstractBeanDefinition beanDefinition, String beanName) {
// 為bd中的屬性設(shè)置默認值
beanDefinition.applyDefaults(this.beanDefinitionDefaults);
// 注解模式下這個值必定為null,使用XML配置時，
if (this.autowireCandidatePatterns != null) {
beanDefinition.setAutowireCandidate(PatternMatchUtils.simpleMatch(this.autowireCandidatePatterns, beanName));
}
}
// 設(shè)置默認值
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設(shè)置默認值，進一步填充bd中的屬性
3、執(zhí)行processCommonDefinitionAnnotations方法
這句代碼將進一步解析class上的注解信息，Spring在創(chuàng)建這個abd的信息時候就已經(jīng)將當(dāng)前的class放入其中了，所有這行代碼主要做的就是通過class對象獲取到上面的注解（包括@Lazy，@Primary，@DependsOn注解等等），然后將得到注解中對應(yīng)的配置信息并放入到bd中的屬性中
4、注冊BeanDefinition
跟**徹底讀懂Spring（一）讀源碼，我們可以從第一行讀起**的注冊邏輯是一樣的
通過上面的分析，我們已經(jīng)知道了ClassPathBeanDefinitionScanner的作用，毋庸置疑，Spring肯定是通過這個類來完成掃描的，但是問題是，Spring是通過第二步創(chuàng)建的這個對象來完成掃描的嗎？我們再來看看這個ClassPathBeanDefinitionScanner的創(chuàng)建過程：
// 第一步
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) {
// 注冊默認的掃描過濾規(guī)則(要被@Component注解修飾)
registerDefaultFilters();
}
setEnvironment(environment);
setResourceLoader(resourceLoader);
}
在這個ClassPathBeanDefinitionScanner的創(chuàng)建過程中我們?nèi)虩o法干涉，不能對這個ClassPathBeanDefinitionScanner進行任何配置。而我們在配置類上明明是可以對掃描的規(guī)則進行配置的，例如：
@ComponentScan(value = "com.spring.study.springfx.aop.service", useDefaultFilters = true,
excludeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = {IndexService.class}))
1
2
所以Spring中肯定不是使用在這里創(chuàng)建的這個ClassPathBeanDefinitionScanner對象。
實際上真正完成掃描的時機是在我們流程圖中的3-5-1步。完成掃描這個功能的類就是我們在上篇文章中所提到的ConfigurationClassPostProcessor。接下來我們就通過這個類，看看Spring到底是如何完成的掃描，這也是本文重點想要說明的問題
Spring是怎么解析配置類的？
1、解析時機分析
解析前Spring做了什么？
注冊配置類
在分析掃描時機之前我們先回顧下之前的代碼，整個程序的入口如下：
public AnnotationConfigApplicationContext(Class<?>... annotatedClasses) {
this();
register(annotatedClasses);
refresh();
}
1
2
3
4
5
其中在this()空參構(gòu)造中Spring實例化了兩個對象，一個是AnnotatedBeanDefinitionReader，在上篇文章中已經(jīng)介紹過了，另外一個是ClassPathBeanDefinitionScanner，在前文中也進行了詳細的分析。
在完成這兩個對象的創(chuàng)建后，Spring緊接著就利用第一步中創(chuàng)建的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被注冊到了容器中
}
}
大家仔細想想我這個問題，不妨帶著這些疑問繼續(xù)往下看。
調(diào)用refresh方法
在將配置類注冊到容器中后，Spring緊接著又調(diào)用了refresh方法，其源碼如下：
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// 這個方法主要做了以下幾件事
// 1.記錄容器的啟動時間，并將容器狀態(tài)更改為激活
// 2.調(diào)用initPropertySources()方法，主要用于web環(huán)境下初始化封裝相關(guān)的web資源，比如將servletContext封裝成為ServletContextPropertySource
// 3.校驗環(huán)境中必要的屬性是否存在
// 4.提供了一個擴展點可以提前放入一些事件，當(dāng)applicationEventMulticaster這個bean被注冊到容器中后就直接發(fā)布事件
prepareRefresh();
// 實際上獲取的就是一個DefaultListableBeanFactory
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 為bean工廠設(shè)置一些屬性
prepareBeanFactory(beanFactory);
try {
// 提供給子類復(fù)寫的方法，允許子類在這一步對beanFactory做一些后置處理
postProcessBeanFactory(beanFactory);
// 執(zhí)行已經(jīng)注冊在容器中的bean工廠的后置處理器，在這里完成的掃描
invokeBeanFactoryPostProcessors(beanFactory);
// 后面的代碼跟掃描無關(guān)，我們在之后的文章再介紹
}
// .....
}
}
大部分的代碼都寫了很詳細的注釋，對于其中兩個比較復(fù)雜的方法我們單獨分析
prepareBeanFactory
invokeBeanFactoryPostProcessors
prepareBeanFactory做了什么？
protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
// 設(shè)置classLoader,一般就是appClassLoader
beanFactory.setBeanClassLoader(getClassLoader());
// 設(shè)置el表達式解析器
beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
// 容器中添加一個屬性編輯器注冊表，關(guān)于屬性編輯在《Spring官網(wǎng)閱讀（十四）Spring中的BeanWrapper及類型轉(zhuǎn)換》有過詳細介紹，這里就不再贅述了
beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
// 添加了一個bean的后置處理器，用于執(zhí)行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中查找是否有對應(yīng)類型的bean存在，如果有的話就直接注入，下面這段代碼就是將對應(yīng)的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()));
}
// 配置一些默認的環(huán)境相關(guān)的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做一些配置，我們需要注意的是跟后置處理器相關(guān)的內(nèi)容，可以看到在這一步一共注冊了兩個后置處理器
ApplicationContextAwareProcessor，用于執(zhí)行xxxAware接口中的方法
ApplicationListenerDetector，保證監(jiān)聽器被添加到容器中
關(guān)于ApplicationListenerDetector請參考Spring官網(wǎng)閱讀（八）容器的擴展點（三）（BeanPostProcessor）
invokeBeanFactoryPostProcessors做了什么?
這個方法的執(zhí)行流程在Spring官網(wǎng)閱讀（六）容器的擴展點（一）BeanFactoryPostProcessor 已經(jīng)做過非常詳細的分析了，其執(zhí)行流程如下
整的來說，它就是將容器中已經(jīng)注冊的bean工廠的后置處理器按照一定的順序進行執(zhí)行。
那么到這一步為止，容器中已經(jīng)有哪些bean工廠的后置處理器呢？
還記得我們在上篇文章中提到的ConfigurationClassPostProcessor嗎？在創(chuàng)建AnnotatedBeanDefinitionReader的過程中它對應(yīng)的BeanDefinition就被注冊到容器中了。接下來我們就來分析ConfigurationClassPostProcessor這個類的源碼
ConfigurationClassPostProcessor源碼分析
它實現(xiàn)了BeanDefinitionRegistryPostProcessor，所以首先執(zhí)行它的postProcessBeanDefinitionRegistry方法，其源碼如下
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
// 生成一個注冊表ID
int registryId = System.identityHashCode(registry);
//.....
// 表明這個工廠已經(jīng)經(jīng)過了后置處理器了
this.registriesPostProcessed.add(registryId);
// 從名字來看這個方法是再對配置類的bd進行處理
processConfigBeanDefinitions(registry);
}
processConfigBeanDefinitions方法的代碼很長，我們拆分一段段分析，先看第一段
第一段
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
// ========第一段代碼========
List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
// 大家可以思考一個問題，當(dāng)前容器中有哪些BeanDefinition呢？
// 這個地方應(yīng)該能獲取到哪些名字？
String[] candidateNames = registry.getBeanDefinitionNames();
for (String beanName : candidateNames) {
// 根據(jù)名稱獲取到對應(yīng)BeanDefinition
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
// 省略日志打印
// 檢查是否是配置類，在這里會將對應(yīng)的bd標(biāo)記為FullConfigurationClass或者LiteConfigurationClass
else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
// 是配置類的話，將這個bd添加到configCandidates中
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
}
// 沒有配置類，直接返回
if (configCandidates.isEmpty()) {
return;
}
// 根據(jù)@Order注解進行排序
configCandidates.sort((bd1, bd2) -> {
int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
return Integer.compare(i1, i2);
});
// .....
面這段代碼有這么幾個問題：
當(dāng)前容器中有哪些BeanDefinition
如果你看過上篇文章的話應(yīng)該知道，在創(chuàng)建AnnotatedBeanDefinitionReader對象的時候Spring已經(jīng)往容器中注冊了5個BeanDefinition，再加上注冊的配置類，那么此時容器中應(yīng)該存在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包含了對應(yīng)class上的注解元信息以及class元信息
AnnotationMetadata metadata;
if (beanDef instanceof AnnotatedBeanDefinition &&
className.equals(((AnnotatedBeanDefinition) beanDef).getMetadata().getClassName())) {
// 已經(jīng)解析過了，比如注冊的配置類就屬于這種，直接從bd中獲取
metadata = ((AnnotatedBeanDefinition) beanDef).getMetadata();
}
else if (beanDef instanceof AbstractBeanDefinition && ((AbstractBeanDefinition) beanDef).hasBeanClass()) {
// 拿到字節(jié)碼重新解析獲取到一個AnnotationMetadata
Class<?> beanClass = ((AbstractBeanDefinition) beanDef).getBeanClass();
metadata = new StandardAnnotationMetadata(beanClass, true);
}
else {
try {
// class屬性都沒有，就根據(jù)className利用ASM字節(jié)碼技術(shù)獲取到這個AnnotationMetadata
MetadataReader metadataReader = metadataReaderFactory.getMetadataReader(className);
metadata = metadataReader.getAnnotationMetadata();
}
catch (IOException ex) {
return false;
}
}
// 如果被@Configuration注解標(biāo)注了，說明是一個FullConfigurationCandidate
if (isFullConfigurationCandidate(metadata)) {
beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);
}
// 如果被這些注解標(biāo)注了，@Component，@ComponentScan，@Import，@ImportResource
// 或者方法上有@Bean注解，那么就是一個LiteConfigurationCandidate
// 也就是說你想把這個類當(dāng)配置類使用，但是沒有添加@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)建這個ConfigurationClassParser對象
ConfigurationClassParser parser = new ConfigurationClassParser(
this.metadataReaderFactory, this.problemReporter, this.environment,
this.resourceLoader, this.componentScanBeanNameGenerator, registry);
// 第三段
}
這段代碼核心目的就是為了創(chuàng)建一個ConfigurationClassParser,這個類主要用于后續(xù)的配置類的解析。
第三段
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
// 第一段，第二段
// .....
Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
do {
// 在第二段代碼中創(chuàng)建了一個ConfigurationClassParser，這里就是使用這個parser來解析配置類
// 我們知道掃描就是通過@ComponentScan，@ComponentScans來完成的，那么不出意外必定是在這里完成的掃描
parser.parse(candidates);
// 校驗在解析過程是中是否發(fā)生錯誤，同時會校驗@Configuration注解的類中的@Bean方法能否被復(fù)寫（被final修飾或者訪問權(quán)限為private都不能被復(fù)寫），如果不能被復(fù)寫會拋出異常，因為cglib代理要通過復(fù)寫父類的方法來完成代理，后文會做詳細介紹
parser.validate();
// 已經(jīng)解析過的配置類
Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
// 移除已經(jīng)解析過的配置類，防止重復(fù)加載了配置類中的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等注解得到相關(guān)信息解析成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到容器中
// 當(dāng)通過@Import注解導(dǎo)入一個全配置類A（被@Configuration注解修飾的類），A可以實現(xiàn)ImportAware接口
// 通過這個Aware可以感知到是哪個類導(dǎo)入的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、解析源碼分析
在上面的源碼分析中，我們已經(jīng)能夠確定了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;
}
// 判斷解析器是否已經(jīng)解析過這個配置類了
ConfigurationClass existingClass = this.configurationClasses.get(configClass);
// 不為null,說明已經(jīng)解析過了
if (existingClass != null) {
// 如果這個要被解析的配置類是被@Import注解導(dǎo)入的
if (configClass.isImported()) {
// 并且解析過的配置類也是被導(dǎo)入的
if (existingClass.isImported()) {
// 那么這個配置類的導(dǎo)入類集合中新增當(dāng)前的配置類的導(dǎo)入類，（A通過@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)解析過的配置類不是被導(dǎo)入的，那么直接忽略新增的這個被導(dǎo)入的配置類。也就是說如果一個配置類同時被@Import導(dǎo)入以及正常的
// 添加到容器中，那么正常添加到容器中的配置類會覆蓋被導(dǎo)入的類
return;
}
else {
// Explicit bean definition found, probably replacing an import.
// Let's remove the old one and go with the new one.
// 就是說新要被解析的這個配置類不是被導(dǎo)入的，所以這種情況下，直接移除調(diào)原有的解析的配置類
// 為什么不是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方便進行統(tǒng)一的處理
SourceClass sourceClass = asSourceClass(configClass);
do {
// doxxx方法，真正干活的方法，對配置類進行處理，返回值是當(dāng)前這個類的父類
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注解，將對應(yīng)的屬性資源添加容器中（實際上添加到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方法
// 在創(chuàng)建一個代理的bd時不會為null
BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
if (bdCand == null) {
bdCand = holder.getBeanDefinition();
}
// 判斷掃描出來的bd是否是一個配置類，如果是的話繼續(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
// 返回父類，進行遞歸處理
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真正完成了對配置類的解析，一共做了下面幾件事
解析配置類中的內(nèi)部類，看內(nèi)部類中是否有配置類，如果有進行遞歸處理
處理配置類上的@PropertySources跟@PropertySource注解
處理@ComponentScan，@ComponentScans注解
處理@Import注解
處理@ImportResource注解
處理@Bean注解
處理接口中的default方法
返回父類，讓外部的循環(huán)繼續(xù)處理當(dāng)前配置類的父類
我們逐一進行分析
2.4、處理配置類中的內(nèi)部類
這段代碼非常簡單，限于篇幅原因我這里就不再專門分析了，就是獲取到當(dāng)前配置類中的所有內(nèi)部類，然后遍歷所有的內(nèi)部類，判斷是否是一個配置類，如果是配置類的話就遞歸進行解析
2.5、處理@PropertySource注解
代碼也非常簡單，根據(jù)注解中的信息加載對應(yīng)的屬性文件然后添加到容器中
2.6、處理@ComponentScan注解
這個段我們就需要看一看了，Spring在這里完成的掃描，我們直接查看其核心方法，org.springframework.context.annotation.ComponentScanAnnotationParser#parse
public Set<BeanDefinitionHolder> parse(AnnotationAttributes componentScan, final String declaringClass) {
// 第一步就創(chuàng)建了一個ClassPathBeanDefinitionScanner對象
// 在這里我們就知道了，Spring在進行掃描時沒有使用在最開始的時候創(chuàng)建的那個對象進行掃描
ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(this.registry,
componentScan.getBoolean("useDefaultFilters"), this.environment, this.resourceLoader);
// 解析成bd時采用的beanName的生成規(guī)則
Class<? extends BeanNameGenerator> generatorClass = componentScan.getClass("nameGenerator");
boolean useInheritedGenerator = (BeanNameGenerator.class == generatorClass);
scanner.setBeanNameGenerator(useInheritedGenerator ? this.beanNameGenerator :
BeanUtils.instantiateClass(generatorClass));
// 配置這個掃描規(guī)則下的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));
}
// 配置掃描器的匹配規(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);
}
}
// 配置默認是否進行懶加載
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);
}
});
// 在完成對掃描器的配置后，直接調(diào)用其doScan方法進行掃描
return scanner.doScan(StringUtils.toStringArray(basePackages));
}
看到了吧，第一步就創(chuàng)建了一個ClassPathBeanDefinitionScanner,緊接著通過解析注解，對這個掃描器進行了各種配置，然后調(diào)用doScan方法完成了掃描。
2.7、處理@Import注解
private void processImports(ConfigurationClass configClass, SourceClass currentSourceClass,
Collection<SourceClass> importCandidates, boolean checkForCircularImports) {
// 沒有要導(dǎo)入的類，直接返回
if (importCandidates.isEmpty()) {
return;
}
// checkForCircularImports：Spring中寫死的為true,需要檢查循環(huán)導(dǎo)入
// isChainedImportOnStack方法：檢查導(dǎo)入棧中是否存在了這個configClass，如果存在了說明
// 出現(xiàn)了A import B,B import A的情況，直接拋出異常
if (checkForCircularImports && isChainedImportOnStack(configClass)) {
this.problemReporter.error(new CircularImportProblem(configClass, this.importStack));
}
else {
// 沒有出現(xiàn)循環(huán)導(dǎo)入，先將當(dāng)前的這個配置類加入到導(dǎo)入棧中
this.importStack.push(configClass);
try {
// 遍歷所有要導(dǎo)入的類
for (SourceClass candidate : importCandidates) {
// 如果要導(dǎo)入的類是一個ImportSelector
if (candidate.isAssignable(ImportSelector.class)) {
// Candidate class is an ImportSelector -> delegate to it to determine imports
// 反射創(chuàng)建這個ImportSelector
Class<?> candidateClass = candidate.loadClass();
ImportSelector selector = BeanUtils.instantiateClass(candidateClass, ImportSelector.class);
// 執(zhí)行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獲取到要導(dǎo)入的類名
String[] importClassNames = selector.selectImports(currentSourceClass.getMetadata());
// 將其轉(zhuǎn)換成SourceClass
Collection<SourceClass> importSourceClasses = asSourceClasses(importClassNames);
// 遞歸處理要導(dǎo)入的類，一般情況下這個時候進入的就是另外兩個判斷了
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
// 先通過反射創(chuàng)建這個ImportBeanDefinitionRegistrar
Class<?> candidateClass = candidate.loadClass();
ImportBeanDefinitionRegistrar registrar =
BeanUtils.instantiateClass(candidateClass, ImportBeanDefinitionRegistrar.class);
// 再執(zhí)行xxxAware方法
ParserStrategyUtils.invokeAwareMethods(
registrar, this.environment, this.resourceLoader, this.registry);
// 最后將其添加到configClass的importBeanDefinitionRegistrars集合中
// 之后會統(tǒng)一調(diào)用其ImportBeanDefinitionRegistrar的registerBeanDefinitions方法，將對應(yīng)的bd注冊到容器中
configClass.addImportBeanDefinitionRegistrar(registrar, currentSourceClass.getMetadata());
}
else {
// Candidate class not an ImportSelector or ImportBeanDefinitionRegistrar ->
// process it as an @Configuration class
// 既不是一個ImportSelector也不是一個ImportBeanDefinitionRegistrar，直接導(dǎo)入一個普通類
// 并將這個類作為配置類進行遞歸處理
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注解
代碼也很簡單，在指定的位置加載資源，然后添加到configClass中。一般情況下，我們通過@ImportResource注解導(dǎo)入的就是一個XML配置文件。將這個Resource添加到configClass后，Spring會在后文中解析這個XML配置文件然后將其中的bd注冊到容器中，可以參考o(jì)rg.springframework.context.annotation.ConfigurationClassBeanDefinitionReader#loadBeanDefinitions方法
2.9、處理@Bean注解
將配置類中所有的被@Bean標(biāo)注的方法添加到configClass的BeanMethod集合中
2.10、處理接口中的default方法
代碼也很簡單，Java8中接口能定義default方法，這里就是處理接口中的default方法，看其是否有@Bean標(biāo)注的方法
到此為止，我們分析完了整個解析的過程。可以發(fā)現(xiàn)Spring將所有解析到的配置信息都存儲在了ConfigurationClass類中，但是到目前為止這些存儲的信息都沒有進行使用。那么Spring是在哪里使用的這些信息呢？回到我們的第三段代碼，其中有一行代碼如圖所示：
也就是在這里Spring完成了對解析好的配置類的信息處理。
2.11、加載解析完成的配置信息
// configurationModel:被解析完成了配置類集合，其中保存了@Bean注解解析信息，@Import注解解析信息等等
public void loadBeanDefinitions(Set<ConfigurationClass> configurationModel) {
TrackedConditionEvaluator trackedConditionEvaluator = new TrackedConditionEvaluator();
for (ConfigurationClass configClass : configurationModel) {
// 調(diào)用這個方法完成的加載
loadBeanDefinitionsForConfigurationClass(configClass, trackedConditionEvaluator);
}
}
1
2
3
4
5
6
7
8
private void loadBeanDefinitionsForConfigurationClass(
ConfigurationClass configClass, TrackedConditionEvaluator trackedConditionEvaluator) {
// 判斷是否需要跳過，例如A導(dǎo)入了B，A不滿足加載的條件需要被跳過，那么B也應(yīng)該被跳過
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)入進來的，實際的代碼就是判斷解析出來的configclass中的importedBy集合是否為空
// 那么這個importedBy集合是做什么的呢？
// 例如A通過@Import導(dǎo)入了B，那么解析B得到得configclass中得importedBy集合就包含了A
// 簡而言之，importedBy集合就是導(dǎo)入了這個類的其它類（可能同時被多個類導(dǎo)入）
// 在前文中我們也分析過了，被多個類同時導(dǎo)入時會調(diào)用mergeImportedBy方法在集合中添加一個元素
if (configClass.isImported()) {
registerBeanDefinitionForImportedConfigurationClass(configClass);
}
// 解析@Bean標(biāo)注的Method得到對應(yīng)的BeanDefinition并注冊到容器中
for (BeanMethod beanMethod : configClass.getBeanMethods()) {
loadBeanDefinitionsForBeanMethod(beanMethod);
}
// 解析導(dǎo)入的配置文件，并將從中得到的bd注冊到容器中
loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());
// 執(zhí)行configClass中的所有ImportBeanDefinitionRegistrar的registerBeanDefinitions方法
loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
}
13450931319
微信登錄
QQ登錄
微博登錄
售前咨詢
