IOC控制反转依赖注入和new对象的区别

spring默认是单例模式的，依赖注入其中操作的都是一个对象

new对象

单例中如果要做到注入的效果就是在类的头部进行实例化对象，这个时候该对象不管使用与否都贯穿该类的始终。该类对象不被回收，这个实例化对象也不会被回收，因为存在引用状态。如果要使用多例对象则最好使用new创建对象而不是依赖注入，即使依赖注入有多例模式也不推荐。

依赖注入：是指程序运行过程中，如果需要调用另一个对象协助时，无须再代码中创建被调用者，而是依赖外部的注入。spring的依赖注入对调用者和被调用者几乎没有任何要求，完全支持对pojo之间依赖关系的管理

依赖注入

如果调用者使用到被调用对象才会从spring容器中取出依赖的对象注入到使用的类中，如果不用则会放回spring容器的对象池中，做到内存节省并且代码的耦合度也降低。面向接口编程中，让依赖注入只需要找到符合规范的接口注入即可实现调用者和被调用者解耦。对象的调用关系由spring管理。

进入实习之后，就之前不是很理解的依赖注入很好奇，在实际工作中也有留意使用并且理解多了之后就查阅文档总结出这个结论，如果有错误的请大佬指出。 

spring的IOC容器比New对象究竟好在哪

私以为以上各位都没有对spring ioc的精髓讲解到位。大多都在很模糊的说是什么，抽象化的表述或者含糊其辞的说概念。

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

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

也就是说，甲方要达成某种目的不需要直接依赖乙方，它只需要达到的目的告诉第三方机构就可以了，比如甲方需要一双袜子，而乙方它卖一双袜子，它要把袜子卖出去，并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方，告诉别人我要卖一双袜子。这下好了，甲乙双方进行交易活动，都不需要自己直接去找卖家，相当于程序内部开放接口，卖家由第三方作为参数传入。甲乙互相不依赖，而且只有在进行交易活动的时候，甲才和乙产生联系。反之亦然。这样做什么好处么呢，甲乙可以在对方不真实存在的情况下独立存在，而且保证不交易时候无联系，想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面，避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系，而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。

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

==============update==============

• 在以上的描述中，诞生了两个专业词汇，依赖注入和控制反转
• 所谓的依赖注入，则是，甲方开放接口，在它需要的时候，能够讲乙方传递进来(注入)
• 所谓的控制反转，甲乙双方不相互依赖，交易活动的进行不依赖于甲乙任何一方，整个活动的进行由第三方负责管理。

这就是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指向你新写的类就可以。所以说他依赖的乙方不是卖袜子的，而是一个中介