如何學習spring源碼
前言
本文屬於spring源碼解析的系列文章之一，文章主要是介紹如何學習spring的源碼，希望能夠最大限度的幫助到有需要的人。文章總體難度不大，但比較繁重，學習時一定要耐住性子堅持下去。
獲取源碼
源碼的獲取有多種途徑
GitHub
可以從GitHub上獲取源代碼，然后自行編譯
maven
使用過maven的都知道可以通過maven下載相關的源代碼和相關文檔，簡單方便。
這里推薦通過maven的方式構建一個web項目。通過對實際項目的運行過程中進行調試來學習更好。
如何開始學習
前置條件
如果想要開始學習spring的源碼，首先要求本身對spring框架的使用基本了解。明白spring中的一些特性如ioc等。了解spring中各個模塊的作用。
確定目標
首先我們要知道spring框架本身經過多年的發展現在已經是一個龐大的家族。可能其中一個功能的實現依賴於多個模塊多個類的相互配合，這樣會導致我們在閱讀代碼時難度極大。多個類之間進行跳躍很容易讓我們暈頭轉向。
所以在閱讀spring的源代碼的時候不能像在JDK代碼時一行一行的去理解代碼，需要把有限的精力更多的分配給重要的地方。而且我們也沒有必要這樣去閱讀。
在閱讀spring某一功能的代碼時應當從一個上帝視角來總覽全局。只需要知道某一個功能的實現流程即可，而且幸運的是spring的代碼規范較好，大多數方法基本都能見名知意，這樣也省去了我們很多的麻煩。
利用好工具
閱讀代碼最好在idea或者eclipse中進行，這類IDE提供的很多功能很有幫助。
在閱讀時配合spring文檔更好(如果是自行編譯源碼直接看注釋更好)。
筆記和復習
這個過程及其重要，我以前也看過一些spring的源碼，但是好幾次都是感覺比較吃力在看過一些后就放棄了。而由於沒有做筆記和沒有復習的原因很快就忘了。下次想看的時候還要重新看一遍，非常的浪費時間。
下面以IOC為例說明下我是怎么看的，供參考。
IOC
入口：ApplicationContext
在研究源碼時首先要找到一個入口，這個入口怎么選擇可以自己定，當一定要和你需要看的模塊有關聯。
比如在IOC中，首先我們想到創建容器是在什么過程？
在程序啟動的時候就創建了，而且在啟動過程中大多數的bean實例就被注入了。
那問題來了，在啟動的時候是從那個類開始的呢？熟悉spring的應該都知道我們平時在做單元測試時如果要獲取bean實例，一個是通過注解，另外我們還可以通過構建一個ApplicationContext來獲取：
ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath*:application.xml");
XxxService xxxService = applicationContext.getBean("xxxService");
在實例化ApplicationContext后既可以獲取bean，那么實例化的這個過程就相當於啟動的過程了，所以我們可以將ApplicationContext當成我們的入口。
ApplicationContext是什么
首先我們要明白的事我們平時一直說的IOC容器在Spring中實際上指的就是ApplicationContext。
如果有看過我之前手寫Spring系列文章的同學肯定知道在當時文章中充當ioc容器的是BeanFactory，每當有bean需要注入時都是由BeanFactory保存，取bean實例時也是從BeanFactory中獲取。
那為什么現在要說ApplicationContext才是IOC容器呢？
因為在spring中BeanFactory實際上是被隱藏了的。ApplicationContext是對BeanFactory的一個封裝，也提供了獲取bean實例等功能。因為BeanFactory本身的能力實在太強，如果可以讓我們隨便使用可能會對spring功能的運行造成破壞。於是就封裝了一個提供查詢ioc容器內容的ApplicationContext供我們使用。
如果項目中需要用到ApplicationContext，可以直接使用spring提供的注解獲取：
@Autowired
private ApplicationContext applicationContext;
如何使用ApplicationContext
如果我們要使用ApplicationContext可以通過new該類的一個實例即可，定義好相應的xml文件。然后通過下面的代碼即可：
@Test
public void testClassPathXmlApplicationContext() {
//1.准備配置文件，從當前類加載路徑中獲取配置文件
//2.初始化容器
ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath*:application.xml");
//2、從容器中獲取Bean
HelloApi helloApi = applicationContext.getBean("hello", HelloApi.class);
//3、執行業務邏輯
helloApi.sayHello();
}
ApplicationContext的體系
了解一個類，首先可以來看看它的繼承關系來了解其先天的提供哪些功能。然后在看其本身又實現了哪些功能。
上圖中繼承關系從左至右簡要介紹其功能。
- ApplicationEventPublisher：提供發布監聽事件的功能，接收一個監聽事件實體作為參數。需要了解的可以通過這篇文章：事件監聽
- ResourcePatternResolver：用於解析一些傳入的文件路徑(比如ant風格的路徑)，然后將文件加載為resource。
- HierarchicalBeanFactory：提供父子容器關系，保證子容器能訪問父容器，父容器無法訪問子容器。
- ListableBeanFactory：繼承自BeanFactory，提供訪問IOC容器的方法。
- EnvironmentCapable：獲取環境變量相關的內容。
- MessageSource：提供國際化的message的解析
配置文件的加載
Spring中每一個功能都是很大的一個工程，所以在閱讀時也要分為多個模塊來理解。要理解IOC容器，我們首先需要了解spring是如何加載配置文件的。
縱覽大局
idea或者eclipse提供了一個很好的功能就是能在調試模式下看到整個流程的調用鏈。利用這個功能我們可以直接觀察到某一功能實現的整體流程，也方便在閱讀代碼時在不同類切換。
以加載配置文件為例，這里給出整個調用鏈。
上圖中下面的紅框是我們寫的代碼，即就是我們應該開始的地方。下面的紅框就是加載配置文件結束的地方。中間既是整體流程的實現過程。在閱讀配置文件加載的源碼時我們只需要關心這一部分的內容即可。
需要知道的是這里展示出來的僅僅只是跟這個過程密切相關的一些方法。實際上在這個過程中還有需要的方法被執行，只不過執行完畢后方法棧彈出所以不顯示在這里。不過大多數方法都是在為這個流程做准備，所以基本上我們也不用太在意這部分內容
refresh()
前面的關於ClassPathXmlApplicationContext的構造函數部分沒有啥好說的，在構造函數中調用了一個方法AbstractApplicationContext#refresh。該方法非常重要，在創建IOC容器的過程中該方法基本上是全程參與。主要功能為用於加載配置或這用於刷新已經加載完成的容器配置。通過該方法可以在運行過程中動態的加入配置文件等：
ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext();
ctx.setConfigLocation("application-temp.xml");
ctx.refresh();
AbstractApplicationContext#refresh
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
prepareRefresh();
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// more statement ...
}
}
這里將於當前功能不相關的部分刪除掉了，可以看到進入方法后就會進入一個同步代碼塊。這是為了防止在同一時間有多個線程開始創建IOC容器造成重復實例化。
prepareRefresh();方法主要用於設置一些日志相關的信息，比如容器啟動時間用於計算啟動容器整體用時，以及設置一些變量用來標識當前容器已經被激活，后續不會再進行創建。
obtainFreshBeanFactory();方法用於獲取一個BeanFactory，在這一過程中便會加載配置文件和解析用於生成一個BeanFactory。
refreshBeanFactory
refreshBeanFactory方法有obtainFreshBeanFactory方法調用
protected final void refreshBeanFactory() throws BeansException {
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
customizeBeanFactory(beanFactory);
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}
該方法首先判斷是否已經實例化好BeanFactory，如果已經實例化完成則將已經實例化好的BeanFactory銷毀。
然后通過new關鍵字創建一個BeanFactory的實現類實例，設置好相關信息。customizeBeanFactory(beanFactory)方法用於設置是否運行當beanName重復是修改bean的名稱(allowBeanDefinitionOverriding)和是否運行循環引用(allowCircularReferences)。
loadBeanDefinitions(beanFactory)方法既是開始加載bean定義的方法。當BeanFactory在加載完所有配置信息后創建，然后將創建好的BeanFactory賦值給當前context下的BeanFactory。
loadBeanDefinitions
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
initBeanDefinitionReader(beanDefinitionReader);
loadBeanDefinitions(beanDefinitionReader);
}
loadBeanDefinitions見名知意其就是用於加載bean定義的方法，在AbstractXmlApplicationContext中定義了一系列該方法的重載方法。上面的方法主要便是引入XmlBeanDefinitionReader。XmlBeanDefinitionReader是一個用於讀取xml文件中bean定義的類，其提供了一些諸如BeanFactory和BeanDefinitionRegistery類的屬性以供使用。但其實真正的讀取操作並沒該類完成，其也是作為一個代理存在。
在spring中如果是完成一些類似操作的類的命名都是有跡可循的，比如這里讀取xml文件就是以reader結尾，類似的讀取注解中bean定義也有如AnnotatedBeanDefinitionReader。如果需要向類中注入一些Spring中的bean，一般是以Aware結尾如BeanFactoryAware等。所以在閱讀spring源碼時如果遇到這樣的類很多時候我們可以直接根據其命名了解其大概的實現方式。
public int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {
ResourceLoader resourceLoader = getResourceLoader();
if (resourceLoader == null) {
throw new BeanDefinitionStoreException(
"Cannot import bean definitions from location [" + location + "]: no ResourceLoader available");
}
if (resourceLoader instanceof ResourcePatternResolver) {
try {
Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
int loadCount = loadBeanDefinitions(resources);
if (actualResources != null) {
for (Resource resource : resources) {
actualResources.add(resource);
}
}
//logging
return loadCount;
}catch (IOException ex) {
throw new BeanDefinitionStoreException(
"Could not resolve bean definition resource pattern [" + location + "]", ex);
}
}else {
Resource resource = resourceLoader.getResource(location);
int loadCount = loadBeanDefinitions(resource);
if (actualResources != null) {
actualResources.add(resource);
}
//logging
return loadCount;
}
}
上面代碼是loadBeanDefinitions的一個實現類，該方法的主要注意點在於三個地方。
一個是方法中拋出的兩個異常，前一個異常時因為ResourceLoader定義的問題，一般來說不需要我們關注。后一個就是配置文件出錯了，可能是因為文件本身xml格式出錯或者是由於循環引用等原因，具體的原因也會通過日志打印。我們需要對這些異常信息有印象，也不用刻意去記，遇到了能快速定位問題即可。
另一個就是代碼中的一個if(){}else{}語句塊，判斷語句快中都是用於解析配置文件，不同之處在於if中支持解析匹配風格的location，比如classpath*:spring.xml這種，該功能的實現由ResourcePatternResolver提供，ResourcePatternResolver對ResourceLoader的功能進行了增強，支持解析ant風格等模式的location。而else中僅僅只能解析指定的某一文件如spring.xml這種。實際上在ApplicationContext中實現了ResourcePatternResolver，如果也按照spring.xml配置，也是按照ResourceLoader提供的解析方式解析。
最后一處就是Resource類，Resource是spring為了便於加載文件而特意設計的接口。其提供了大量對傳入的location操作方法，支持對不同風格的location(比如文件系統或者ClassPath)。其本身還有許多不同的實現類，本質上是對File，URL，ClassPath等不同方式獲取location的一個整合，功能十分強大。即使我們的項目不依賴spring，如果涉及到Resource方面的操作也可以使用Spring中的Resource。
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
//log and assert
Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
if (currentResources == null) {
currentResources = new HashSet<EncodedResource>(4);
this.resourcesCurrentlyBeingLoaded.set(currentResources);
}
if (!currentResources.add(encodedResource)) {
throw new BeanDefinitionStoreException(
"Detected cyclic loading of " + encodedResource + " - check your import definitions!");
}
try {
InputStream inputStream = encodedResource.getResource().getInputStream();
try {
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
finally {
inputStream.close();
}
}catch (IOException ex) {
throw new BeanDefinitionStoreException(
"IOException parsing XML document from " + encodedResource.getResource(), ex);
}finally {
currentResources.remove(encodedResource);
if (currentResources.isEmpty()) {
this.resourcesCurrentlyBeingLoaded.remove();
}
}
}
該方法依舊是loadBeanDefinitions的重載方法。
方法傳入一個EncodedResource，該類可以通過制定的字符集對Resource進行編碼，利於統一字符編碼格式。
然后try語句塊上面的代碼也是比較重要的，主要功能便是判斷是否有配置文件存在循環引用的問題。
循環應用問題出現在比如我加載一個配置文件application.xml，但是在該文件內部又通過import標簽引用了自身。在解析到import時會加載import指定的文件。這樣就造成了一個死循環，如果不解決程序就會永遠啟動不起來。
解決的方法也很簡單，通過一個ThreadLocal記錄下當前正在加載的配置文件名稱(包括路徑)，每一次在加載新的配置文件時從ThreadLocal中取出放入到set集合中，通過set自動去重的特性判斷是否循環加載了。當一個文件加載完成后，就從ThreadLocal中去掉(finally)。這里是判斷xml文件時否重復加載，而在spring中判斷bean是否循環引用是雖然實現上有點差別，但基本思想也是這樣的。
doLoadBeanDefinitions(InputSource, Resource)
到了這一步基本上才算是真正開始解析了。該方法雖然代碼行數較多，但是大多都是異常處理，異常代碼已經省略。我們需要關注的就是try中的兩句代碼。
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
Document doc = doLoadDocument(inputSource, resource);
return registerBeanDefinitions(doc, resource);
}catch (Exception ex) {
//多個catch語句塊
}
}
Document doc = doLoadDocument(inputSource, resource)就是讀取配置文件並將其內容解析為一個Document的過程。解析xml一般來說並不需要我們特別的去掌握，稍微有個了解即可，spring這里使用的解析方式為Sax解析，有興趣的可以直接搜索相關文章，這里不進行介紹。下面的registerBeanDefinitions才是我們需要關注的地方。
registerBeanDefinitions(Document, Resource)
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
documentReader.setEnvironment(getEnvironment());
int countBefore = getRegistry().getBeanDefinitionCount();
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
return getRegistry().getBeanDefinitionCount() - countBefore;
}
在進入該方法后首先創建了一個BeanDefinitionDocumentReader的實例，這和之前的用於讀取xml的reader類一樣，只不過該類是用於從xml文件中讀取BeanDefinition。
Environment
在上面的代碼中給Reader設置了Environment，這里談一下關於Environment。
Environment是對spring程序中涉及到環境有關的一個描述集合，主要分為profile和properties。
profile是一組bean定義的集合，通過profile可以指定不同的配置文件用以在不同的環境中，如測試環境，生產環境的配置分開。在部署時只需要配置好當前所處環境值即可按不同分類加載不同的配置。
profile支持xml配置和注解的方式。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
//more >
<!-- 定義開發環境的profile -->
<beans profile="development">
<!-- 只掃描開發環境下使用的類 -->
<context:component-scan base-package="com.demo.service" />
<!-- 加載開發使用的配置文件 -->
<util:properties id="config" location="classpath:dev/config.properties"/>
</beans>
<!-- 定義生產環境的profile -->
<beans profile="produce">
<!-- 只掃描生產環境下使用的類 -->
<context:component-scan
base-package="com.demo.service" />
<!-- 加載生產使用的配置文件 -->
<util:properties id="config" location="classpath:produce/config.properties"/>
</beans>
</beans>
也可以通過注解配置：
@Service
@Profile("dev")
public class ProductRpcImpl implements ProductRpc {
public String productBaseInfo(int id) {
return "success";
}
}
然后在啟動時根據傳入的環境值加載相應的配置。
properties是一個很寬泛的定義，其來源很多如properties文件，JVM系統變量，系統環境變量，JNDI，servlet上下文參數，Map等。spring會讀取這些配置並在environment接口中提供了方便對其進行操作的方法。
總之就是設計到跟環境有關的直接來找Environment即可。
handler
代碼接着往下走，documentReader.registerBeanDefinitions(doc, createReaderContext(resource))這一步很明顯就是從解析好的document對象中讀取BeanDefinition的過程，但是在此之前我們先要關注一下createReaderContext(resource)方法。
先來看一個XML文件。
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc" >
</beans>
上面是xml中根元素定義部分，可能平時並沒有太多人注意。其屬性中的xmlns是XML NameSpace的縮寫。namespace的作用主要是為了防止在xml定義的節點存在沖突的問題。比如上面聲明了mvc的namespace：xmlns:mvc="http://www.springframework.org/schema/mvc"。在xml文件中我們就可以使用mvc了：
<mvc:annotation-driven />
<mvc:default-servlet-handler/>
而實際上在spring中還根據上面定義的namespace來准備了各自的處理類。這里因為解析過程就是將xml定義的每一個節點取出根據配置好的屬性和值來初始化或注冊bean，為了保證代碼可讀性和明確的分工，每一個namespace通過一個專有的handler來處理。
跟蹤createReaderContext(resource)方法，最終來到DefaultNamespaceHandlerResolver類的構造方法中。
public DefaultNamespaceHandlerResolver(ClassLoader classLoader) {
//DEFAULT_HANDLER_MAPPINGS_LOCATION = "META-INF/spring.handlers"
this(classLoader, DEFAULT_HANDLER_MAPPINGS_LOCATION);
}
可以看到默認的handler是通過一個本地文件來進行映射的。該文件存在於被依賴jar包下的META-INF文件夾下的spring.handlers文件中。
http\://www.springframework.org/schema/c=org.springframework.beans.factory.xml.SimpleConstructorNamespaceHandler
http\://www.springframework.org/schema/p=org.springframework.beans.factory.xml.SimplePropertyNamespaceHandler
http\://www.springframework.org/schema/util=org.springframework.beans.factory.xml.UtilNamespaceHandler
這里只是展示了beans包下的映射文件，其他如aop包，context包下都有相應的映射文件。通過讀取這些配置文件來映射相應的處理類。在解析xml時會根據使用的namespace前綴使用對應的handler類解析。這種實現機制其實就是所謂的SPI(Service Provider Interface)，目前很多的應用都在實現過程中使用了spi，如dubbo，mysql的jdbc實現等，有興趣的可以取了解一下。
doRegisterBeanDefinitions(Element)
到這一步中間省略了一個方法，很簡單沒有分析的必要。
protected void doRegisterBeanDefinitions(Element root) {
BeanDefinitionParserDelegate parent = this.delegate;
this.delegate = createDelegate(getReaderContext(), root, parent);
if (this.delegate.isDefaultNamespace(root)) {
String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);
if (StringUtils.hasText(profileSpec)) {
String[] specifiedProfiles = StringUtils.tokenizeToStringArray(
profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);
if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {
return;
}
}
}
preProcessXml(root);
parseBeanDefinitions(root, this.delegate);
postProcessXml(root);
this.delegate = parent;
}
delegate
這里的delegate是對BeanDefinitionParse功能的代理，提供了一些支持解析過程的方法。我們可以看到上面有一個重新創建delegate同時又將之前的delegate保存的代碼。注釋上說是為了防止嵌套的beans標簽遞歸操作導致出錯，但是注釋后面又說這並不需要這樣處理，這個操作真的看不懂了，實際上我認為即使遞歸應該也是沒有影響的。還是我理解錯了？
創建好delegate后下面的if語句塊就是用來判斷當前加載的配置文件是否是當前使用的profile指定的配置文件。上面在介紹Environment的時候已經介紹過來，如果這里加載的配置文件和profile指定的不符則直接結束。
preProcessXml(root)方法是一個空實現，並且當前spring框架中好像也沒有對這個方法實現的，這里不管了。同理還有下面的postProcessXml(root)。
parseBeanDefinitions(Element, BeanDefinitionParserDelegate)
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
if (delegate.isDefaultNamespace(root)) {
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element) {
Element ele = (Element) node;
if (delegate.isDefaultNamespace(ele)) {
parseDefaultElement(ele, delegate);
}
else {
delegate.parseCustomElement(ele);
}
}
}
}
else {
delegate.parseCustomElement(root);
}
}
該方法的理解起來並不難，首先讀取根節點(beans)下的所有子節點，然后對這些節點進行解析。這里需要注意的即使是對節點的解析也有一個判斷語句。
主要來看一下delegate.isDefaultNamespace(ele),
public boolean isDefaultNamespace(String namespaceUri) {
//BEANS_NAMESPACE_URI = "http://www.springframework.org/schema/beans"
return (!StringUtils.hasLength(namespaceUri) || BEANS_NAMESPACE_URI.equals(namespaceUri));
}
也就是說beans命名空間下的標簽一個解析方法，而另外的標簽一個解析方法。
parseDefaultElement(Element, BeanDefinitionParserDelegate)
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {//import
importBeanDefinitionResource(ele);
}
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {//alias
processAliasRegistration(ele);
}
else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {//bean
processBeanDefinition(ele, delegate);
}
else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
// recurse
doRegisterBeanDefinitions(ele);
}
}
可以看到對於每一個標簽，都提供了一個方法來進行解析，最后一個方法用於對嵌套標簽進行解析，這里以bean標簽的解析為例。
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
//用於將一些屬性值塞進BeanDefinition中如lazy-init
//以及子節點中的值 如bean節點下的property
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
Holder對象也是spring中的一個系列性的對象，主要就是對某一些實例進行包裝，比如BeanDefinitionHolder就是對BeanDefinition進行包裝，主要就是持有BeanDefinition以及它的名稱和別名等(BeanDefinition為接口，無法提供名稱等屬性)。
public static void registerBeanDefinition(
BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)
throws BeanDefinitionStoreException {
String beanName = definitionHolder.getBeanName();
registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());
String[] aliases = definitionHolder.getAliases();
if (aliases != null) {
for (String alias : aliases) {
registry.registerAlias(beanName, alias);
}
}
}
接下來的BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry())可以算是我們本次目標最重要的一步了，前面所有的流程都是給這一步鋪墊。通過該方法將解析出來的BeanDefinition注冊到容器中，方便實例化。
方法接收兩個參數holder和registry，如果有看過我手寫系列的文章(IOC篇)應該知道，當時為了將bean定義和容器關聯起來以及為了將beanfactory的功能簡化，所以我們定義了一個BeanDefinitionRegistry接口用於將BeanDefinition注冊到容器中和從容器中取BeanDefinition，這里的registry功能也是一樣的。(BeanDefinitionRegistry被DefaultListableBeanFactory實現，而DefaultListableBeanFactory實際就是容器)
而且可以看到實際上這里也是通過beanName來區分BeanDefinition是否重復(實際上肯定是我仿的spring的(笑))，只不過為了運行名稱相同的BeanDefinition注冊提供了alias，之前在實現ioc時沒有實現這一步。
在processBeanDefinition方法的最后一步實際上是注冊了一個listener，在一個BeanDefinition被注冊后觸發，只不過上spring中實際觸發方法是一個空方法，如果我們需要在BeanDefinition注冊完成后做一些什么工作可以直接繼承EmptyReaderEventListener后實現componentRegistered(componentDefinition)方法即可。
到這里基本上關於BeanDefinition的加載就完成了，后面就是重復上面的流程加載多個配置文件。
小結
本節主要介紹了我關於學習spring源碼的一些方法，以及以spring的BeanDefinition的加載為例分析了其整體的流程，希望對大家能有所幫助。還要提的是spring源碼很復雜，如果只是開斷點一路調試下去肯定是不夠的，看的過程中需要多做筆記。由於該文章內容較多以及本人水平問題，文章中可能會存在錯誤，如果有可以指出來方便修改。