说到 IoC（Inversion of Control，反转控制），得先简单说下什么是 Dependency Inversion Principle（依赖倒置原则），DI 是实现 IoC 的一种方式。
假设我们设计一辆汽车有两种方案：
方案一：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个「依赖」关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。 方案二：我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。在方案一中，如果说要修改轮胎设计，则会导致轮胎设计之后的流程也重新走一遍；而在方案二中，如果需要修改轮胎设计，只需要修改轮胎就行，而不需要修改其他内容。
这就是依赖倒置原则——把原本的高层建筑依赖底层建筑「倒置」过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的「牵一发动全身」的情况。
两者的关系： 以上内容来自：Spring IoC有哪些好处？
IoC（Inversion of Control，反转控制）：在应用程序中的组件需要获取资源时，传统的方式是组件主动从容器中获取所需要的资源。而在 IoC 的思想中反转了资源的获取方向：改由容器主动将资源推送给需要的组件，开发人员不需要知道容器是如何创建资源对象的，只需要提供接收资源的方式即可。
用找对象举个例子： 你如果是主动找的话，你看到了一个中意的，需要你自己去问人要联系方式；而如果你在婚姻介绍所（容器）呢，说了你的标准后，有关人员就会将符合你意愿的另一个人的联系方式给你。
在通过 IoC 容器读取 Bean 的实例之前，我们需要将 IoC 容器本身实例化，在 Spring 中提供了两种 IoC 的实现方式：
BeanFactory：IoC 容器的基本实现，是面向 Spring 容器本身的，开发人员一般不用；ApplicationContext：BeanFactory 的子接口，提供了更多的特性，面向开发人员使用。ApplicationContext 的主要实现类：
ClassPathXmlApplicationContext：基于对应类路径下的XML格式的配置文件的实现类FileSystemXmlApplicationContext：基于对应文件系统中的XML格式的配置文件的实现类AnnotationConfigApplicationContext：基于注解配置的实现类BeanFactory 和 ApplicationContext 的区别：
BeanFactory 才是 Spring 容器中的顶层接口，ApplicationContext 是它的子接口。创建对象的时间点不一样： ApplicationContext：只要一读取配置文件，默认情况下就会创建对象。 BeanFactory：什么使用什么时候创建对象ConfigurableApplicationContext：是 ApplicationContext 的子接口，包含一些扩展方法，如 refresh() 和 close()，这两个方法让 ApplicationContext 有了启动、关闭以及刷新的能力。
本质是用到了 DI（Dependency Injection，依赖注入），DI 的相关博客，敬请期待~
IoC 是一种思想，而我们有时候听到的「将 Bean 交给 Spring 的 IoC 容器管理 」这句话容易给人以「IoC 是 Spring 的容器」的假象。
