在一開始學習 Spring 的時候嚷辅，我們就接觸 IoC 了簿姨，作為 Spring 第一個最核心的概念，我們在解讀它源碼之前一定需要對其有深入的認識簸搞，本篇為【死磕 Spring】系列博客的第一篇博文扁位，主要介紹 IoC 基本概念和各個組件深寥。
IOC 理論
IoC 全稱為 Inversion of Control，翻譯為 “控制反轉”贤牛，它還有一個別名為 DI（Dependency Injection）,即依賴注入惋鹅。
如何理解“控制反轉”好呢？理解好它的關鍵在于我們需要回答如下四個問題：
- 誰控制誰
- 控制什么
- 為何是反轉
- 哪些方面反轉了
在回答這四個問題之前殉簸，我們先看 IOC 的定義：
所謂 IOC 闰集，就是由 Spring IOC 容器來負責對象的生命周期和對象之間的關系
上面這句話是整個 IoC 理論的核心。如何來理解這句話般卑？我們引用一個例子來走闡述（看完該例子上面四個問題也就不是問題了）武鲁。
已找女朋友為例（對于程序猿來說這個值得探究的問題）。一般情況下我們是如何來找女朋友的呢蝠检？首先我們需要根據(jù)自己的需求（漂亮沐鼠、身材好、性格好）找一個妹子叹谁，然后到處打聽她的興趣愛好饲梭、微信、電話號碼焰檩，然后各種投其所好送其所要憔涉，最后追到手。如下：
/**
* 年輕小伙子
*/
public class YoungMan {
private BeautifulGirl beautifulGirl;
YoungMan(){
// 可能你比較牛逼析苫，指腹為婚
// beautifulGirl = new BeautifulGirl();
}
public void setBeautifulGirl(BeautifulGirl beautifulGirl) {
this.beautifulGirl = beautifulGirl;
}
public static void main(String[] args){
YoungMan you = new YoungMan();
BeautifulGirl beautifulGirl = new BeautifulGirl("你的各種條件");
beautifulGirl.setxxx("各種投其所好");
// 然后你有女票了
you.setBeautifulGirl(beautifulGirl);
}
}
這就是我們通常做事的方式兜叨，如果我們需要某個對象，一般都是采用這種直接創(chuàng)建的方式(new BeautifulGirl())衩侥，這個過程復雜而又繁瑣国旷，而且我們必須要面對每個環(huán)節(jié)，同時使用完成之后我們還要負責銷毀它茫死，在這種情況下我們的對象與它所依賴的對象耦合在一起跪但。
其實我們需要思考一個問題？我們每次用到自己依賴的對象真的需要自己去創(chuàng)建嗎璧榄？我們知道特漩，我們依賴對象其實并不是依賴該對象本身，而是依賴它所提供的服務骨杂，只要在我們需要它的時候涂身，它能夠及時提供服務即可，至于它是我們主動去創(chuàng)建的還是別人送給我們的搓蚪，其實并不是那么重要蛤售。再說了，相比于自己千辛萬苦去創(chuàng)建它還要管理、善后而言悴能，直接有人送過來是不是顯得更加好呢揣钦？
這個給我們送東西的“人” 就是 IoC，在上面的例子中漠酿，它就相當于一個婚介公司冯凹，作為一個婚介公司它管理著很多男男女女的資料，當我們需要一個女朋友的時候炒嘲，直接跟婚介公司提出我們的需求宇姚，婚介公司則會根據(jù)我們的需求提供一個妹子給我們，我們只需要負責談戀愛夫凸，生猴子就行了浑劳。你看，這樣是不是很簡單明了夭拌。
誠然魔熏，作為婚介公司的 IoC 幫我們省略了找女朋友的繁雜過程咖杂，將原來的主動尋找變成了現(xiàn)在的被動接受（符合我們的要求）篱瞎，更加簡潔輕便。你想啊瞎暑，原來你還得鞍馬前后献烦，各種巴結滓窍，什么東西都需要自己去親力親為卖词，現(xiàn)在好了巩那，直接有人把現(xiàn)成的送過來，多么美妙的事情啊此蜈。所以即横，簡單點說，IoC 的理念就是讓別人為你服務裆赵，如下圖（摘自Spring揭秘）：
在沒有引入 IoC 的時候东囚，被注入的對象直接依賴于被依賴的對象，有了 IoC 后战授，兩者及其他們的關系都是通過 Ioc Service Provider 來統(tǒng)一管理維護的页藻。被注入的對象需要什么，直接跟 IoC Service Provider 打聲招呼植兰，后者就會把相應的被依賴對象注入到被注入的對象中份帐，從而達到 IOC Service Provider 為被注入對象服務的目的。所以 IoC 就是這么簡單楣导！原來是需要什么東西自己去拿废境，現(xiàn)在是需要什么東西讓別人（IOC Service Provider）送過來
現(xiàn)在在看上面那四個問題，答案就顯得非常明顯了:
- 誰控制誰：在傳統(tǒng)的開發(fā)模式下，我們都是采用直接 new 一個對象的方式來創(chuàng)建對象噩凹，也就是說你依賴的對象直接由你自己控制巴元，但是有了 IOC 容器后，則直接由 IoC 容器來控制驮宴。所以“誰控制誰”逮刨，當然是 IoC 容器控制對象。
- 控制什么：控制對象堵泽。
- 為何是反轉：沒有 IoC 的時候我們都是在自己對象中主動去創(chuàng)建被依賴的對象禀忆，這是正轉。但是有了 IoC 后落恼，所依賴的對象直接由 IoC 容器創(chuàng)建后注入到被注入的對象中箩退，依賴的對象由原來的主動獲取變成被動接受，所以是反轉佳谦。
- 哪些方面反轉了：所依賴對象的獲取被反轉了戴涝。
妹子有了，但是如何擁有妹子呢钻蔑？這也是一門學問啥刻。
- 可能你比較牛逼，剛剛出生的時候就指腹為婚了咪笑。
- 大多數(shù)情況我們還是會考慮自己想要什么樣的妹子可帽，所以還是需要向婚介公司打招呼的。
- 還有一種情況就是窗怒，你根本就不知道自己想要什么樣的妹子映跟，直接跟婚介公司說，我就要一個這樣的妹子扬虚。
所以努隙，IOC Service Provider 為被注入對象提供被依賴對象也有如下幾種方式：構造方法注入、stter方法注入辜昵、接口注入荸镊。
構造器注入
構造器注入，顧名思義就是被注入的對象通過在其構造方法中聲明依賴對象的參數(shù)列表堪置，讓外部知道它需要哪些依賴對象躬存。
YoungMan(BeautifulGirl beautifulGirl){
this.beautifulGirl = beautifulGirl;
}
構造器注入方式比較直觀，對象構造完畢后就可以直接使用舀锨，這就好比你出生你家里就給你指定了你媳婦岭洲。
setter 方法注入
對于 JavaBean 對象而言，我們一般都是通過 getter 和 setter 方法來訪問和設置對象的屬性雁竞。所以钦椭，當前對象只需要為其所依賴的對象提供相對應的 setter 方法拧额，就可以通過該方法將相應的依賴對象設置到被注入對象中。如下：
public class YoungMan {
private BeautifulGirl beautifulGirl;
public void setBeautifulGirl(BeautifulGirl beautifulGirl) {
this.beautifulGirl = beautifulGirl;
}
}
相比于構造器注入彪腔，setter 方式注入會顯得比較寬松靈活些侥锦，它可以在任何時候進行注入（當然是在使用依賴對象之前），這就好比你可以先把自己想要的妹子想好了德挣，然后再跟婚介公司打招呼恭垦，你可以要林志玲款式的，趙麗穎款式的格嗅，甚至鳳姐哪款的番挺，隨意性較強。
接口方式注入
接口方式注入顯得比較霸道屯掖，因為它需要被依賴的對象實現(xiàn)不必要的接口玄柏，帶有侵入性。一般都不推薦這種方式贴铜。
關于 IOC 理論部分粪摘，筆者不在闡述，這里推薦幾篇博客閱讀：
- 談談對Spring IOC的理解：http://www.cnblogs.com/xdp-gacl/p/4249939.html
- Spring的IOC原理[通俗解釋一下]：https://blog.csdn.net/m13666368773/article/details/7802126
- spring ioc原理（看完后大家可以自己寫一個spring）：https://blog.csdn.net/it_man/article/details/4402245
各個組件
先看下圖（摘自:http://singleant.iteye.com/blog/1177358）
該圖為 ClassPathXmlApplicationContext 的類繼承體系結構绍坝，雖然只有一部分徘意，但是它基本上包含了 IOC 體系中大部分的核心類和接口。
下面我們就針對這個圖進行簡單的拆分和補充說明轩褐。
Resource體系
Resource椎咧，對資源的抽象，它的每一個實現(xiàn)類都代表了一種資源的訪問策略把介，如ClasspathResource 勤讽、 URLResource ，F(xiàn)ileSystemResource 等劳澄。
有了資源地技，就應該有資源加載，Spring 利用 ResourceLoader 來進行統(tǒng)一資源加載秒拔，類圖如下：
BeanFactory 體系
BeanFactory 是一個非常純粹的 bean 容器，它是 IOC 必備的數(shù)據(jù)結構飒硅，其中 BeanDefinition 是她的基本結構砂缩，它內(nèi)部維護著一個 BeanDefinition map ，并可根據(jù) BeanDefinition 的描述進行 bean 的創(chuàng)建和管理三娩。
BeanFacoty 有三個直接子類 ListableBeanFactory庵芭、HierarchicalBeanFactory 和 AutowireCapableBeanFactory，DefaultListableBeanFactory 為最終默認實現(xiàn)雀监，它實現(xiàn)了所有接口双吆。
Beandefinition 體系
BeanDefinition 用來描述 Spring 中的 Bean 對象眨唬。
BeandefinitionReader體系
BeanDefinitionReader 的作用是讀取 Spring 的配置文件的內(nèi)容，并將其轉換成 Ioc 容器內(nèi)部的數(shù)據(jù)結構：BeanDefinition好乐。
ApplicationContext體系
這個就是大名鼎鼎的 Spring 容器匾竿，它叫做應用上下文，與我們應用息息相關蔚万，她繼承 BeanFactory岭妖，所以它是 BeanFactory 的擴展升級版，如果BeanFactory 是屌絲的話反璃，那么 ApplicationContext 則是名副其實的高富帥昵慌。由于 ApplicationContext 的結構就決定了它與 BeanFactory 的不同，其主要區(qū)別有：
- 繼承 MessageSource淮蜈，提供國際化的標準訪問策略斋攀。
- 繼承 ApplicationEventPublisher ，提供強大的事件機制梧田。
- 擴展 ResourceLoader蜻韭，可以用來加載多個 Resource，可以靈活訪問不同的資源柿扣。
- 對 Web 應用的支持肖方。
下圖來源：https://blog.csdn.net/yujin753/article/details/47043143
上面五個體系可以說是 Spring IoC 中最核心的部分，后面博文也是針對這五個部分進行源碼分析未状。其實 IoC 咋一看還是挺簡單的俯画，無非就是將配置文件（暫且認為是 xml 文件）進行解析（分析 xml 誰不會啊）司草，然后放到一個 Map 里面就差不多了艰垂，初看有道理，其實要面臨的問題還是有很多的埋虹，下面就勞煩各位看客跟著 LZ 博客來一步一步揭開 Spring IoC 的神秘面紗猜憎。
此系列博文為 LZ 學習、研究 Spring 機制和源碼的學習筆記搔课，會涉及參考別人的博文和書籍內(nèi)容胰柑，如有雷同，純屬借鑒爬泥，當然 LZ 會標明參考來源柬讨。同時由于知識面和能力的問題，文章中難免會出現(xiàn)錯誤之處袍啡，如有踩官，望各位大佬指出，不勝感激境输。
LZ 寫此系列博客時蔗牡，Spring 最新版本為 5.0.6.RELEASE 颖系，所以此系列博客所有源碼來源均為 5.0.6.RELEASE。
