来源：zhihu.com/question/23277575/answer/24259844

ioc的思想最核心的地方在于，资源不由使用资源的双方管理，而由不使用资源的第三方管理，这可以带来很多好处。

1. 资源集中管理，实现资源的可配置和易管理。
2. 降低了使用资源双方的依赖程度，也就是我们说的耦合度。

也就是说，甲方要达成某种目的不需要直接依赖乙方，它只需要达到的目的告诉第三方机构就可以了，比如甲方需要一双袜子，而乙方它卖一双袜子，它要把袜子卖出去，并不需要自己去直接找到一个卖家来完成袜子的卖出。

它也只需要找第三方，告诉别人我要卖一双袜子。这下好了，甲乙双方进行交易活动，都不需要自己直接去找卖家，相当于程序内部开放接口，卖家由第三方作为参数传入。甲乙互相不依赖，而且只有在进行交易活动的时候，甲才和乙产生联系。反之亦然。

这样做什么好处么呢，甲乙可以在对方不真实存在的情况下独立存在，而且保证不交易时候无联系，想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面，避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系，而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。

这就是ioc的核心思想。生活中这种例子比比皆是，支付宝在整个淘宝体系里就是庞大的ioc容器，交易双方之外的第三方，提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是，雇佣机构和个人之外的第三方。

在以上的描述中，诞生了两个专业词汇，依赖注入和控制反转

所谓的依赖注入，则是，甲方开放接口，在它需要的时候，能够讲乙方传递进来(注入)

所谓的控制反转，甲乙双方不相互依赖，交易活动的进行不依赖于甲乙任何一方，整个活动的进行由第三方负责管理。

这就是spring IOC的思想所在，不要只谈DI IOC这些概念。

人之所恶在好为人师,不实知，谨慎言。

问：有点小问题，如果是甲方要袜子，那么他也必须依赖于一个卖袜子的人，这之间就有联系了，也就是说甲方也是依赖于乙方的，因为如果乙方没有卖袜子的话，甲方也就买不到袜子，自然也就没法继续进行，这怎么就解隅了呢？？

答：是解耦的，平时new A()时候是要import包地址的，这就已经写死了，以后这个引用就死死的指向了那个类，想改变很麻烦，用ac.getbean(“A”)就没引入包，也就是所谓的不依赖 （就是跟那类A没关系），它只从容器找那个叫A的类，至于你给我的是啥，看容器中咋配置。

举了例子：比如说是个很常用的dao类，开始你new的很开心，万一以后需求大改，数据库mysql换db2了，这个dao文件基本就得重写，如果这个类已经封装编译为class文件，不能改了怎么办。又或者你实例化了一个常用接口。

原来那个实现类A不好，要换成B做他的实现类，重写他的方法。你就得把项目中所有实例化的地方都找出来，再改成B（大项目用了很多的话你就一个一个改类似，万一漏了就是不小的bug）。

用ioc就没这个麻烦，直接在配置文件中将叫A的bean指向你新写的类就可以。所以说他依赖的乙方不是卖袜子的，而是一个中介