名词解释：
依赖注入（DI）：甲方开放接口，在它需要的时候，能够讲乙方传递进来（注入）
控制反转（IOC）：甲乙双方不相互依赖，交易活动的进行不依赖于甲乙任何一方，整个活动的进行由第三方负责管理。
注意：这里说的第三方指的是Spring的核心配置文件（xml）
IOC思想的好处：
1、资源集中管理，实现资源的可配置和易管理；
2、降低了使用资源双方的依赖程度，也就是我们说的耦合度。
举例说明：
甲方要达成某种目的不需要直接依赖乙方，它只需要达到的目的告诉第三方机构就可以了，比如甲方需要一双袜子，而乙方它卖一双袜子，它要把袜子卖出去，并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方，告诉别人我要卖一双袜子。这下好了，甲乙双方进行交易活动，都不需要自己直接去找卖家，相当于程序内部开放接口，卖家由第三方作为参数传入。甲乙互相不依赖，而且只有在进行交易活动的时候，甲才和乙产生联系。反之亦然。这样做什么好处么呢，甲乙可以在对方不真实存在的情况下独立存在，而且保证不交易时候无联系，想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面，避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系，而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。
详细总结：
平时new A()时候是要import包地址的，这就已经写死了，以后这个引用就死死的指向了那个类，想改变很麻烦，用 ApplicationContext.getBean(“A”)就不需要引入包，也就是所谓的不依赖 （就是跟那类A没关系），它只从容器找那个叫A的类，至于你给我的是什么，看容器中如何配置。举个例子：比如说是个很常用的dao类，开始你new的很开心，万一以后需求大改，数据库mysql换db2了，这个dao文件基本就得重写，如果这个类已经封装编译为class文件，不能改了怎么办。又或者你实例化了一个常用接口。原来那个实现类A不好，要换成B做他的实现类，重写他的方法。你就得把项目中所有实例化的地方都找出来，再改成B（大项目用了很多的话你就一个一个改类似，万一漏了就是不小的bug）。用ioc就没这个麻烦，直接在配置文件中将叫A的bean指向你新写的类就可以。因此使用IOC容器极大的降低了耦合度。