一、概述
1.1、IoC是什么
Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。如何理解好Ioc呢？理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：
●谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对 象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。
●为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
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的理解应该是有很大帮助的。
二、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控制，所以这叫控制反转。
IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的。比如对象A需要操作数据库，以前我们总是要在A中自己编写代码来获得一个Connection对象，有了 spring我们就只需要告诉spring，A中需要一个Connection，至于这个Connection怎么构造，何时构造，A不需要知道。在系统运行时，spring会在适当的时候制造一个Connection，然后像打针一样，注射到A当中，这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行，而这个Connection是由spring注入到A中的，依赖注入的名字就这么来的。
三、Spring IoC总览
Spring的IoC容器在实现控制反转和依赖注入的过程中,可以划分为两个阶段:
- 容器启动阶段
- Bean实例化阶段
四、容器启动阶段的讲解
1、IOC的技术实现方式
“伙计，来杯啤酒！”当你来到酒吧，想要喝杯啤酒的时候，通常会直接招呼服务生，让他为你
送来一杯清凉解渴的啤酒。同样地，作为被注入对象，要想让IoC容器为其提供服务，并
将所需要的被依赖对象送过来，也需要通过某种方式通知对方。
- 如果你是酒吧的常客，或许你刚坐好，服务生已经将你最常喝的啤酒放到了你面前
- 如果你是初次或偶尔光顾，也许你坐下之后还要招呼服务生，“Waiter,Tsingdao, please.”
- 还有一种可能，你根本就不知道哪个牌子是哪个牌子，这时，你只能打手势或干脆画出商标
图来告诉服务生你到底想要什么了吧！
不管怎样，你终究会找到一种方式来向服务生表达你的需求，以便他为你提供适当的服务。那么，在IoC模式中，被注入对象又是通过哪些方式来通知IoC容器为其提供适当服务的呢?
常用的有两种方式：构造方法注入和setter方法注入，还有一种已经退出历史舞台的接口注入方式，下面就比较一下三种注入方式：
- 接口注入。从注入方式的使用上来说，接口注入是现在不甚提倡的一种方式，基本处于“退
役状态”。因为它强制被注入对象实现不必要的接口，带有侵入性。而构造方法注入和setter
方法注入则不需要如此。
- 构造方法注入。这种注入方式的优点就是，对象在构造完成之后，即已进入就绪状态，可以
马上使用。缺点就是，当依赖对象比较多的时候，构造方法的参数列表会比较长。而通过反
射构造对象的时候，对相同类型的参数的处理会比较困难，维护和使用上也比较麻烦。而且
在Java中，构造方法无法被继承，无法设置默认值。对于非必须的依赖处理，可能需要引入多个构造方法，而参数数量的变动可能造成维护上的不便。
- setter方法注入。因为方法可以命名，所以setter方法注入在描述性上要比构造方法注入好一些。 另外，setter方法可以被继承，允许设置默认值，而且有良好的IDE支持。缺点当然就是对象无法在构造完成后马上进入就绪状态。
其实，这些操作都是由IoC容器来做的，我们所要做的，就是调用IoC容器来获得对象而已。
2、IoC容器及IoC容器如何获取对象间的依赖关系
Spring中提供了两种IoC容器：
- BeanFactory
- ApplicationContext
ApplicationContext是BeanFactory的子类，所以，ApplicationContext可以看做更强大的BeanFactory，他们两个之间的区别如下：
- BeanFactory。基础类型IoC容器，提供完整的IoC服务支持。如果没有特殊指定，默认采用延迟初始化策略（lazy-load）。只有当客户端对象需要访问容器中的某个受管对象的时候，才对该受管对象进行初始化以及依赖注入操作。所以，相对来说，容器启动初期速度较快，所需要的资源有限。对于资源有限，并且功能要求不是很严格的场景，BeanFactory是比较合适的IoC容器选择。
- ApplicationContext。ApplicationContext在BeanFactory的基础上构建，是相对比较高级的容器实现，除了拥有BeanFactory的所有支持，ApplicationContext还提供了其他高级特性，比如事件发布、国际化信息支持等，ApplicationContext所管理的对象，在该类型容器启动之后，默认全部初始化并绑定完成。所以，相对于BeanFactory来说，ApplicationContext要求更多的系统资源，同时，因为在启动时就完成所有初始化，容
器启动时间较之BeanFactory也会长一些。在那些系统资源充足，并且要求更多功能的场景中，ApplicationContext类型的容器是比较合适的选择。
但是我们无论使用哪个容器，我们都需要通过某种方法告诉容器关于对象依赖的信息，只有这样，容器才能合理的创造出对象，否则，容器自己也不知道哪个对象依赖哪个对象，如果胡乱注入，那不是创造出一个四不像。理论上将我们可以通过任何方式来告诉容器对象依赖的信息，比如我们可以通过语音告诉他，但是并没有人实现这样的代码，所以我们还是老老实实使用Spring提供的方法吧：
- 通过最基本的文本文件来记录被注入对象和其依赖对象之间的对应关系
- 通过描述性较强的XML文件格式来记录对应信息
- 通过编写代码的方式来注册这些对应信息
- 通过注解方式来注册这些对应信息
虽然提供了四种方式，但是我们一般只使用xml文件方式和注解方式，所以，就重点讲解这两种方式。
3、万里长征第一步：加载配置文件信息
我们在介绍了一些基本的概念后，终于要迎来容器创造对象的第一步，那就是加载配置文件信息，我们已经知道我们主要通过xml文件和注解的方式来告诉容器对象间的依赖信息，那么容器怎么才能从xml配置文件中得到对象依赖的信息呢？且听我慢慢道来。（这里的容器指的是BeanFactory，至于ApplicationContext，以后会有相应的讲解）
在BeanFactory容器中，每一个注入对象都对应一个BeanDefinition实例对象，该实例对象负责保存注入对象的所有必要信息，包括其对应的对象的class类型、是否是抽象类、构造方法参数以及其他属性等。当客户端向BeanFactory请求相应对象的时候，BeanFactory会通过这些信息为客户端返回一个完备可用的对象实例。
那么BeanDefinition实例对象的信息是从哪而来呢？这里就要引出一个专门加载解析配置文件的类了，他就是BeanDefinitionReader，对应到xml配置文件，就是他的子类XmlBeanDefinitionReader，XmlBeanDefinitionReader负责读取Spring指定格式的XML配置文件并解析，之后将解析后的文件内容映射到相应的BeanDefinition。在我们了解了怎么得到对象依赖的信息，并知道这些信息最终保存在BeanDefinition之后，我们可能会想，那么容器怎么通过这些信息创造出一个可用的对象了呢？
4、笼统讲解容器中对象的创建和获取
我们把容器创造一个对象的过程称为Bean的注册，实现Bean的注册的接口为BeanDefinitionRegistry，其实BeanFactory只是一个接口，他定义了如何获取容器内对象的方法，我们所说的BeanFactory容器，其实是这个接口的是实现类，但是具体的BeanFactory实现类同时也会实现BeanDefinitionRegistry接口，这样我们才能通过容器注册对象和获取对象。我们通过BeanDefinitionRegistry的rsgisterBeanDefinition(BeanDefinition beandefinition)方法来进行Bean的注册。
打个比方说，BeanDefinitionRegistry就像图书馆的书架，所有的书是放在书架上的。虽然你还书或者借书都是跟图书馆（也就是BeanFactory）打交道，但书架才是图书馆存放各类图书的地方。所以，书架相对于图书馆来说，就是它的BeanDefinitionRegistry。
我们来总结一下一个Bean是如何注册到容器中，然后被我们获取的：
首先我们需要配置该Bean的依赖信息，通常我们配置在xml文件中，然后我们通过XmlBeanDefinitionReader读取文件内容，然后将文件内容映射到相应的BeanDefinition，然后我们可以通过BeanFactory和BeanDefinitionRegistry的具体实现类,比如DefaultListableBeanFactory实现Bean的注册和获取。这里放一段代码来演示一下这个过程：
public static void main(String[] args)
{
//创建一个容器
DefaultListableBeanFactory beanRegistry = new DefaultListableBeanFactory();
//调用方法实现Bean的注册
BeanFactory container = (BeanFactory)bindViaCode(beanRegistry);
//通过容器获取对象
FXNewsProvider newsProvider = (FXNewsProvider)container.getBean("djNewsProvider");
}
public static BeanFactory bindViaCode(BeanDefinitionRegistry registry)
{
AbstractBeanDefinition newsProvider = new RootBeanDefinition(FXNewsProvider.class,true);
AbstractBeanDefinition newsListener = new RootBeanDefinition(DowJonesNewsListener.class,true);
AbstractBeanDefinition newsPersister = new RootBeanDefinition(DowJonesNewsPersister.class,true);
// 将bean定义注册到容器中
registry.registerBeanDefinition("djNewsProvider", newsProvider);
registry.registerBeanDefinition("djListener", newsListener);
registry.registerBeanDefinition("djPersister", newsPersister);
// 指定依赖关系
// 1. 可以通过构造方法注入方式
ConstructorArgumentValues argValues = new ConstructorArgumentValues();
argValues.addIndexedArgumentValue(0, newsListener);
argValues.addIndexedArgumentValue(1, newsPersister);
newsProvider.setConstructorArgumentValues(argValues);
// 2. 或者通过setter方法注入方式
MutablePropertyValues propertyValues = new MutablePropertyValues();
propertyValues.addPropertyValue(new ropertyValue("newsListener",newsListener));
propertyValues.addPropertyValue(new PropertyValue("newPersistener",newsPersister));
newsProvider.setPropertyValues(propertyValues);
// 绑定完成
return (BeanFactory)registry;
}
五、Bean的生命周期
1、Bean的实例化和属性设置
当我们完成了容器的启动阶段后，对于BeanFactory来说，并不会马上实例化相应的bean定义。我们知道，容器现在仅仅拥有所有对象的BeanDefinition来保存实例化阶段将要用的必要信息。只有当请求方通过BeanFactory的getBean()方法来请求某个对象实例的时候，才有可能触发Bean实例化阶段的活动BeanFactory的getBean()法可以被客户端对象显式调用，也可以在容器内部隐式地被调用。隐式调用有如下两种情况：
- 对于BeanFactory来说，对象实例化默认采用延迟初始化。通常情况下，当对象A被请求而需要第一次实例化的时候，如果它所依赖的对象B之前同样没有被实例化，那么容器会先实例化对象A所依赖的对象。这时容器内部就会首先实例化对象B，以及对象 A依赖的其他还没有实例化的对象。这种情况是容器内部调用getBean()，对于本次请求的请求方是隐式的。
- ApplicationContext启动之后会实例化所有的bean定义，但ApplicationContext在实现的过程中依然遵循Spring容器实现流程的两个阶段，只不过它会在启动阶段的活动完成之后，紧接着调用注册到该容器的所有bean定义的实例化方法getBean()。这就是为什么当你得到ApplicationContext类型的容器引用时，容器内所有对象已经被全部实例化完成。不信你查一下类org.AbstractApplicationContext的refresh()方法。
容器在实现Bean的实例化的时候，采用“策略模式(Strategy Pattern)"来决定采用何种方式初始化bean实例。通常，可以通过反射或者CGLIB动态字节码生成来初始化相应的bean实例或者动态生成其子类。
这里就涉及到了一些AOP的知识，我们只需要知道在容器中并不是直接通过new的方式来添加对象，而是通过AOP实现机制，创造了一个目标对象的代理对象就可以了，代理对象可以简单理解为目标对象的子类，他要么和目标对象有相同的功能，要么能力比目标对象强大，AOP我会在以后进行详细讲解。
但是容器也并不是直接就创造了一个代理对象，他还把这个代理对象包装了一下，他把代理对象包装成了一个BeanWrapper。
BeanWrapper定义继承了org.springframework.beans.PropertyAccessor接口，可以以统一的方式对对象属性进行访问；BeanWrapper定义同时又直接或者间接继承了PropertyEditorRegistry和TypeConverter接口。不知你是否还记得CustomEditorConfigurer？当把各种PropertyEditor注册给容器时，知道后面谁用到这些PropertyEditor吗？对，就是BeanWrapper！在第一步构造完成对象之后，Spring会根据对象实例构造一个BeanWrapperImpl实例，然后将之前CustomEditorConfigurer注册的PropertyEditor复制一份给BeanWrapperImpl实例（这就是BeanWrapper同时又是PropertyEditorRegistry的原因）。然后我们就可以通过BeanWrapper来为对象设置属性了。
2、Aware接口
到这里图中的前两个过程就已经走完了，接下来，容器会检查当前对象实例是否实现了一系列的以Aware命名结尾的接口定义。如果是，则将这些Aware接口定义中规定的依赖注入给当前对象实例。我们可以看一看这些Aware对象到底规定了什么依赖，对于BeanFactory来说，Aware接口有一下几个：
- org.springframework.beans.factory.BeanNameAware。如果Spring容器检测到当前对象实例实现了该接口，会将该对象实例的bean定义对应的beanName设置到当前对象实例。
- org.springframework.beans.factory.BeanClassLoaderAware。如果容器检测到当前对
象实例实现了该接口，会将对应加载当前bean的Classloader注入当前对象实例。默认会使用加载org.springframework.util.ClassUtils类的Classloader。
- org.springframework.beans.factory.BeanFactoryAware。如果对象声明实现了
BeanFactoryAware接口，BeanFactory容器会将自身设置到当前对象实例。这样，当前对象实例就拥有了一个BeanFactory容器的引用，并且可以对这个容器内允许访问的对象按照需要进行访问。
对于ApplicationContext类型的容器，也存在几个Aware相关接口。如下：
- org.springframework.context.ResourceLoaderAware。 ApplicationContext实现了Spring的ResourceLoader接口。当容器检测到当前对象实例实现了ResourceLoaderAware接口之后，会将当前ApplicationContext自身设置到对象实例，这样当前对象实例就拥有了其所在ApplicationContext容器的一个引用。
- org.springframework.context.ApplicationEventPublisherAware。ApplicationContext
作为一个容器，同时还实现了ApplicationEventPublisher接口，这样，它就可以作为ApplicationEventPublisher来使用。所以，当前ApplicationContext容器如果检测到当前实例化的对象实例声明了ApplicationEventPublisherAware接口，则会将自身注入当前对象。
- org.springframework.context.MessageSourceAware。ApplicationContext通过MessageSource接口提供国际化的信息支持，即I18n（Internationalization）。它自身就实现了MessageSource接口，所以当检测到当前对象实例实现了MessageSourceAware接口，则会将自身注入当前对象实例。
- org.springframework.context.ApplicationContextAware。 如果ApplicationContext容器检测到当前对象实现了ApplicationContextAware接口，则会将自身注入当前对象实例。
在了解了这些Aware接口的功能后，我们可能会想容器是如何实现将Aware接口中规定的依赖注入到已经生成的对象中的呢？这里就要引出我们在容器实例化阶段的扩展点了，那就是BeanPostProcessor
3、BeanPostProcessor
与BeanFactoryPostProcessor通常会处理容器内所有符合条件的BeanDefinition类似，BeanPostProcessor会处理容器内所有符合条件的实例化后的对象实例。
我们已经知道BeanFactoryPostProcessor是在容器启动阶段，对象还未创建之前对创建对象的信息就是BeanDefinition进行了修改，那么BeanPostProcessor是如何对一个已经生成的对象进行扩展的呢，这里当然就要用到AOP了，看来，Spring中的IoC和AOP真是“你中有我，我中有你”啊。
我们ApplicationContext对应的那些Aware接口实际上就是通过BeanPostProcessor的方式进行处理的。当ApplicationContext中每个对象的实例化过程走到BeanPostProcessor前置处理这一步时，ApplicationContext容器会检测到之前注册到容器的ApplicationContextAwareProcessor这个BeanPostProcessor的实现类，然后就会调用其postProcessBeforeInitialization()方法，检查并设置Aware相关依赖。
至于如何将BeanPostProcessor注册到容器中，BeanFactory需要手动的写代码注入，而ApplicationContext可以通过配置文件的方式注入
4、init-method
通俗的将，init-method可以指定我们在容器中的获得的对象在执行任何方法前，先执行那个方法。比如我们在做任何事情前必须要先洗手，那么我可以把洗手定义为init-method，那么我们在做吃饭，睡觉，玩游戏，写代码。。。。之前都会去洗手。
这里只需要保证FXTradeDateCalculator类中有一个setupHolidays方法就可以了。
5、destory-method
和init-method对应，destory-method定义的是在所有这个对象被销毁前，需要做的方法。