本文参考《精通Spring 4.x 企业应用开发实战》

IoC概述

IoC（Inverse of Control），控制反转是Spring容器的内核，AOP、生命是事务等功能在此基础上开花结果。但是IoC这个概念还是比较晦涩难懂，不容易让人望文生义，还是有很大遗憾的。

理解IoC概念

书上用《墨攻》来举例子，解释了导演，剧本，演员之间的关系，是如何进行控制反转的。但是我觉得并不容易读懂，所以我决定换个例子：
27岁阿里程序员相亲穿特步被拒—不管是不是阿里的程序员，也不管为什么是单身，也不管为什么穿特步。我们就说说找对象这个事。
首先一开始肯定是自己找对象啊。所以一开始你是这个样子的：
SpringTest1
这个时候你会不断的去更改你的要求，直至你找到（不到）女朋友。
但是“你”和“找女朋友”这个动作是直接耦合的，作为一个效率至上的程序员，这个是绝对不允许的。所以这个时候你找到了一个中介——intermediary。
SpringTest2
此时，你只需要告诉中介，你需要什么样子的女朋友，他就会帮你找到合适的。是不是很方便，很节省时间。同样，因为“中介”的介入，“你”和“找女朋友”这个事情解耦。对应到代码中，中介就相当于一台装配器，替“你”去“找女朋友”。
现在我们可以反过来说一下IoC的概念了：IoC（Inverse of Control）的字面意思是控制反转，它包含两方面的内容：

其一是控制
其二是反转

那到底是什么东西的“控制”被“反转”呢？对应到上面的例子，“控制”是指“找女朋友”的控制权；“反转”是指这种控制权从“你”的手中，转移到“中介”的手中。对于软件来说，即某一接口具体实现类的选择控制权从调用类中一处，转交给第三方决定，即由Spring容器借由Bean配置来进行控制。
因为IoC确实不够开门见山，因此业界曾进行了广泛的讨论，最终软件界的泰斗级人物Martin Fowler提出来DI(Dependency Injection, 依赖注入)的概念用来代替IoC，即让调用类对某一接口实现类的依赖关系由第三方（容器或协作类）注入，以一处调用类对某一接口实现类的依赖。“依赖注入”这个名词显然比“控制反转”直接明了、易于理解。

IoC的类型

从注入方法上看，IoC主要可以划分为三种类型：构造函数注入、属性注入和接口注入。Spring支持构造函数注入和属性注入。

构造函数注入

在构造函数注入中，通过调用类的构造函数，将接口实现类通过构造函数变量传入。

属性注入

属性注入可以有选择的通过Setter方法完成调用类所需依赖的注入，更加灵活方便

接口注入

将调用类所有依赖注入的方法抽取到一个接口中，调用类通过实现该接口提供相应的注入方法。为了采取接口注入的方式，必须先声明一个接口。然后用过接口提供的方法完成注入工作。

因为通过接口注入需要额外声明一个接口，增加了类的数目，而且他的效果和属性注入无本质区别，所以不提倡使用接口注入。

通过容器完成依赖关系的注入

虽然上面的三种方式都可以实现解耦，但是对于创建对象的过程都在代码中体现，如果有第三方代理去帮助我们实现，才会实现完全解耦。
在程序领域就是一个第三方的容器，它帮助完成类的初始化与装配工作。让开发者从这些底层实现类的实例化、依赖关系装配等工作中解脱出来，专注于更有意义的业务逻辑开发工作。
Spring就是这样的一个容器，它通过配置文件或注解描述类和类之间的依赖关系，自动完成类的初始化和依赖注入工作。
通过new XmlBeanFactory("beans.xml")等方式既可启动容器，在容器启动时，会根据配置文件的描述信息，自动实例化Bean并完成历来关系的装配，从容器中既可返回贮备就绪的Bean实力，后续可直接使用。

但是Spring为什么会有这种“神奇”的力量呢，仅凭一个简单的配置文件，就可以实例化并装配好程序有用的Bean。这种“神奇”的力量归功于java语言本身的类反射功能。下面简单的说说Spring的技术内幕。

Spring 4.x IOC介绍