控制反轉(IoC)：概念的描述：
Martin Fowler提出，那些方面的控制被反轉了？ - 他給出的結論：依賴對象的獲取被反轉了，基於這個結論他爲控制反轉創造了一個由兩個或多各類批次之間的合作來實現業務邏輯的，這是的每一個對象都需要與其合作的對象（也就是他依賴的對象）的引用。如果這個獲取過程要考自身實現，那麼如果如你所見，這將導致代碼高度耦合難以測試。--《摘自維基百科》
我是這樣理解IOC容器：以水桶爲例，有大的，小的，有金的，銀的，各種各樣。IOC容器也如此，每種不同的容器有自己功能，但是他們有一個是不能改變的，那就是裝水，我們所學習的IOC容器也一樣。
IOC是Inversion of Control的縮寫，由於引進了中間位置的第三方，也就是IOC容器使得沒有關聯關係的類有了一個共同的關係--被ICO容器所管理，所以說IOC容器起到了粘合劑的作用。
DI是Dependency Injection的所寫，是指通過引入IOC容器，利用類與類相關的依賴關係，注入的方式，實現代碼重用以及對象之間的解耦合。（說到解耦合，三大框架都是爲了解耦合，面試時候千萬別說解耦合 ，說具體，哈哈。）
IOC的好處，初始化的過程中就不可避免的會寫大量的new，只需要維護XML或註解，不需要大量的修改代碼，IOC容器是分層的，從最底層BeanFactory網上找（後面源碼解讀會詳細講解），實現類與類之間的解耦合，可以將代碼分離，每個人只需要寫自己的部分，利於團隊協作。
複合IOC規範的產品: Spring、Guice、Pico Container、Avalon、HiveMind；重量級的有EJB，JBoss，Jdon等等。以上除了Spring別的都沒用過，出去面試吹一下也沒啥^-^
使用IOC容器的小缺點: 引入第三方工具，對性能，初始化等速度均有影響，需要配置一大堆（springboot簡化了好多，推薦大家從基於xml的spring學起），通過反射機制創建對象，效率較低~~~實際沒影響。
