对于IOC（Inversion of Control），很多人有不同的见解，这相当于“一千人心中有一千个哈姆雷特”，其实说来说去总是离不开“控制反转”和“依赖注入”。不要把IOC当成一种什么的很高深的技术，它只是一种概念，告诉你Spring针对程序解耦的实现方法。
首先我们来详细说一下什么叫“控制反转”，分解为两个关键词:控制和反转
①传统的JavaSE中我们如果在一个对象引入其他对象，习惯用new，这样我们就可以用这个对象资源，而IOC则是将对象创建其他对象的控制权收到自己手中，当对象需要引用其他对象时，不需要我们new，IOC容器会为你创建，即将对象新建的控制拿在手里。
②所谓new对象是属于主动的行为，那么被动的获取对象就属于被动行为，从我们自己主动创建依赖对象到由容器控制创建以及注入依赖对象，就是一种反转。
下面图片很好的反应了这个过程：
当引入IOC容器后，用户不需要去创建这些类：
知道IOC原理以后，我们需要知道Spring 的IOC带给我们怎么样的变化：
实现组件之间的解耦，提高程序的灵活性和可维护性。
但是同时:
1、创建对象的步骤变复杂了，不直观，当然这是对不习惯这种方式的人来说的。
2、因为使用反射来创建对象，所以在效率上会有些损耗。但相对于程序的灵活性和可维护性来说，这点损耗是微不足道的。
3、缺少IDE重构的支持，如果修改了类名，还需到XML文件中手动修改，这似乎是所有XML方式的缺憾所在。
其次，我们来说一下“依赖注入”（DI）。
依赖注入其实与控制反转是从不同角度来说明IOC概念，两个对象之间的依赖关系在程序运行时由外部容器动态的注入依赖行为方式称为依赖注入 (DI) 。
①如果类A需要运用类B的方法或者属性，通俗的说他们之前存在依赖关系。
②当A运行时，IOC容器会将类B注入到A中，A不需要知道B什么时候创建以及怎么构造的。
对于IOC，我们只要明白"控制反转"以及"依赖注入"中的每个字的含义就行了，它代表的只是一种设计原理，并非那么高深。