共计 8478 个字符，预计需要花费 22 分钟才能阅读完成。
IoC 是什么
Ioc—Inversion of Control，即“管制反转”，不是什么技术，而是一种设计思维。在 Java 开发中，Ioc 意味着将你设计好的对象交给容器管制，而不是传统的在你的对象外部间接管制。如何了解好 Ioc 呢？了解好 Ioc 的要害是要明确“谁管制谁，管制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那咱们来深入分析一下：
●谁管制谁，管制什么：传统 Java SE 程序设计，咱们间接在对象外部通过 new 进行创建对象，是程序被动去创立依赖对象；而 IoC 是有专门一个容器来创立这些对象，即由 Ioc 容器来管制对 象的创立；谁管制谁？当然是 IoC 容器管制了对象；管制什么？那就是次要管制了内部资源获取（不只是对象包含比方文件等）。
●为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由咱们本人在对象中被动管制去间接获取依赖对象，也就是正转；而反转则是由容器来帮忙创立及注入依赖对象；为何是反转？因为由容器帮咱们查找及注入依赖对象，对象只是被动的承受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
用图例阐明一下，传统程序设计如图 2 -1，都是被动去创立相干对象而后再组合起来：
1.2、IoC 能做什么
IoC 不是一种技术，只是一种思维，一个重要的面向对象编程的法令，它能领导咱们如何设计出松耦合、更低劣的程序。传统应用程序都是由咱们在类外部被动创立依赖对象，从而导致类与类之间高耦合，难于测试；有了 IoC 容器后，把创立和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 涣散耦合，这样也不便测试，利于性能复用，更重要的是使得程序的整个体系结构变得非常灵活。
其实IoC 对编程带来的最大扭转不是从代码上，而是从思维上，产生了“主从换位”的变动。应用程序本来是老大，要获取什么资源都是主动出击，然而在 IoC/DI 思维中，应用程序就变成被动的了，被动的期待 IoC 容器来创立并注入它所须要的资源了。
IoC 很好的体现了面向对象设计法令之一—— 好莱坞法令：“别找咱们，咱们找你”；即由 IoC 容器帮对象找相应的依赖对象并注入，而不是由对象被动去找。
1.3、IoC 和 DI
DI—Dependency Injection，即“依赖注入”：组件之间依赖关系 由容器在运行期决定，形象的说，即 由容器动静的将某个依赖关系注入到组件之中 。 依赖注入的目标并非为软件系统带来更多功能，而是为了晋升组件重用的频率，并为零碎搭建一个灵便、可扩大的平台。通过依赖注入机制，咱们只须要通过简略的配置，而无需任何代码就可指定指标须要的资源，实现本身的业务逻辑，而不须要关怀具体的资源来自何处，由谁实现。
了解 DI 的要害是：“谁依赖谁，为什么须要依赖，谁注入谁，注入了什么”，那咱们来深入分析一下：
●谁依赖于谁：当然是 应用程序依赖于 IoC 容器；
●为什么须要依赖：应用程序须要 IoC 容器来提供对象须要的内部资源；
●谁注入谁：很显著是IoC 容器注入应用程序某个对象，应用程序依赖的对象；
●注入了什么：就是 注入某个对象所须要的内部资源（包含对象、资源、常量数据）。
IoC 和 DI由什么 关系 呢？其实它们 是同一个概念的不同角度形容，因为管制反转概念比拟含混（可能只是了解为容器管制对象这一个层面，很难让人想到谁来保护对象关系），所以 2004 年大师级人物 Martin Fowler 又给出了一个新的名字：“依赖注入”，绝对 IoC 而言，“依赖注入”明确形容了“被注入对象依赖 IoC 容器配置依赖对象”。
看过很多对 Spring 的 Ioc 了解的文章，好多人对 Ioc 和 DI 的解释都艰涩难懂，反正就是一种说不清，道不明的感觉，读完之后仍然是一头雾水，感觉就是开涛这位技术牛人写得特地通俗易懂，他分明地解释了 IoC(管制反转) 和 DI(依赖注入)中的每一个字，读完之后给人一种恍然大悟的感觉。我置信对于初学 Spring 框架的人对 Ioc 的了解应该是有很大帮忙的。
2.1、IoC(管制反转)
首先想说说 IoC（Inversion of Control，管制反转）。这是spring 的外围，贯通始终。 所谓 IoC，对于 spring 框架来说，就是由 spring 来负责管制对象的生命周期和对象间的关系。这是什么意思呢，举个简略的例子，咱们是如何找女朋友的？常见的状况是，咱们到处去看哪里有长得丑陋身材又好的 mm，而后打听她们的兴趣爱好、qq 号、电话号、ip 号、iq 号………，想方法意识她们，投其所好送其所要，而后嘿嘿……这个过程是简单深奥的，咱们必须本人设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要应用另外的对象，就必须失去它（本人 new 一个，或者从 JNDI 中查问一个），应用完之后还要将对象销毁（比方 Connection 等），对象始终会和其余的接口或类藕合起来。
那么 IoC 是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介治理了很多男男女女的材料，我能够向婚介提出一个列表，通知它我想找个什么样的女朋友，比方长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，而后婚介就会依照咱们的要求，提供一个 mm，咱们只须要去和她谈恋爱、结婚就行了。简单明了，如果婚介给咱们的人选不符合要求，咱们就会抛出异样。整个过程不再由我本人管制，而是有婚介这样一个相似容器的机构来管制。Spring 所提倡的开发方式 就是如此，所有的类都会在 spring 容器中注销，通知 spring 你是个什么货色，你须要什么货色，而后 spring 会在零碎运行到适当的时候，把你要的货色被动给你，同时也把你交给其余须要你的货色。所有的类的创立、销毁都由 spring 来管制，也就是说管制对象生存周期的不再是援用它的对象，而是 spring。对于某个具体的对象而言，以前是它管制其余对象，当初是所有对象都被 spring 管制，所以这叫管制反转。
2.2、DI(依赖注入)
IoC 的一个重点是在零碎运行中，动静的向某个对象提供它所须要的其余对象。这一点是通过 DI（Dependency Injection，依赖注入）来实现的。比方对象 A 须要操作数据库，以前咱们总是要在 A 中本人编写代码来取得一个 Connection 对象，有了 spring 咱们就只须要通知 spring，A 中须要一个 Connection，至于这个 Connection 怎么结构，何时结构，A 不须要晓得。在零碎运行时，spring 会在适当的时候制作一个 Connection，而后像打针一样，注射到 A 当中，这样就实现了对各个对象之间关系的管制。A 须要依赖 Connection 能力失常运行，而这个 Connection 是由 spring 注入到 A 中的，依赖注入的名字就这么来的。那么 DI 是如何实现的呢？Java 1.3 之后一个重要特色是反射（reflection），它容许程序在运行的时候动静的生成对象、执行对象的办法、扭转对象的属性，spring 就是通过反射来实现注入的。
了解了 IoC 和 DI 的概念后，所有都将变得简单明了，剩下的工作只是在 spring 的框架中沉积木而已。
三、我对 IoC(管制反转)和 DI(依赖注入)的了解
在平时的 java 利用开发中，咱们要实现某一个性能或者说是实现某个业务逻辑时至多须要两个或以上的对象来合作实现，在没有应用 Spring 的时候，每个对象在须要应用他的单干对象时，本人均要应用像 new object() 这样的语法来将单干对象创立进去，这个单干对象是由本人被动创立进去的，创立单干对象的主动权在本人手上，本人须要哪个单干对象，就被动去创立，创立单干对象的主动权和创立机会是由本人把控的，而这样就会使得对象间的耦合度高了，A 对象须要应用单干对象 B 来共同完成一件事，A 要应用 B，那么 A 就对 B 产生了依赖，也就是 A 和 B 之间存在一种耦合关系，并且是严密耦合在一起，而应用了 Spring 之后就不一样了，创立单干对象 B 的工作是由 Spring 来做的，Spring 创立好 B 对象，而后存储到一个容器外面，当 A 对象须要应用 B 对象时，Spring 就从寄存对象的那个容器外面取出 A 要应用的那个 B 对象，而后交给 A 对象应用，至于 Spring 是如何创立那个对象，以及什么时候创立好对象的，A 对象不须要关怀这些细节问题(你是什么时候生的，怎么生进去的我可不关怀，能帮我干活就行)，A 失去 Spring 给咱们的对象之后，两个人一起合作实现要实现的工作即可。
所以 管制反转 IoC(Inversion of Control)是说创建对象的控制权进行转移，以前创建对象的主动权和创立机会是由本人把控的，而当初这种势力转移到第三方，比方转移交给了 IoC 容器，它就是一个专门用来创建对象的工厂，你要什么对象，它就给你什么对象，有了 IoC 容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖 IoC 容器了，通过 IoC 容器来建设它们之间的关系。
这是我对 Spring 的 IoC(管制反转)的了解。DI(依赖注入)其实就是 IOC 的另外一种说法，DI 是由 Martin Fowler 在 2004 年初的一篇论文中首次提出的。他总结：管制的什么被反转了？就是：取得依赖对象的形式反转了。
四、小结
对于 Spring Ioc 这个外围概念，我置信每一个学习 Spring 的人都会有本人的了解。这种概念上的了解没有相对的标准答案，仁者见仁智者见智。如果有了解不到位或者了解错的中央，欢送宽广园友斧正！
引述 ：IoC（管制反转：Inverse of Control）是 Spring 容器的内核，AOP、申明式事务等性能在此基础上开花结果。然而 IoC 这个重要的概念却比拟艰涩隐讳，不容易让人顾名思义，这不能不说是一大遗憾。不过 IoC 的确包含很多外延，它波及代码解耦、设计模式、代码优化等问题的考量，咱们打算通过一个小例子来阐明这个概念。
通过实例了解 IoC 的概念
贺岁大片在中国曾经造成了一个传统，每到年底总有多部贺岁大片络绎不绝让人应接不暇。在所有贺岁大片中，张之亮的《墨攻》算是比拟出彩的一部。该片讲述了战国时期墨家人革离帮忙梁国镇压赵国侵略的集体英雄主义故事，恢宏壮阔、浑雄凝重的历史局面相当震撼。其中有一个场景：当刘德华所饰演的墨者革离达到梁国都城下，城上梁国守军问到：“来者何人？”刘德华答复：“墨者革离！”咱们无妨通过一个 Java 类为这个“城门叩问”的场景进行编剧，并借此了解 IoC 的概念：
代码清单 3 -1 MoAttack：通过演员安顿剧本
Java 代码
public class MoAttack {public void cityGateAsk(){
//①演员间接侵入剧本
LiuDeHua ldh = new LiuDeHua();
ldh.responseAsk("墨者革离！");
}
} 咱们会发现以上剧本在①处，作为具体角色饰演者的刘德华间接侵入到剧本中，使剧本和演员间接耦合在一起。
一个理智的编剧在剧情创作时应围绕故事的角色进行，而不应思考角色的具体饰演者，这样才可能在剧本投拍时自在地遴选任何适宜的演员，而非绑定在刘德华一人身上。通过以上的剖析，咱们晓得须要为该剧本主人公革离定义一个接口：
代码清单 3 -2 MoAttack：引入剧本角色
public class MoAttack {public void cityGateAsk() {
//①引入革离角色接口
GeLi geli = new LiuDeHua();
//②通过接口发展剧情
geli.responseAsk("墨者革离！");
}
} 在①处引入了剧本的角色——革离，剧本的情节通过角色开展，在拍摄时角色由演员饰演，如②处所示。因而墨攻、革离、刘德华三者的类图关系如图 3 2 所示：
可是，从图 3 2 中，咱们能够看出 MoAttack 同时依赖于 GeLi 接口和 LiuDeHua 类，并没有达到咱们所冀望的剧本仅依赖于角色的目标。然而角色最终必须通过具体的演员能力实现拍摄，如何让 LiuDeHua 和剧本无关而又能实现 GeLi 的具体动作呢？当然是在影片投拍时，导演将 LiuDeHua 安顿在 GeLi 的角色上，导演将剧本、角色、饰演者装配起来。
通过引入导演，使剧本和具体饰演者解耦了。对应到软件中，导演像是一个拆卸器，安顿演员表演具体的角色。
当初咱们能够反过来解说 IoC 的概念了。IoC（Inverse of Control）的字面意思是管制反转，它包含两个内容：
其一是管制
其二是反转
那到底是什么货色的“管制”被“反转”了呢？对应到后面的例子，“管制”是指抉择 GeLi 角色扮演者的控制权；“反转”是指这种控制权从《墨攻》剧本中移除，转交到导演的手中。对于软件来说，即是某一接口具体实现类的抉择控制权从调用类中移除，转交给第三方决定。
因为 IoC 的确不够单刀直入，因而业界曾进行了宽泛的探讨，最终软件界的泰斗级人物 Martin Fowler 提出了 DI（依赖注入：Dependency Injection）的概念用以代替 IoC，即让调用类对某一接口实现类的依赖关系由第三方（容器或合作类）注入，以移除调用类对某一接口实现类的依赖。“依赖注入”这个名词显然比“管制反转”间接明了、易于了解。
IoC 的类型
从注入办法上看，次要能够划分为三种类型：构造函数注入、属性注入和接口注入。Spring 反对构造函数注入和属性注入。上面咱们持续应用以上的例子阐明这三种注入办法的区别。
构造函数注入
在构造函数注入中，咱们通过调用类的构造函数，将接口实现类通过构造函数变量传入，如代码清单 3 - 3 所示：
代码清单 3 -3 MoAttack：通过构造函数注入革离扮演者
public class MoAttack {
private GeLi geli;
//①注入革离的具体扮演者
public MoAttack(GeLi geli){this.geli = geli;}
public void cityGateAsk(){geli.responseAsk("墨者革离！");
}
} MoAttack 的构造函数不关怀具体是谁表演革离这个角色，只有在①处传入的扮演者按剧本要求实现相应的表演即可。角色的具体扮演者由导演来安顿，如代码清单 3 - 4 所示：
代码清单 3 -4 Director：通过构造函数注入革离扮演者
public class Director {public void direct(){
//①指定角色的扮演者
GeLi geli = new LiuDeHua();
//②注入具体扮演者到剧本中
MoAttack moAttack = new MoAttack(geli);
moAttack.cityGateAsk();}
} 在①处，导演安顿刘德华饰演革离的角色，并在②处，将刘德华“注入”到墨攻的剧本中，而后开始“城门叩问”剧情的上演工作。
属性注入
有时，导演会发现，尽管革离是影片《墨攻》的第一配角，但并非每个场景都须要革离的呈现，在这种状况下通过构造函数注入相当于每时每刻都在革离的饰演者在场，可见并不得当，这时能够思考应用属性注入。属性注入能够有选择地通过 Setter 办法实现调用类所需依赖的注入，更加灵便不便：
代码清单 3 -5 MoAttack：通过 Setter 办法注入革离扮演者
public class MoAttack {
private GeLi geli;
//①属性注入办法
public void setGeli(GeLi geli) {this.geli = geli;}
public void cityGateAsk() {geli.responseAsk("墨者革离");
}
} MoAttack 在①处为 geli 属性提供一个 Setter 办法，以便让导演在须要时注入 geli 的具体扮演者。
代码清单 3 -6 Director：通过 Setter 办法注入革离扮演者
public class Director {public void direct(){GeLi geli = new LiuDeHua();
MoAttack moAttack = new MoAttack();
//①调用属性 Setter 办法注入
moAttack.setGeli(geli);
moAttack.cityGateAsk();}
} 和通过构造函数注入革离扮演者不同，在实例化 MoAttack 剧本时，并未指定任何扮演者，而是在实例化 MoAttack 后，在须要革离出场时，才调用其 setGeli()办法注入扮演者。依照相似的形式，咱们还能够别离为剧本中其余诸如梁王、巷淹中等角色提供注入的 Setter 办法，这样，导演就能够依据所拍剧段的不同，注入相应的角色了。
接口注入
将调用类所有依赖注入的办法抽取到一个接口中，调用类通过实现该接口提供相应的注入办法。为了采取接口注入的形式，必须先申明一个 ActorArrangable 接口：
public interface ActorArrangable {void injectGeli(GeLi geli);
} 而后，MoAttack 实现 ActorArrangable 接口提供具体的实现：
代码清单 3 -7 MoAttack：通过接口办法注入革离扮演者
private GeLi geli;
//①实现接口办法
public void injectGeli (GeLi geli) {this.geli = geli;}
public void cityGateAsk() {geli.responseAsk("墨者革离");
}
} Director 通过 ActorArrangable 的 injectGeli()办法实现扮演者的注入工作。
代码清单 3 -8 Director：通过接口办法注入革离扮演者
public class Director {public void direct(){GeLi geli = new LiuDeHua();
MoAttack moAttack = new MoAttack();
moAttack. injectGeli (geli);
moAttack.cityGateAsk();}
} 因为通过接口注入须要额定申明一个接口，减少了类的数目，而且它的成果和属性注入并无本质区别，因而咱们不提倡采纳这种形式。
通过容器实现依赖关系的注入
尽管 MoAttack 和 LiuDeHua 实现理解耦，MoAttack 毋庸关注角色实现类的实例化工作，但这些工作在代码中仍然存在，只是转移到 Director 类中而已。假如某一制片人想扭转这一场面，在抉择某个剧本后，心愿通过一个“海选”或者第三中介机构来抉择导演、演员，让他们各司其职，那剧本、导演、演员就都实现解耦了。
所谓媒体“海选”和第三方中介机构在程序畛域即是一个第三方的容器，它帮忙实现类的初始化与拆卸工作，让开发者从这些底层实现类的实例化、依赖关系拆卸等工作中脱离进去，专一于更有意义的业务逻辑开发工作。这无疑是一件令人向往的事件，Spring 就是这样的一个容器，它通过配置文件或注解形容类和类之间的依赖关系，主动实现类的初始化和依赖注入的工作。上面是 Spring 配置文件的对以上实例进行配置的配置文件片断：
Xml 代码
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<!--①实现类实例化 -->
<bean id="geli" class="LiuDeHua"/>
<bean id="moAttack" class="com.baobaotao.ioc.MoAttack"
p:geli-ref="geli"/><!--②通过 geli-ref 建设依赖关系 -->
</beans> 通过 new XmlBeanFactory(“beans.xml”)等形式即可启动容器。在容器启动时，Spring 依据配置文件的形容信息，主动实例化 Bean 并实现依赖关系的拆卸，从容器中即可返回准备就绪的 Bean 实例，后续可间接应用之。
Spring 为什么会有这种“神奇”的力量，仅凭一个简略的配置文件，就能魔法般地实例化并拆卸好程序所用的 Bean 呢？这种“神奇”的力量归功于 Java 语言自身的类反射性能。