IoC,Inversion Of Control 即控制反转，由容器来管理业务对象之间的依赖关系，而非传统方式中的由代码来管理。
其本质，即将控制权由应用程序代码转到了外部容器，控制权的转移就是所谓的反转，其带来的最大的好处是降低了业务对象之间的依赖程度，即实现了解耦。
Spring的IoC容器主要使用DI（Dependency Injection，依赖注入）方式实现的。不需要主动查找，对象的查找、定位和创建全部由容器管理，容器会将符合依赖关系的对象通过属性（setter等）或者构造函数传递给需要的对象。
使用IoC可以带来以下好处：
1、查询依赖操作和应用代码分离，大量减少了Factory和Singleton的数量，使代码层次更加清晰，主要原因是我们不再查找、定位、创建和管理对象之间的依赖关系了，都交给IoC容器管理了
2、没有侵入性，不需要依赖容器的API，也不需要实现一些特殊接口。这样我们的受控对象可以搬出容器进而单独使用。
3、可以从IoC容器中直接获得一个对象然后直接使用，而无需考虑对象的创建过程。（工厂模式）
从网上看了一个例子，觉得不错，贴过来帮助我们理解：
我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。 那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转
其实，我们可以把IoC看做是工厂模式的升华，IoC好比是一个大工厂，只不过在这个大工厂里生成的对象都是在XML文件中定义的，然后利用Java的反射实例化。在没有Spring之前我们也是这么做的，只是Spring的IoC更加强大完善。
有利就有毙,IoC也有一定的弊端：
1、使用反射变成，在效率上有些损耗。
2、缺乏更加智能的IDE，写XML中时，错误不容易暴露，推迟到运行期才能发现。
但相对于IoC提高的维护性和灵活性来说，这点缺点又显得微不足道
写到最后，忽然想到《走遍美国》里，唱片公司制片在rebaca录制完唱片后对她说的一句话：Don't call us,we'll call you
用这句话来形容IoC再合适不过。
