IOC：Inversion of Control(控制反轉)。IOC它所展現的并不是一種技術，而是一種思想，一種将設計好的對象交給容器來管理的思想。IOC的核心思想就展現在控制、反轉這兩個詞上面，要了解就必須要了解幾個問題：
1、誰控制誰？在傳統的開發工作中，我們一般都是主動去new一個對象，這個是主動控制依賴對象。但是對于IOC而已，控制權會被移交給容器，是以應該是IOC容器控制對象。
2、控制什麼？既然是IOC容器控制對象，那控制什麼呢？IOC容器除了負責控制對象的生成還包括外部資源的擷取。
3、為何是反轉？對象主動生成依賴對象，我們稱之為“正轉”，但是現在有IOC來負責了，是以反轉則是IOC容器來負責對象的生成和注入過程。
4、那些地方反轉？依賴對象的擷取被反轉了。
對于IOC而言，它強調是将主動變為被動，由IOC容器來負責依賴對象的建立和查找，由IOC容器來進行注入組合對象。将原來的強聯系、高耦合轉變為了弱關系、松耦合。IOC，它能指導我們如何設計出松耦合、更加優良的程式，把應用程式從原來需要維護依賴對象之間關系中徹底解放出來而更加專注于業務邏輯，這樣會使得程式的整個體系機構變得非常靈活。
其實IoC對程式設計帶來的最大改變不是從代碼上，而是從思想上，發生了“主從換位”的變化。應用程式原本是老大，要擷取什麼資源都是主動出擊，但是在IoC/DI思想中，應用程式就變成被動的了，被動的等待IoC容器來建立并注入它所需要的資源了。
有了IOC就有必要提到DI了。DI,Dependency Injection，即“依賴注入”。其實IOC和DI本就是同一個概念的兩種不同的表述，DI所描述的是由容器動态地将某個依賴關系注入到主鍵當中去，其需要了解如下幾個概念：
1、誰依賴誰？應用程式依賴IOC容器。
2、依賴什麼？因為應用程式不再主動去建立對象，由IOC容器來向應用程式注入，是以應該是應用程式依賴IOC容器來提供的外部資源。
3、誰注入誰？由IOC容器向應用程式注入。
4、注入什麼？注入的某個對象所依賴的外部資源。
通俗點将就是IOC就是容器控制應用程式所需要外部資源的建立和管理，然後将其反轉給應用程式；而DI是應用程式依賴容器提供的外部對象，容器将其依賴的外部資源在運作期注入到應用程式中。兩者表達的意思都是容器負責應用程式的建立和管理，應用程式隻需要在需要它們的時候等待容器将其所依賴的外部資源提供就行，至于來自哪裡，怎麼來的應用程式都不需要知道。
具體的IOC了解我就不多闡述了，網上實在是太多了，這裡推薦幾篇部落格：
1、談談對Spring IOC的了解
2、【第二章】 IoC 之 2.1 IoC基礎 ——跟我學Spring3
3、Spring的IOC原理[通俗解釋一下]
4、spring ioc原理（看完後大家可以自己寫一個spring）
IOC作為一個容器，它裡面放得都是bean、bean與bean之間的對應關系，而bean之間的對應關系我們開始都是通過xml配置檔案來展現的。那麼這裡就回報了如下幾個問題：
1、對應與對象之間的關系是通過xml配置檔案來描述的（當然也可以是properties等檔案）。
2、描述的檔案存放位置在那裡，一般來說我們都是放在classpath目錄下的，但是也可是是URL、fileSystem。
3、檔案的解析。
4、Bean在容器中的表現形式，也就是它的資料結構。
對于Spring而言，它用Resource、BeanDefinition、BeanDefinitionReader、BeanFactory、ApplicationContext五個元件來實作以上問題，而同時這5個接口定義了 spring ioc 容器的基本代碼元件結構。下面我們逐一了解這五個結構
Resource
Resource，對資源的抽象，它的每一個實作類都代表了一種資源的通路政策，如ClasspathResource 、 URLResource ，FileSystemResource 等。
BeanDefinition
用來描述和抽象一個具體的Bean對象，它是描述Bean對象的基本資料結構。
BeanDefinitionReader
外部資源所表達的語義需要統一轉化為統一的内部資料結構BeanDefinition，這個時候BeanDefinitionReader就起到統一解析的作用力了。對應不同的描述需要有不同的 Reader 。如 XmlBeanDefinitionReader 用來讀取xml 描述配置的 bean 對象。
BeanFactory
BeanFactory是一個非常純粹的bean容器，它是IOC必備的資料結構，其中BeanDefinition是她的基本結構，它内部維護着一個BeanDefinition map，并可根據BeanDefinition 的描述進行 bean 的建立和管理。
ApplicationContext
這個就是大名鼎鼎的Spring容器，它叫做應用上下文，與我們應用息息相關，她繼承BeanFactory，是以它是BeanFactory的擴充更新版，如果BeanFactory是屌絲的話，那麼ApplicationContext則是名副其實的高富帥。由于ApplicationContext的結構就決定了它與BeanFactory的不同，其主要差別有：
1、繼承MessageSource，提供國際化的标準通路政策。
2、繼承ApplicationEventPublisher，提供強大的事件機制。
3、擴充ResourceLoader，可以用來加載多個Resource，可以靈活通路不同的資源。
4、對Web應用的支援。
下圖是上面組合關系圖（以ClasspathXmlApplicationContext 為例）
以上圖檔均來自：啃啃老菜： Spring IOC核心源碼學習（一）
下面LZ将盡全力闡述IOC的初始化過程和在該過程中涉及的重要元件，這系列部落格是也是LZ學習、研究Spring機制和源碼的學習筆記，其中難免會參考别人的部落格，如有雷同，純屬借鑒。同時也避免不了錯誤之處，博文中的錯誤望各位博友指出，不勝感激！！！
參考資料
1、啃啃老菜： Spring IOC核心源碼學習（一）
PS:如果你覺得文章對你有所幫助，别忘了推薦或者分享，因為有你的支援，才是我續寫下篇的動力和源泉！
作者：chenssy。一個專注于【死磕 Java】系列創作的男人
出處：https://www.cnblogs.com/chenssy/p/5106486.html
作者個人網站：https://www.cmsblogs.com/。專注于 Java 優質系列文章分享，提供一站式 Java 學習資料
目前死磕系列包括：
1. 【死磕 Java 并發】：https://www.cmsblogs.com/category/1391296887813967872（已完成）
2.【死磕 Spring 之 IOC】：https://www.cmsblogs.com/category/1391374860344758272（已完成）
3.【死磕 Redis】：https://www.cmsblogs.com/category/1391389927996002304（已完成）
4.【死磕 Java 基礎】：https://www.cmsblogs.com/category/1411518540095295488
5.【死磕 NIO】：https://www.cmsblogs.com/article/1435620402348036096
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。