谈到Spring中的Ioc，我们大部分人可能会有一些误解，觉得这一定又是一门新技术，实际上，IOC-Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。本文我们就来深入分析一下Spring 框架的 IoC。

在采用面向对象方法设计的软件系统中，底层实现都是由N个对象组成的，所有的对象通过彼此的合作，最终实现系统的业务逻辑。即软件系统中对象之间的耦合，对象A和对象B之间有关联，对象B又和对象C有依赖关系，这样对象和对象之间有着复杂的依赖关系，所以才有了控制反转这个理论。

在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。如何理解好Ioc呢？理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：

传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。

有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。

IoC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦，如下图所示：

即把各个对象类封装之后，通过IoC容器来关联这些对象类。这样对象与对象之间就通过IoC容器进行联系，但对象与对象之间并没有什么直接联系。

如果去掉IoC容器后系统中的对象A与对象B就有了直接关系，如下图所示：

比如好多的对象类要关联起来的话，就会变得很复杂，如下图所示：

所以提出IoC控制反转是很有必要的。

说到IoC我们很容易就联想到依赖注入（DI），Martin Fowler曾经探讨了同一个问题，既然IoC是控制反转，那么到底是“哪些方面的控制被反转了呢？”，经过详细地分析和论证后，他得出了答案：“获得依赖对象的过程被反转了”。控制被反转之后，获得依赖对象的过程由自身管理对象变为由IoC容器主动注入。于是，他给“控制反转”取了一个更合适的名字叫做“依赖注入（Dependency Injection，DI）”。他的这个答案，实际上给出了实现IoC的方法：注入。

DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

我们仔细对比一下依赖注入（DI）和控制反转（IoC），其实不难发现两者是从不同的角度描述的同一件事情，就是指通过引入IoC容器，利用依赖关系注入的方式，实现对象之间的解耦。 

控制反转是Spring框架的核心，贯穿了整个框架的工作流程。其原理是基于面向对象(OO)设计原则的The Hollywood Principle：Don't call us, we'll call you（别找我，我会来找你的）。也就是说，所有的组件都是被动的，所有的组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。简单的来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控，即在一个类中调用另外一个类。这也就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，即所谓反转。

其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。

基本上掌握了Spring 框架的 IoC，就等于掌握了整个Spring 框架。当然，如果你觉得上面的讲解模棱两可，你看起来似懂非懂的话欢迎观看本站的专业课程，有名师讲解，为你排疑解惑！