⑴ [Spring boot源碼解析] 2 啟動流程分析
在了解 Spring Boot 的啟動流程的時候，我們先看一下一個Spring Boot 應用是如何啟動的，如下是一個簡單的 SpringBoot 程序，非常的簡潔，他是如何做到的呢，我們接下來就將一步步分解。
我們追蹤 SpringApplication.run() 方法，其實最終它主要的邏輯是新建一個 SpringApplication ，然後調用他的 run 方法，如下:
我們先來看一下創建 SpringApplication 的方法：
在將Main class 設置 primarySources 後，調用了 WebApplicationType.deceFromClasspath() 方法，該方法是為了檢查當前的應用類型，並設置給 webApplicationType 。 我們進入 deceFromClasspath 方法 ：
這里主要是通過類載入器判斷是否存在 REACTIVE 相關的類信息，假如有就代表是一個 REACTIVE 的應用，假如不是就檢查是否存在 Servelt 和 ，假如都沒有，就代表應用為非 WEB 類應用，返回 NONE ，默認返回 SERVLET 類型，我們這期以我們目前最常使用的 SERVLET 類型進行講解，所以我們在應用中引入了 spring-boot-starter-web 作為依賴：
他會包含 Spring-mvc 的依賴，所以就包含了內嵌 tomcat 中的 Servlet 和 Spring-web 中的 ,因此返回了 SERVLET 類型。
回到剛才創建 SpringApplication 的構建方法中，我們設置完成應用類型後，就尋找所有的 Initializer 實現類，並設置到 SpringApplication 的 Initializers 中，這里先說一下 getSpringFactoriesInstances 方法，我們知道在我們使用 SpringBoot 程序中，會經常在 META-INF/spring.factories 目錄下看到一些 EnableAutoConfiguration ，來出發 config 類注入到容器中，我們知道一般一個 config 類要想被 SpringBoot 掃描到需要使用 @CompnentScan 來掃描具體的路徑，對於 jar 包來說這無疑是非常不方便的，所以 SpringBoot 提供了另外一種方式來實現，就是使用 spring.factories ，比如下面這個，我們從 Springboot-test 中找到的例子，這里先定義了一個ExampleAutoConfiguration，並加上了 Configuration 註解：
然後在 spring.factories 中定義如下：
那這種方式是怎麼實現的你，這就要回到我們剛才的方法 getSpringFactoriesInstances :
我們先來看一下傳入參數，這里需要注意的是 args，這個是初始化對應 type 的時候傳入的構造參數，我們先看一下 SpringFactoriesLoader#loadFactoryNames 方法：
首先是會先檢查緩存，假如緩存中存在就直接返回，假如沒有就調用 classLoader#getResources 方法，傳入 META-INF/spring.factories ，即獲取所有 jar 包下的對應文件，並封裝成 UrlResource ，然後使用 PropertiesLoaderUtils 將這些信息讀取成一個對一對的 properties，我們觀察一下 spring.factories 都是按 properties 格式排版的，假如有多個就用逗號隔開，所以這里還需要將逗號的多個類分隔開來，並加到 result 中，由於 result 是一個 LinkedMultiValueMap 類型，支持多個值插入，最後放回緩存中。最終完成載入 META-INF/spring.factories 中的配置，如下：
我們可以看一下我們找到的 initializer 有多少個：
在獲取到所有的 Initializer 後接下來是調用 方法進行初始化。
這里的 names 就是我們上面通過類載入器載入到的類名，到這里會先通過反射生成 class 對象，然後判斷該類是否繼承與 ApplicationContextInitializer ，最後通過發射的方式獲取這個類的構造方法，並調用該構造方法，傳入已經定義好的構造參數，對於 ApplicationContextInitializer 是無參的構造方法，然後初始化實例並返回，回到原來的方法，這里會先對所有的 ApplicationContextInitializer 進行排序，調用 #sort(instances) 方法，這里就是根據 @Order 中的順序進行排序。
接下來是設置 ApplicationListener ，我們跟進去就會發現這里和上面獲取 ApplicationContextInitializer 的方法如出一轍，最終會載入到如圖的 15 個 listener （這里除了 外，其他都是 SpringBoot 內部的 Listener）:
在完成 SpringApplication 對象的初始化後，我們進入了他的 run 方法，這個方法幾乎涵蓋了 SpringBoot 生命周期的所有內容，主要分為九個步驟，每一個步驟這里都使用註解進行標識：
主要步驟如下：
第一步：獲取 SpringApplicationRunListener， 然後調用他的 staring 方法啟動監聽器。
第二步：根據 SpringApplicationRunListeners以及參數來准備環境。
第三步：創建 Spring 容器。
第四步：Spring 容器的前置處理。
第五步：刷新 Spring 容器。
第六步： Spring 容器的後置處理器。
第七步：通知所有 listener 結束啟動。
第八步：調用所有 runner 的 run 方法。
第九步：通知所有 listener running 事件。
我們接下來一一講解這些內容。
我們首先看一下第一步，獲取 SpringApplicationRunListener :
這里和上面獲取 initializer 和 listener 的方式基本一致，都是通過 getSpringFactoriesInstances , 最終只找到一個類就是： org.springframework.boot.context.event.EventPublishingRunListener ，然後調用其構造方法並傳入產生 args , 和 SpringApplication 本身:
我們先看一下構造函數，首先將我們獲取到的 ApplicationListener 集合添加到initialMulticaster 中， 最後都是通過操作 來進行廣播，我，他繼承於 ，我們先看一下他的 addApplicationListener 方法：
我們可以看出，最後是放到了 applicationListenters 這個容器中。他是 defaultRetriever 的成員屬性， defaultRetriever 則是 的私有類，我們簡單看一下這個類：
我們只需要看一下這里的 getApplicationListeners 方法，它主要是到 beanFactory 中檢查是否存在多的 ApplicationListener 和舊的 applicationListeners 組合並返回，接著執行 listener 的 start 方法，最後也是調用了 的 multicastEvent 查找支持對應的 ApplicationEvent 類型的通知的 ApplicationListener 的 onApplicationEvent 方法 ,這里除了會:
篩選的方法如下，都是調用了對應類型的 supportsEventType 方法 ：
如圖，我們可以看到對 org.springframework.boot.context.event.ApplicationStartingEvent 感興趣的有5個 Listener
環境准備的具體方法如下：
首先是調用 getOrCreateEnvironment 方法來創建 environment ，我們跟進去可以發現這里是根據我們上面設置的環境的類型來進行選擇的，當前環境會創建 StandardServletEnvironment
我們先來看一下 StandardServletEnvironment 的類繼承關系圖，我們可以看出他是繼承了 AbstractEnvironment ：
他會調用子類的 customizePropertySources 方法實現,首先是 StandardServletEnvironment 的實現如下，他會添加 servletConfigInitParams , servletContextInitParams , jndiProperties 三種 properties，當前調試環境沒有配置 jndi properties，所以這里不會添加。接著調用父類的 customizePropertySources 方法，即調用到了 StandardEnvironment 。
我們看一下 StandardEnvironment#customizePropertySources 方法，與上面的三個 properties 創建不同，這兩個是會進行賦值的，包括系統環境變數放入 systemEnvironment 中，jvm 先關參數放到 systemProperties 中：
這里會添加 systemEnvironment 和 systemProperties 這兩個 properties，最終拿到的 properties 數量如下 4個：
在創建完成 Environment 後，接下來就到了調用 configureEnvironment 方法：
我們先看一下 configurePropertySources 方法，這里主要分兩部分，首先是查詢當前是否存在 defaultProperties ，假如不為空就會添加到 environment 的 propertySources 中，接著是處理命令行參數，將命令行參數作為一個 CompositePropertySource 或則 添加到 environment 的 propertySources 裡面，
接著調用 ConfigurationPropertySources#attach 方法,他會先去 environment 中查找 configurationProperties , 假如尋找到了，先檢查 configurationProperties 和當前 environment 是否匹配，假如不相等，就先去除，最後添加 configurationProperties 並將其 sources 屬性設置進去。
回到我們的 prepareEnvironment 邏輯，下一步是通知觀察者，發送 事件，調用的是 SpringApplicationRunListeners#environmentPrepared 方法，最終回到了 #multicastEvent 方法，我們通過 debug 找到最後對這個時間感興趣的 Listener 如下：
其主要邏輯如下：
這個方法最後載入了 PropertySourceLoader , 這里主要是兩種，一個是用於 Properties 的，一個是用於 YAML 的如下：
其中 apply 方法主要是載入 defaultProperties ，假如已經存在，就進行替換，而替換的目標 PropertySource 就是 load 這里最後的一個 consumer 函數載入出來的，這里列一下主要做的事情：
1、載入系統中設置的所有的 Profile 。
2、遍歷所有的 Profile ，假如是默認的 Profile ， 就將這個 Profile 加到 environment 中。
3、調用load 方法，載入配置，我們深入看一下這個方法：
他會先調用 getSearchLocations 方法，載入所有的需要載入的路徑，最終有如下路徑：
其核心方法是遍歷所有的 propertySourceLoader ，也就是上面載入到兩種 propertySourceLoader ,最紅 loadForFileExtension 方法，載入配置文件，這里就不展開分析了，說一下主要的作用，因為每個 propertySourceLoader 都有自己可以載入的擴展名，默認擴展名有如下四個 properties, xml, yml, yaml，所以最終拿到文件名字，然後通過 - 拼接所有的真實的名字，然後加上路徑一起載入。
接下來，我們分析 BackgroundPreinitializer ,這個方法在接收 ApplicationPrepareEnvironment 事件的時候真正調用了這份方法：
1、 ConversionServiceInitializer 主要負責將包括 日期，貨幣等一些默認的轉換器注冊到 formatterRegistry 中。
2、 ValidationInitializer 創建 validation 的匹配器。
3、 MessageConverterInitializer 主要是添加了一些 http 的 Message Converter。
4、 JacksonInitializer 主要用於生成 xml 轉換器的。
接著回到我們將的主體方法， prepareEnvironment 在調用完成 listeners.environmentPrepared(environment) 方法後，調用 bindToSpringApplication(environment) 方法，將 environment 綁定到 SpirngApplication 中。
接著將 enviroment 轉化為 StandardEnvironment 對象。
最後將 configurationProperties 加入到 enviroment 中， configurationProperties 其實是將 environment 中其他的 PropertySource 重新包裝了一遍，並放到 environment 中，這里主要的作用是方便 進行解析。
它主要是檢查是否存在 spring.beaninfo.ignore 配置，這個配置的主要作用是設置 javaBean 的內省模式，所謂內省就是應用程序在 Runtime 的時候能檢查對象類型的能力，通常也可以稱作運行時類型檢查，區別於反射主要用於修改類屬性，內省主要用戶獲取類屬性。那麼我們什麼時候會使用到內省呢，java主要是通過內省工具 Introspector 來完成內省的工作，內省的結果通過一個 Beaninfo 對象返回，主要包括類的一些相關信息，而在 Spring中，主要是 BeanUtils#Properties 會使用到，Spring 對內省機制還進行了改進，有三種內省模式，如下圖中紅色框框的內容，默認情況下是使用 USE_ALL_BEANINFO。假如設置為true，就是改成第三中 IGNORE_ALL_BEANINFO
首先是檢查 Application的類型，然後獲取對應的 ApplicationContext 類，我們這里是獲取到了 org.springframework.boot.web.servlet.context. 接著調用 BeanUtils.instantiateClass(contextClass); 方法進行對象的初始化。
最終其實是調用了 的默認構造方法。我們看一下這個方法做了什麼事情。這里只是簡單的設置了一個 reader 和一個 scanner，作用於 bean 的掃描工作。
我們再來看一下這個類的繼承關系
這里獲取 ExceptionReporter 的方式主要還是和之前 Listener 的方式一致,通過 getSpringFactoriesInstances 來獲取所有的 SpringBootExceptionReporter 。
其主要方法執行如下：
⑵ Spring Tx源碼解析(二)
上一篇 我們介紹了 spring-tx 中的底層抽象，本篇我們一起來看看圍繞這些抽象概念 spring-tx 是如何打造出聲明式事務的吧。籠統的說， spring-tx-5.2.6.RELEASE 的實現主要分為兩個部分：
這兩部分彼此獨立又相互成就，並且每個部分都有著大量的源碼支撐，本篇我們先來分析 spring-tx 中的AOP部分吧。
EnableTransactionManagement 註解想必大家都很熟悉了，它是啟用 Spring 中注釋驅動的事務管理功能的關鍵。
EnableTransactionManagement 註解的主要作用是向容器中導入 ，至於註解中定義的幾個屬性在 Spring AOP源碼解析 中有過詳細分析，這里就不再贅述了。
由於我們並沒有使用 AspectJ ，因此導入容器的自然是 這個配置類。
這個配置類的核心是向容器中導入一個類型為 的Bean。這是一個 PointcutAdvisor ，它的 Pointcut 是 ， Advice 是 TransactionInterceptor 。
利用 TransactionAttributeSource 解析 @Transactional 註解的能力來選取標注了 @Transactional 註解的方法，而 TransactionInterceptor 則根據應用提出的需求（來自對 @Transactional 註解的解析）將方法增強為事務方法，因此 可以識別出那些標注了 @Transactional 註解的方法，為它們應用上事務相關功能。
TransactionInterceptor 能對方法進行增強，但是它卻不知道該如何增強，比如是為方法新開一個獨立事務還是沿用已有的事務？什麼情況下需要回滾，什麼情況下不需要？必須有一個『人』告訴它該如何增強，這個『人』便是 TransactionAttributeSource 。
@Transactional 註解定義了事務的基礎信息，它表達了應用程序期望的事務形態。 TransactionAttributeSource 的主要作用就是解析 @Transactional 註解，提取其屬性，包裝成 TransactionAttribute ，這樣 TransactionInterceptor 的增強便有了依據。
前面我們已經見過， spring-tx 使用 來做具體的解析工作，其父類 定義了解析 TransactionAttribute 的優先順序，核心方法是 computeTransactionAttribute(...) 。
默認只解析 public 修飾的方法，這也是導致 @Transactional 註解失效的一個原因，除此之外它還實現了父類中定義的兩個模板方法：
同時為了支持 EJB 中定義的 javax.ejb.TransactionAttribute 和 JTA 中定義的 javax.transaction.Transactional 註解， 選擇將實際的提取工作代理給 TransactionAnnotationParser 。Spring 提供的 @Transactional 註解由 進行解析。
的源碼還是很簡單的，它使用 AnnotatedElementUtils 工具類定義的 find 語義來獲取 @Transactional 註解信息。 RuleBasedTransactionAttribute 中 rollbackOn(...) 的實現還是挺有意思的，其它的都平平無奇。
RollbackRuleAttribute 是用來確定在發生特定類型的異常（或其子類）時是否應該回滾，而 NoRollbackRuleAttribute 繼承自 RollbackRuleAttribute ，但表達的是相反的含義。 RollbackRuleAttribute 持有某個異常的名稱，通過 getDepth(Throwable ex) 演算法來計算指定的 Throwable 和持有的異常在繼承鏈上的距離。
程序猿只有在拿到需求以後才能開工， TransactionInterceptor 也一樣，有了 TransactionAttributeSource 之後就可以有依據的增強了。觀察類圖， TransactionInterceptor 實現了 MethodInterceptor 介面，那麼自然要實現介面中的方法：
可以看到， TransactionInterceptor 本身是沒有實現任何邏輯的，它更像一個適配器。這樣分層以後， TransactionAspectSupport 理論上就可以支持任意類型的 Advice 而不只是 MethodInterceptor 。實現上 TransactionAspectSupport 確實也考慮了這一點，我們馬上就會看到。
invokeWithinTransaction(...) 的流程還是非常清晰的：
第一步前文已經分析過了，我們來看第二步。
TransactionInfo 是一個非常簡單的類，我們就不費什麼筆墨去分析它了。接著看第三步，這一步涉及到兩個不同的操作——提交或回滾。
至此， TransactionInterceptor 於我們而言已經沒有任何秘密了。
本篇我們一起分析了 spring-tx 是如何通過 spring-aop 的攔截器將普通方法增強為事務方法的，下篇就該說道說道 PlatformTransactionManager 抽象下的事務管理細節啦，我們下篇再見~~
⑶ 急求！spring源碼怎麼運行，怎麼看
1、在你的MyEclipse上安裝一個反編譯插件，這樣，所有的class文件都能看到它的源代碼
2、建議你用jad MyEclipse反編譯插件。
3、要相應jar包，我上傳給你了。
4、MyEclipse10是在(MyEclipse安裝目錄)\MyEclipse 10\dropins下建立一個文件夾jad，可能myeclipse的版本不一樣，路徑會有所區別。在新建的jad文件夾中新建兩個文件夾：plugins,features,然後將下載來的jar放入到plugins文件夾中。
5、還要用的jad.exe，在上面的壓縮包里也有。把這個最好放到你的jdk的bin目錄下。
6、打開：Window->Preferences->Java->JadClipse.
1）Path to decompiler，這里設置反編譯工具jad的全路徑名，我的是
D:\Program Files\Java\jdk1.7.0\bin\jad.exe
2）Directory for temporary files，這里設置臨時文件路徑。
這個不用管。就默認的哪個樣子就可以。
7、注意：安裝完成後，myeclipse沒有自動將JadClipse Class File Viewer設置成class文件的預設打開方式，設置方法如下：
在Eclipse的Windows—> Perference—>General->Editors->File Associations中修改「*.class」默認關聯的編輯器為「JadClipse Class File Viewer」。
9、設置完成，找一個jar包中的*.class文件，myeclipse將自動反編譯
⑷ 如何查看spring源碼
1.准備工作：在官網上下載了Spring源代碼之後，導入Eclipse，以方便查詢。
2.打開我們使用Spring的項目工程，找到Web.xml這個網站系統配置文件，在其中找到Spring的初始化信息：
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
由配置信息可知，我們開始的入口就這里ContextLoaderListener這個監聽器。
在源代碼中我們找到了這個類，它的定義是：
public class ContextLoaderListener extends ContextLoader
implements ServletContextListener {
…
/**
* Initialize the root web application context.
*/
public void contextInitialized(ServletContextEvent event) {
this.contextLoader = createContextLoader();
if (this.contextLoader == null) {
this.contextLoader = this;
}
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
...
}
該類繼續了ContextLoader並實現了監聽器，關於Spring的信息載入配置、初始化便是從這里開始了，具體其他閱讀另外寫文章來深入了解。
二、關於IOC和AOP
關於Spring IOC 網上很多相關的文章可以閱讀，那麼我們從中了解到的知識點是什麼？
1）IOC容器和AOP切面依賴注入是Spring是核心。
IOC容器為開發者管理對象之間的依賴關系提供了便利和基礎服務，其中Bean工廠（BeanFactory）和上下文（ApplicationContext）就是IOC的表現形式。BeanFactory是個介面類，只是對容器提供的最基本服務提供了定義，而DefaultListTableBeanFactory、XmlBeanFactory、ApplicationContext等都是具體的實現。
介面：
public interface BeanFactory {
//這里是對工廠Bean的轉義定義，因為如果使用bean的名字檢索IOC容器得到的對象是工廠Bean生成的對象，
//如果需要得到工廠Bean本身，需要使用轉義的名字來向IOC容器檢索
String FACTORY_BEAN_PREFIX = "&";
//這里根據bean的名字，在IOC容器中得到bean實例，這個IOC容器就象一個大的抽象工廠，用戶可以根據名字得到需要的bean
//在Spring中，Bean和普通的JAVA對象不同在於：
//Bean已經包含了我們在Bean定義信息中的依賴關系的處理，同時Bean是已經被放到IOC容器中進行管理了，有它自己的生命周期
Object getBean(String name) throws BeansException;
//這里根據bean的名字和Class類型來得到bean實例，和上面的方法不同在於它會拋出異常：如果根名字取得的bean實例的Class類型和需要的不同的話。
Object getBean(String name, Class requiredType) throws BeansException;
//這里提供對bean的檢索，看看是否在IOC容器有這個名字的bean
boolean containsBean(String name);
//這里根據bean名字得到bean實例，並同時判斷這個bean是不是單件，在配置的時候，默認的Bean被配置成單件形式,如果不需要單件形式，需要用戶在Bean定義信息中標注出來，這樣IOC容器在每次接受到用戶的getBean要求的時候，會生成一個新的Bean返回給客戶使用 - 這就是Prototype形式
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
//這里對得到bean實例的Class類型
Class getType(String name) throws NoSuchBeanDefinitionException;
//這里得到bean的別名，如果根據別名檢索，那麼其原名也會被檢索出來
String[] getAliases(String name);
}
實現：
XmlBeanFactory的實現是這樣的：
public class XmlBeanFactory extends DefaultListableBeanFactory {
//這里為容器定義了一個默認使用的bean定義讀取器，在Spring的使用中，Bean定義信息的讀取是容器初始化的一部分，但是在實現上是和容器的注冊以及依賴的注入是分開的，這樣可以使用靈活的 bean定義讀取機制。
private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this);
//這里需要一個Resource類型的Bean定義信息，實際上的定位過程是由Resource的構建過程來完成的。
public XmlBeanFactory(Resource resource) throws BeansException {
this(resource, null);
}
//在初始化函數中使用讀取器來對資源進行讀取，得到bean定義信息。這里完成整個IOC容器對Bean定義信息的載入和注冊過程
public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws
BeansException {
super(parentBeanFactory);
this.reader.loadBeanDefinitions(resource);
}
⑸ 如何閱讀Spring源碼
如果你是一名JAVA開發人員，你一定用過Spring Framework。 作為一款非常經典的開源框架，從2004年發布的1.0版本到現在的5.0版本，已經經歷了16年的洗禮。可以說這是一款老框架了(當然這里的老僅僅指的是時間).
在這16年中，涌現了很多技術，大多曇花一現，但Spring經久不衰。隨著技術的演進與版本的更迭，Spring框架總能不落後於技術的潮流，總能緊跟時代的步伐。
究竟是什麼樣的設計可以讓它經久不衰？究竟它體現了一種什麼樣的設計哲學？
閱讀Spring源碼之前的准備：
熟練使用Spring框架：只有當你熟練了，閱讀其源碼水到渠成
扎實的JAVA基礎：如果你不具備扎實的JAVA基礎，那麼請不要輕易嘗試，否則只是浪費寶貴的時間。那麼怎麼樣才算是基礎扎實呢？此處暫列出一些基本精通的東西，如集合框架(數據結構的實現),多線程技術(線程池、線程安全、並發容器等)，反射與註解（Spring中大量的使用到了反射），面向對象(面向對象不僅僅指的是對象抽象，還包括對象集成、多態等各種機制)以及JAVA的一些其他高級特性(如基於java介面的動態代理等)
設計模式：Spring中大量的使用了各種設計模式已提高其健壯性，因此對於設計模式需要一些深刻的理解.
繪制UML能力：在閱讀的時候，肯定是要探究其核心對象之間的關系，而UML類圖不失為一種非常直觀的方式.
激情與毅力：學習一件事物的時候激情是非常重要的，但毅力才是體現成敗的關鍵.
如何開始閱讀：
了解其整體架構與核心概念以便建立Spring的模型
從框架入口開始抽絲剝繭，理解其每一個核心概念以及作用，並將這些核心技術點融匯起來
探究每一個核心的實現細節（UML圖、跑單元測試用例、DEBUG，體悟）
以上，僅為我自己閱讀源碼的方式。
工作中一直得益於Spring帶來的便利，對於Spring的使用應該很是熟練了，但對於它的設計理念與整體架構卻沒有一個非常清晰明了的認知。
很久之前就想過要閱讀Spring的源碼了，但一直是無從下手的狀態。也曾嘗試著debug去強行閱讀， 但不了解的地方甚多。 於是反省自己java的基礎，反省自己閱讀的方式。
經過一段很長時間的查缺補漏， 終於可以順利的去閱讀Spring的源碼了，所以在此處加以記錄。
⑹ 怎麼閱讀Spring源碼
學習源碼是一件非常耗時費力的事情，需要有足夠的時間和持久的耐心，下面是我閱讀郝佳老師的《Spring源碼深度解析》所做的記錄，書中以Spring3.2講解，使用jdk1.7。
准備工作
1. 安裝github：現在spring源代碼都在github管理，所以首先需要下載githup，下；
2. 安裝gradle構建工具： 下載完後進行解壓到任意盤符，然後增加環境變數GRADLE_HOME，並在環境變數bin中增加%GRADLE_HOME%/bin，打開DOS窗口，運行gradle -v，出現版本號等信息，表示安裝成功；
3. 下載Spring源碼：首先打開git shell，切換到你的工作目錄，然後輸入以下命令：git clone git://github.com/SpringSource/Spring-framework.git，後面一串是源碼下載地址。大概半小時的樣子，就可以下載完成，這時候在你的工作目錄中就會出現Spring-framework的目錄，裡面有Spring各組件的源碼包；
4. 構建導入：下載下來的代碼不能直接導入Eclipse，要先轉換成Eclipse能讀取的形式。因為所有組件都會依賴spring-core，所有我們首先要轉換Spring-core工程，在命令窗口切換到Spring-core工程，運行gradle cleanidea eclipse命令，我們會看到開始下載工程所依賴的jar包，幾分鍾後執行完畢，再來看Spring-core文件夾，多了.classpath、.project等文件，這是Eclipse工程所必須的，然後可以把他導入到eclipse。因為大部分Spring組件都會用到 spring-beans、spring-context、spring-aop，而他們又依賴spring-expression、spring-instrument，所以我們乾脆先把這些工程都進行轉換並導入eclipse。
⑺ Spring源碼分析（一） XmlWebApplicationContext
spring是大家都會用的ioc框架，但是要真的了解spring還是需要好好研究一下才行，為此看了一些spring源碼，所以開始寫spring源碼分析的文章，這個是第一篇，先從ioc容器的啟動開始。
我們都知道,spring的ioc容器的最基本的介面就是BeanFactory,而ApplicationContext是包含了BeanFactory的所有信息，所以ioc容器在啟動的時候就是從AbstractApplicationContext的refresh方法開始的
具體的啟動流程就不說了，主要是這里有一個onRefresh方法,我們來看這個類，在這個類中覆寫了onRefresh方法
這是什麼東西？別急，我們來看看themeSource是什麼。
還是不太明白？那我們來看看的結構
原來ThemeSource是一個介面,而則實現了這個介面,在onRefresh把自己傳進去了，好吧，這塊就先看到這里。
我們直接到XmlWebApplicationContext這個類里,我們發現類有一個方法loadBeanDefinitions,而XmlWebApplicationContext覆寫了這個方法,我們來看看XmlWebApplicationContext是怎麼實現的
這里我們要介紹ioc容器里的一個介面BeanDefinitionReader,而XmlBeanDefinitionReader是BeanDefinitionReader的一個實現類,負責對xml的配置文件進行讀取,並放到ioc容器中。當讀取完配置文件後，通過loadBeanDefinitions方法將bean注冊到ioc容器中。
至此，ioc容器就啟動完成。
XmlWebApplicationContext的分析就到這里了。