① [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 。
其主要方法執行如下:
② 怎麼樣才能打好JAVA的學習基礎
從大學到現在,我使用Java已經將近20年,日常也帶實習生,還在公司內部做training,所以可以分享下我的經驗,希望對你有用。
因為是在工作中培訓,就必然有兩個約束:實用、時間緊,因此就不能像大學那樣,把所有的知識點都面面俱到的講到。而只能挑基礎的,實用的,難理解的講。至於其他邊邊角角的知識,就一筆帶過。一則沒有時間,二則不常用,再則既使講了,學生印象也不深刻。總之一句話:「好鋼用在刀刃上」。
下面,就根據我的實踐,具體談下學習過程:
1.基礎知識
我學習java的時候,先是通讀了《Java編程思想》,然後是《Java核心技術》。當時這兩本書還不像現在這么厚,而剛才我把案頭的《Java核心技術》第9版翻了翻,上下兩冊已經1700多頁了,可想而知,如果要把它通讀一遍,且不說把所有的代碼都調通,就是當小說讀,估計也需要些時間。
但我現在教學依然首推《Java核心技術》,主要是體系完整,實例多,可操作性強。但對初學者,我一般是只講前6章,也就是下面的內容:
Java程序設計概述
Java程序設計環境
Java的基礎程序設計結構
對象與類
繼承
介面與內部類
就《Java核心技術》第9版來說,也就是到250頁為止,加把勁,1個月拿下完全沒問題。
因為你是自學,所以建議你一定要把其中的代碼都調通,課後的作業盡量去做。除此之外,還有兩點特別重要:
#.學習筆記
因為你是自學,不像在企業中學了就能夠實踐,印象自然特別深刻。而自學因為沒有實踐的及時反饋,所以記筆記就顯得特別重要。因為記筆記就像寫作一樣,是整理思路的絕佳方法。同時學習筆記也是你以後開發,面試的絕好資料。
學習編程,人跟人是不一樣的,別人覺得難理解的東西,對你卻不一定;而你覺得難理解的東西,別人可能又會覺得特簡單。而學習筆記就是自己專有的「難點手冊」,有點像高考時的「錯題本」,以後無論是在面試前,還是在日常工作中,隨時都可以翻出來看看,自是獲益匪淺。
#.分門別類保存demo
學習筆記是很好的文字資料,但編程界有句話說的特別好,所謂「no code, no text」,意思就是說:千言萬語都沒有一段代碼來的實在。
以我的經驗,在你在學習的過程中,就某個知識點,無論當時理解的多透徹,調試的多棒,只要時間一長,等到了實用的時候,肯定會碰到各種各樣的問題,一些看似簡單的東西,此時死活就是調不通,正所謂人到事中迷。這個時候,如果你手頭恰有運行良好的demo,打開參考一下(甚至直接拷貝過來),問題自然迎刃而解。而且因為這些demo都是你親手調試出來,印象自然特別深刻,一碰到問題,在腦子中自會立刻涌現。
所以說,在學習的過程,一定要善待你調通的demo,千萬不要用完了就扔,等後來碰到困難,想要用時卻找不到,追愧莫及。正確的做法就是把所有調通的demo,分門別類的保存起來,到時候查起來自是得心應手。
人都說「書到用時方恨少」,其實代碼也是這樣,所謂「demo用時方恨少」。
2.Spring
目前在Java EE開發中,Spring已經成為和Java核心庫一樣的基礎設施,所以說如果想成為一個合格的Java程序員,Spring肯定繞不開。另一方面,如果掌握了Spring體系,Java基本上就算入門了,就有能力進行一些實用級的開發了。
但Spring本身也是日漸復雜,衍生項目越來越多,但最最核心的概念依舊是IOC和AOP,掌握了這兩個概念,再把Spring MVC學會,再學習其他的衍生項目就會平滑很多。
順便在這里說一下,如果你現在也在學習Java,在入門學習Java的過程當中,有遇見任何關於學習方法,學習路線,學習效率等方面的問題,你可以申請加入我的Java新手學習交流qun:前面輸入是:三九零,最後輸入是:七八一四。裡面聚集了很多正在學習Java技術的初學者,其中不乏也有正在從事Java技術開發的大牛,裙文件裡面還有我做Java技術這段時間整理的一些學習手冊,面試題,開發工具,PDF文檔書籍教程,需要的話都可以自行來獲取下載。
同時,因為Spring本身就應用了許多優雅的設計理念,所以學習Spring的過程,也是加強Java基礎知識學習的過程。因此等你掌握了Spring,原來很多你理解不透徹的Java特性,此時就會恍然大悟,包括介面、抽象類等。
我學習Spring,讀的第一本書是《Spring實戰》,坦率的說,書很一般,但市面上比它好的書,我卻沒有遇到過。還有一本《Spring源碼深度解析》也不錯,對Spring的設計理念講的尤其透徹,雖然整本書讀起來有些艱澀,但前幾章卻生動有趣,也是整本書的精華。所以建議你在學習Spring之前,先把該書的前幾章通讀一下,然後再回過頭來學習《Spring實戰》會順利很多。
以我經驗,要學透Spring,終極的方法還是閱讀源碼(我當時就是這么乾的),待把Spring的核心源碼通讀了,人就真的自由了(所謂無真相不自由),不僅是對Spring,而是對整個Java體系。以後再遇到其他框架,大概一眼就能看出其中的脈絡,所謂到了「看山不是山」的境界。但這都是後話,可以作為以後你努力的方向。
和學習Java基礎知識一樣,學習Spring也一定要記筆記,一定要分門別類保存demo。
老實說,Spring對初學者不算簡單,因此最好能有個好老師帶一下,不用太長時間,2個課時即可,然後就是在你遇到大的困難時,能及時的點撥下。
以我的經驗,要初步掌握Spring,大概需要1到1個半月的時間。
3.其他知識
Spring是Java編程的基礎設施,但真要進入到實際項目的開發,還有些東西繞不過,包括 MySql,Mybatis,Redis,Servlet等,但如果你經過Spring的洗禮,這些東西相對就簡單多了,以我的經驗,1個月的時間足夠了。
4.實踐
學習Java,光學不練肯定是不行的。但因為是自學,所以就沒有實際的產品讓你練手,但也沒有關系,誰大學還沒有做過畢業設計呢?以我的經驗,大家最愛的「學生管理系統」依舊是個很好的練手系統。
別看「學生管理系統」邏輯簡單,但麻雀雖小五臟俱全,其中資料庫設計、Mybatis,Spring、SpringMVC,Servlet、Tomcat一個都不缺,絕對的練手好伴侶。
還有,雖然你的學習重點在Java,因為要做一個完整的demo,前端的配合肯定少不了。因此就免少不了要學一些簡單的JS、HTML知識,但因為前端本就是個很大的topic,所以一定要控制好邊界,千萬不要顧此失彼。就「學生管理系統」來說,在前端上,只要實現一個包含table、textbox、button,能發送REST請求到server,能實現學生的「增刪改查」的簡單頁面即可。
作為一個練手項目,目標就是把Java的主要技能點串起來,所以自不求盡善盡美(也不可能),所以1個月時間足夠了。
最後
按照上面的過程,4個月的時間剛剛好。當然Java的體系是很龐大的,還有很多更高級的技能需要掌握,但不要著急,這些完全可以放到以後工作中邊用別學。
學習編程就是一個由混沌到有序的過程,所以你在學習過程中,如果一時碰到理解不了的知識點,大可不必沮喪,更不要氣餒,這都是正常的不能在正常的事情了,不過是「人同此心,心同此理」的暫時而已。
在日常的教學中,我常把下面這句話送給學員們,今天也把它送給你:
「道路是曲折的,前途是光明的!」
祝你好運!
③ 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.准備工作:在官網上下載了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);
}