spring揭秘总结（一)——spring的Ioc容器

IOC的理念

控制反转，让别人为你服务，让Ioc Service Provider （抽象出来的概念）来为你服务。
理解：对象注入到ioc容器中，称为被注入对象。通常情况下，被注入对象会直接依赖于被依赖对象，但是在IOC中，二者通过IOC service Provice来打交道，被注入对象需要什么，通知到IOC service provice，后者将被依赖对象注入到被注入对象中，从而达到IoC Service Provider为被注入对象服务的目的。从被注入对象的角度看，与之前直接寻求依赖对象相比，依赖对象的取得方式发生了反转，控制权也从被注入对象转到了IoC Service Provider那里。

那么问题是，被注入对象是怎么“通知”到Ioc service Provice它需要依赖的对象是什么，并让其提供适当服务呢？这就是依赖注入的方式。

依赖注入

1、构造方法注入

IoC Service Provider会检查被注入对象的构造方法，取得它所需要的依赖对象列表，进而为其注入相应的对象。同一个对象是不可能被构造两次的，因此，被注入对象的构造乃至其整个生命周期，应该是由IoC Service Provider来管理的。
实用性强，构造完成，直接可以进入就绪状态，马上可以使用。

2、setter注入

是在对象被构造完成之后再通过settter方法注入。

3、接口注入

被注入对象如果想要IoC ServiceProvider为其注入依赖对象，就必须实现某个接口。这个接口提供一个方法，方法中的参数，就是所依赖对象的类型，用来为其注入依赖对象。（入侵性较强，现在不推荐使用）
FXNewsProvider 为了让IoC Service Provider为其注入所依赖的 IFXNewsListener ，首先需要实现IFXNewsListenerCallable 接口，这个接口会声明一个 injectNewsListner 方法（方法名随意），该方法的参数，就是所依赖对象的类型。这样， InjectionServiceContainer 对象，即对应的IoC Service Provider就可以通过这个接口方法将依赖对象注入到被注入对象 FXNewsProvider 当中。

4、基于注解的依赖注入（2.5版本之后）

@Autowired：按照类型注入，属于spring提供的内部注解，要求依赖对象必须可以找到，不然会报错。
@Qualifier：Autowired注入发生类型冲突时，使用该注解标明具体需要依赖的对象名称。
@Resource：遵循byName自动绑定形式，属于JSR250中的注解，IoC容器将根据 @Resource 所指定的名称，到容器中查找 beanName 与之对应的实例，然后将查找到的对象实例注入给 @Resource 所标注的对象。
@componentscan：扫描指定包路径下标注@component注解的类

IoC Service Provider

1、职责

1、业务对象的构建管理
2、业务对象间的依赖绑定
IoC Service Provider通过结合之前构建和管理的所有业务对象，以及各个业务对象间可以识别的依赖关系，将这些对象所依赖的对象注入绑定，从而保证每个业务对象在使用的时候，可以处于就绪状态。

2、管理对象间依赖关系的方式

1、直接编码
2、配置文件（properties或xml文件）
3、元数据方式
通过 @Inject ，我们指明需要IoC Service Provider通过构造方法注入方式，为 FXNewsProvider 注入其所依赖的对
象。

BeanFactory

spring提供的两种容器类型：

1、BeanFactory：采用延迟初始化策略，容器启动初期速度快，所需资源有限
2、ApplicationContext： ApplicationContext 所管理的对象，在该类型容器启动之后，默认全部初始化并绑定完成。

spring提供的自动绑定模式

1、no
容器默认的自动绑定模式，也就是不采用任何形式的自动绑定，完全依赖手工明确配置各个bean之间的依赖关系
2、byName
3、byType
4、constructor
byName 和 byType 类型的自动绑定模式是针对property的自动绑定，而 constructor 类型则是针对构造方法参数的类型而进行的自动绑定，它同样是 byType 类型的绑定模式。
5、autodetect
这种模式是 byType 和 constructor 模式的结合体，如果对象拥有默认无参数的构造方法，容器会优先考虑 byType 的自动绑定模式。否则，会使用 constructor 模式。

bean的作用域（scope）

1、singleton
2、prototype
3、request
4、session
5、global session

FactoryBean

FactoryBean 是Spring容器提供的一种可以扩展容器对象实例化逻辑的接口。
当某些对象的实例化过程过于烦琐，通过XML配置过于复杂，使我们宁愿使用Java代码来完成这个实例化过程的时候，或者，某些第三方库不能直接注册到Spring容器的时候，就可以实现 org.spring-framework.beans.factory.FactoryBean 接口，给出自己的对象实例化逻辑代码。

Ioc容器底层

Ioc容器作用

spring Ioc容器，会议某种方式加载Configuration Metadata（通常就是xml格式的配置信息），然后根据这些信息绑定整个系统的对象，最终组装成一个可用于基于轻量级容器的应用系统。
整个过程分为两个阶段：容器启动阶段和bean实例化阶段

1、容器启动
容器需要依赖某些工具类（ BeanDefinitionReader ）对加载的Configuration MetaData进行解析和分析，并将分析后的信息编组为相应的 BeanDefinition ，最后把这些保存了bean定义必要信息的 BeanDefinition ，注册到相应的 BeanDefinitionRegistry ，这样容器启动工作就完成了。
2、bean实例化阶段
当某个请求方通过容器的 getBean 方法明确地请求某个对象，或者因依赖关系容器需要隐式地调用 getBean 方法时，就会触发第二阶段的活动。（使用BeanFactory容器的情况）
容器会首先检查所请求的对象之前是否已经初始化，没有，就会根据注册的BeanDefinition 所提供的信息实例化被请求对象，并为其注入依赖。如果该对象实现了某些回调接口，也会根据回调接口的要求来装配它。当该对象装配完毕之后，容器会立即将其返回请求方使用。

插手容器启动

pring提供了一种叫做 BeanFactoryPostProcessor 的容器扩展机制。该机制允许我们在容器实例化相应对象之前，对注册到容器的 BeanDefinition 所保存的信息做相应的修改。比如修改其中bean定义的某些属性，为bean定义增加其他信息等。

Bean的一生

容器只要根据相应bean定义的 BeanDefintion 取得实例化信息，结合 CglibSubclassingIns-
tantiationStrategy 以及不同的bean定义类型（反射或CGLIB动态字节码），就可以返回实例化完成的对象实例。但是，返回方式上有些“点缀”。不是直接返回构造完成的对象实例，而是以 BeanWrapper 对构造完成的对象实例进行包裹，返回相应的 BeanWrapper 实例。BeanWarpper接口的实现类BeanWarppreImpl，可以实现对“包装”的bean进行操作，比如设置或者获取bean的相应属性值。
当对象实例化完成并且相关属性以及依赖设置完成之后，Spring容器会检查当前对象实例是否实现了一系列的以 Aware 命名结尾的接口定义。如果是，则将这些 Aware 接口定义中规定的依赖注入给当前对象实例。

ApplicationContext

实现：ClassPathXmlApplicationContext 和 FileSystemXmlApplicationContext 等
ApplicationContext 是Spring在 BeanFactory 基础容器之上，提供的另一个IoC容器实现。它拥有许多 BeanFactory 所没有的特性，包括统一的资源加载策略、国际化信息支持、容器内事件发布以及简化的多配置文件加载功能。