IOC：控制反转，它是不是什么技术，它是一种设计模式。所谓控制反转就是由容器控制程序间的关系，而
不是传统实现中，由编程代码直接操控。说白了就是由容器控制对象间的依赖关系。
DI：Dependency Injection 依赖注入 ，即组件(对象)之间的依赖关系由容器在运行期间决定。其实依赖注
入和控制反转是对同一概念的不同描述。
Spring通过这种控制反转（IoC）的设计模式促进了松耦合。当应用了IoC，一个对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。不是对象从容器中查找依赖，而是容器在对象初始化时不等对象请求就主动将依赖传递给它。我们可以把IoC模式看做是工厂模式的升华，可以把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。
(自己理解的白话)其实控制反转就是不需要我们手动new一个对象了，它把我们所要实例化的对象都写在了配置文件xml中了，一般这个类都是我们应用的业务类。框架内部已经将xml中配置的类自动实例化成对象，当我们调用某个类A，并且这个类中存在另一个类B时，我们就说A依赖于B,容器就会将B对象注入到A类中，大多数情况下都是通过A类中的setB()方法注入进来的。以前是由类中的代码查找类并new对象，现在是xml文件控制的对象的生成，控制权由程序代码转移到了xml文件中。这样做还是有好处的，假如在A中需要5个对象，那么A类中就会new5个对象，不管以后A中用不用到这5个类，只要用到A类，就会把这5个类全部new出来。如果我们在xml文件中定义类的话，当类需要用到其中的三个类时，就会用对应的set类()方法将对象注入进来，不用的就不注入进来，由此看来，第一个方法时将类A和5个类紧紧联系起来，不管用不用到5个类都new一下，真浪费，而第二个方法是第一个类你需要我得时候我就注入进来被你用，你不需要就和我没关系。这样类A和其中的5个类是分别独立的互不干预，当有关系的时候，容器自动注入关系。