1.IOC是Inversion of Control控制反转的缩写，为了解决对象之间的耦合度过高的问题
把复杂系统分解成相互合作的对象，这些对象类通过封装以后，内部实现对外部是透明的，从而降低了解决问题的复杂度，灵活被重用和扩展。借助于“第三方”实现具有依赖关系的对象之间的解耦，如下图：
图3：IOC解耦过程
大家看到了吧，由于引进了中间位置的“第三方”，也就是IOC容器，使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“粘合剂”的由来。
我们再来做个试验：把上图中间的IOC容器拿掉，然后再来看看这套系统：
图4：拿掉IoC容器后的系统
我们现在看到的画面，就是我们要实现整个系统所需要完成的全部内容。这时候，A、B、C、D这4个对象之间已经没有了耦合关系，彼此毫无联系，这样的话，当你在实现A的时候，根本无须再去考虑B、C和D了，对象之间的依赖关系已经降低到了最低程度。所以，如果真能实现IOC容器，每一成员只要实现自己的类就可以了，跟别人没有任何关系！
没有引入IOC容器之前：如图1所示，A依赖于B，A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B，控制权都在自己手上。
引入IOC容器之后：如图3所示，由于IOC容器的加入，A与B失去了直接联系，A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。
由主动变被动，“控制反转”的由来。
2. IOC的别名：依赖注入(DI)
获得依赖对象的过程被反转了。控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。于是，他给“控制反转”取了一个更合适的名字叫做“依赖注入（Dependency Injection）”。IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。
依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。
当 A需要B时，IOC容器就创建B给A。IOC容器就是一个对象制造工厂，直接使用就行.不用去关心如何制成怎么被销毁。
我们经常使用new关键字来实现两个组件之间关系的组合，会造成组件之间耦合。IOC解决了该问题，由容器在运行期将组件间的某种依赖关系动态注入组件中。
3. IOC为我们带来了什么好处
第一、可维护性好，便于单元测试，调试程序和诊断故障。每一个Class都可以单独测试，互不影响，低耦合的好处。
第二、分工明确、将大务划分为小任务，开发效率和产品质量提高。
第三、可复用性好，符合接口标准的实现，可以插接到支持此标准的模块中。
第四、对象生成放在配置文件里定义，更换一个实现子类将会变简单，修改配置文件就可以
4. IOC容器的技术剖析
IOC基本的技术就是“反射(Reflection)”编程，就是根据给出的类名（字符串方式）来动态地生成对象。让对象在生成时才决定到底是哪一种对象。应用广泛Hibernate、Spring框架
IOC容器的工作模式看做是工厂模式的升华，IOC容器看作是一个工厂。
1.生产的对象都在配置文件中给出定义
2.利用编程语言的的反射编程，根据配置文件中给出的类名生成相应的对象。
3.从实现来看，IOC是把以前在工厂方法里写死的对象生成代码，改变为由配置文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。
5. 使用IOC框架应该注意什么
缺点
第一、生成对象的步骤变得有些复杂
第二、生成对象是通过反射方式，在运行效率上有一定的损耗。
第三、具体到IOC框架产品(比如：Spring)来讲，需要进行大量的配制工作，比较繁琐
一些工作量不大的项目或者产品，不太适合使用IOC框架产品。
