IoC就是IoC，不是什麼技術，是一種設計模式。IoC 亦稱爲 “依賴倒置原則”("Dependency Inversion Principle")。
控制反轉（Inversion of Control，英文縮寫爲IoC）是一個重要的面向對象編程的法則來削減計算機程序的耦合問題。 控制反轉還有一個名字叫做依賴注入（Dependency Injection）。簡稱DI。
可以把IoC模式看做是工廠模式的昇華。把IoC看作是一個大工廠，只不過這個大工廠裏要生成的對象都是在XML文件中給出定義的，然後利用Java 的“反射”編程，根據XML中給出的類名生成相應的對象。從實現來看，IoC是把以前在工廠方法裏寫死的對象生成代碼，改變爲由XML文件來定義，也就是把工廠和對象生成這兩者獨立分隔開來，目的就是提高靈活性和可維護性。
優缺點
IoC最大的好處是什麼？因爲把對象生成放在了XML裏定義，所以當我們需要換一個實現子類將會變成很簡單（一般這樣的對象都是實現於某種接口的），只要修改XML就可以了，這樣我們甚至可以實現對象的熱插撥（有點象USB接口和SCSI硬盤了）。
IoC最大的缺點是什麼？（1）生成一個對象的步驟變複雜了（事實上操作上還是挺簡單的），對於不習慣這種方式的人，會覺得有些彆扭和不直觀。（2）對象生成因爲是使用反射編程，在效率上有些損耗。但相對於IoC提高的維護性和靈活性來說，這點損耗是微不足道的，除非某對象的生成對效率要求特別高。（3）缺少IDE重構操作的支持，如果在Eclipse要對類改名，那麼你還需要去XML文件裏手工去改了，這似乎是所有XML方式的缺憾所在。
---------------------------------------------------------------------------
Spring的IoC
依賴注入(Dependency Injection)和控制反轉(Inversion of Control)是同一個概念。具體含義是:當某個角色(可能是一個Java實例，調用者)需要另一個角色(另一個Java實例，被調用者)的協助時，在傳統的程序設計過程中，通常由調用者來創建被調用者的實例。但在Spring裏，創建被調用者的工作不再由調用者來完成，因此稱爲控制反轉;創建被調用者實例的工作通常由Spring容器來完成，然後注入調用者，因此也稱爲依賴注入。
不管是依賴注入，還是控制反轉，都說明Spring採用動態、靈活的方式來管理各種對象。對象與對象之間的具體實現互相透明。在理解依賴注入之前，看如下這個問題在各種社會形態裏如何解決:一個人(Java實例，調用者)需要一把斧子(Java實例，被調用者)。
(1)原始社會裏，幾乎沒有社會分工。需要斧子的人(調用者)只能自己去磨一把斧子(被調用者)。對應的情形爲:Java程序裏的調用者自己創建被調用者。
(2)進入工業社會，工廠出現。斧子不再由普通人完成，而在工廠裏被生產出來，此時需要斧子的人(調用者)找到工廠，購買斧子，無須關心斧子的製造過程。對應Java程序的簡單工廠的設計模式。
(3)進入“按需分配”社會，需要斧子的人不需要找到工廠，坐在家裏發出一個簡單指令:需要斧子。斧子就自然出現在他面前。對應Spring的依賴注入。
第一種情況下，Java實例的調用者創建被調用的Java實例，必然要求被調用的Java類出現在調用者的代碼裏。無法實現二者之間的鬆耦合。
第二種情況下，調用者無須關心被調用者具體實現過程，只需要找到符合某種標準(接口)的實例，即可使用。此時調用的代碼面向接口編程，可以讓調用者和被調用者解耦，這也是工廠模式大量使用的原因。但調用者需要自己定位工廠，調用者與特定工廠耦合在一起。
第三種情況下，調用者無須自己定位工廠，程序運行到需要被調用者時，系統自動提供被調用者實例。事實上，調用者和被調用者都處於Spring的管理下，二者之間的依賴關係由Spring提供。