第 4 章 Spring IoC容器之BeanFactory

Spring 的 IoC 容器是一个提供 IoC 支持的轻量级容器，除了基本的 IoC 支持，它作为轻量级容器还提供了 IoC 之外的支持。

Spring 提供了两种容器类型：BeanFactory 和 ApplicationContext：

1. BeanFactory，基础类型 IoC 容器，提供完整的 IoC 服务支持。如果没有特殊指定，默认采用延迟初始化策略（lazy-load）。所以容器启动初始速度较快。
2. ApplicationContext，在 BeanFactory 基础上构建的相对高级的容器实现，除了 BeanFactory 的所有支持，还提供了其他高级特性，如事件发布、国际化信息支持等。 ApplicationContext 所管理的对象，在该容器启动之后默认全部初始化并绑定完成。

BeanFactory 肯定会公开一个取得组装完成的对象的方法接口。

public interface BeanFactory {String FACTORY_BEAN_PREFIX = "&";Object getBean(String name) throws BeansException;Object getBean(String name, Class requiredType) throws BeansException;/*** @since 2.5*/Object getBean(String name, Object[] args) throws BeansException;boolean containsBean(String name);boolean isSingleton(String name) throws NoSuchBeanDefinitionException;/*** @since 2.0.3*/boolean isPrototype(String name) throws NoSuchBeanDefinitionException;/*** @since 2.0.1*/boolean isTypeMatch(String name, Class targetType) throws NoSuchBeanDefinitionException;Class getType(String name) throws NoSuchBeanDefinitionException;String[] getAliases(String name);
}

4.1 拥有 BeanFactory 之后的生活

之前我们的系统业务对象需要自己去“拉”（Pull）所依赖的业务对象，有了 BeanFactory 之类的 IoC 容器之后，需要依赖什么就让 BeanFactory 为我们推过来（Push）过来就行了。

4.2 BeanFactory 的对象注册与依赖绑定方式

4.2.1 直接编码方式

BeanFactory 接口只定义如何访问容器内管理的 Bean 的方法，BeanDefinitionRegistry 才提供 Bean 注册管理的角色。所以 IoC 容器在实现 BeanFactory 的同时，还需要实现 BeanDefinitionRegistry。

每个一个受管的对象，在容器中都会有一个 BeanDefinition 的实例（instance）与之相对应，该 BeanDefinition 的实例负责保存对象的所有必要信息，包括其对应的对象的 class 类型、是否是抽象类、构造方法参数以及其他属性等。当客户端向 BeanFactory 请求相应对象的时候，BeanFactory 会通过这些信息为客户端返回一个完备可用的对象实例。

4.2.2 外部配置文件方式

Spring 的 IoC 容器支持两个配置文件格式：Properties 文件格式和 XML 文件格式。

通常情况下，需要根据不同的外部配置文件格式，给出相应的 BeanDefinitionReader 实现类，由 BeanDefinitionReader 的相应实现类负责将配置文件内容读取并映射到 BeanDefinition，然后将BeanDefinition 注册到一个 BeanDefinitionRegistry，之后，完成 Bean 的注册和加载。

4.2.3 注解方式

适用于 Spring 2.5 以及 Java 5 或者更高版本。

<context:component-scan/>会到指定的包 (package)下面扫描标注有@Component的类，将它们添加到容器进行管理，并根据它们所标注的@Autowired为这些类注入符合条件的依赖对象。

public static void main(String[] args) {ApplicationContext ctx = new ClassPathXmlApplicationContext("配置文件路径");FXNewsProvider newsProvider = (FXNewsProvider) ctx.getBean("FXNewsProvider");newsProvider.getAndPersistNews();
}

4.3 BeanFactory 的 XML 之旅

4.3.1 和

4.3.2 孤孤单单一个人

4.3.3 Help Me, Help You

4.3.4 继承？我也会！

<bean id="superNewsProvider" class="..FXNewsProvider"><property name="newsListener"><ref bean="djNewsListener"/></property><property name="newPersistener"><ref bean="djNewsPersister"/></property>
</bean>
<bean id="subNewsProvider" parent="superNewsProvider" class="..SpecificFXNewsProvider"><property name="newsListener"><ref bean="specificNewsListener"/></property>
</bean>

我们在声明 subNewsProvider 的时候，使用了 parent 属性，将其值指定为 superNewsProvider，这样就继承了 superNewsProvider 定义的默认值。

<bean id="newsProviderTemplate" abstract="true"><property name="newPersistener"><ref bean="djNewsPersister"/></property>
</bean><bean id="superNewsProvider" parent="newsProviderTemplate" class="..FXNewsProvider"><property name="newsListener"><ref bean="djNewsListener"/></property> 
</bean><bean id="subNewsProvider" parent="newsProviderTemplate" class="..SpecificFXNewsProvider"><property name="newsListener"><ref bean="specificNewsListener"/></property>
</bean>

newsProviderTemplate 的 bean 定义通过 abstract 属性声明为 true，说明这个 bean 定义不需要实例化，也是可以不指定 class 属性的少数场景之一。

默认情况下，ApplicationContext 会在容器启动的时候就对其管理的所有 bean 进行实例化，只有标志为 abstract 的 bean 除外。

4.3.5 bean 的 scope

scope 用来场景容器中的对象所应该处的限定场景或者说该对象的存活时间，即容器在对象进入其相应的 scope 之前，生成并装配这些对象，在该对象不再处于这些 scope 的限定之后，容器通常会销毁这些对象。

1. singleton：默认 scope，标记为 singleton 的 bean 对象，在容器中只存在一个实例，所有对该对象的引用将共享这个实例。该实例从容器启动，并因为第一次被请求而初始化之后，将一直存活到容器退出，也就是说，它与 IoC 容器“几乎”拥有相同的“寿命”。
2. prototype：对于标记为 prototype 的 bean 对象，容器在接到该类型对象的请求的时候，每次都会重新生成一个新的对象实例给请求方。之后容器便不再拥有当前返回对象的引用，任由其“自生自灭”。
3. request、session 和 global session：只适用于 Web 应用程序。
4. 自定义 scope： 实现 org.springframework.beans.factory.config.Scope 接口。

4.3.6 工厂方法与 FacatoryBean

4.4 容器背后的秘密

4.4.1 “战略性观望”

1. 容器启动阶段

容器启动伊始，首先会通过某种途径加载 Configuration MetaData。除了代码方式比较直接，在大部分情况下，容器需要依赖某些工具类（BeanDefinitionReader）对加载的 Configuration MetaData 进行解析和分析，并将分析后的信息编组为相应的 BeanDefinition。最后把这些保存了 bean 定义必要信息的 BeanDefinition，注册到相应的 BeanDefinitionRegistry，这样容器启动工作就完成了。

2. Bean 实例化阶段

经过第一阶段，现在所有的 bean 定义信息都通过 BeanDefinition 的方式注册到了 BeanDefinitionRegistry 中。当某个请求方通过容器的 getBean 方法明确地请求某个对象，或者因依赖关系容器需要隐式地调用 getBean 方法时，就会触发第二阶段的活动。
该阶段，容器会首先检查所请求的对象之前是否已经初始化。如果没有，则会根据注册的BeanDefinition所提供的信息实例化被请求对象，并为其注入依赖。如果该对象实现了某些回调接口，也会根据回调接口的要求来装配它。当该对象装配完毕之后，容器会立即将其返回请求方使用。

4.4.2 插手“容器的启动”

BeanFactoryPostProcessor，允许我们在容器实例化相应对象之前，对注册到容器的 BeanDefinition 所保存的信息做相应的修改。

4.4.3 了解 bean 的一生

1. Bean 的实例化 与 BeanWrapper

容器在内部实现时，采用“策略模式（Strategy Pattern）”来决定采用何种方式初始化 bean 实例。通常可以通过反向或者 CGLIB 动态字节码生成来初始化相应的 bean 实例或者动态生成其子类。默认采用 CglibSubclassingInstantiationStrategy 生成对象经过“点缀”过的 BeanWrapper 实例。

2. 各色的 Aware 接口

当对象实例化完成并且相关属性以及依赖设置完成之后，Spring 容器会检查当前对象实例是否实现了一系列的以 Aware 命令结尾的接口定义。如果是，则将这些 Aware 接口定义中规定的依赖注入给当前对象实例。

3. BeanPostProcessor

BeanPostProcessor 会处理容器内所有符合条件的实例化后的对象实例。

4. 自定义 BeanPostProcessor

5. InitializingBean 和 init-method

6. DisposableBean 与 destory-method

4.5 小结