【Spring系列】- IoC容器的两阶段_ioc容器的两大阶段-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_68383079/article/details/145926604

【Spring系列】- IoC容器的两阶段

文章目录

【Spring系列】- IoC容器的两阶段

一、IoC容器的两阶段

Spring的IoC容器的作用，以某种方式加载Configuration Metadata（通常也就是XML格式的配置信息），然后根据这些信息绑定整个系统的对象，最终组装成一个可用的基于轻量级容器的应用系统

Spring的IoC容器实现以上功能的过程，基本上可以按照类似的流程划分为两个阶段：

在这里插入图片描述

1. 容器启动阶段

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

2. Bean实例化阶段

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

二、“插手”容器的启动

Spring提供了BeanFactoryPostProcessor容器扩展机制，用于在容器实例化相应对象之前，对注册到容器的BeanDefinition所保存的信息做相应的修改，比如修改其中bean的属性、增加其他信息等

如果要自定义实现BeanFactoryPostProcessor，通常需要实现org.springframework.beans.factory.config.BeanFactoryPostProcessor接口
又因为一个容器可能拥有多个BeanFactoryPostProcessor，可能需要实现类同时实现Spring的org.springframework.core.Ordered接口，以保证各个BeanFactoryPostProcessor按预定顺序执行
但很少自己去实现某个BeanFactoryPostProcessor
两个比较常用的BeanFactoryPostProcessor
- org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
- org.springframework.beans.factory.config.PropertyOverrideConfigurer

可以通过两种方式来应用BeanFactoryPostProcessor，分别针对IoC容器BeanFactory和ApplicationContext

对于BeanFactory来说，需要用手动方式应用所有的BeanFactoryPostProcessor

// 声明将被后处理的BeanFactory实例
ConfigurableListableBeanFactory beanFactory = new XmlBeanFactory(new 
                                              		ClassPathResource("配置文件路径")); 
// 声明要使用的BeanFactoryPostProcessor 
PropertyPlaceholderConfigurer propertyPostProcessor = new 
    												PropertyPlaceholderConfigurer(); 
propertyPostProcessor.setLocation(new ClassPathResource("...")); 
// 执行后处理操作
propertyPostProcessor.postProcessBeanFactory(beanFactory);

对于ApplicationContext，它可以自动识别配置文件中的BeanFactoryPostProcessor并应用它

<beans> 
 <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
	<property name="locations"> 
		...
	</property> 
 </bean> 
	... 
</beans>

Spring提供的三种不同的BeanFactoryPostProcessor的实现：

1. PropertyPlaceholderConfigurer

通常会将一些数据库连接信息、邮件服务器等相关信息单独配置到一个properties文件中，这样，如果因系统资源变动的话，只需要关注这些简单properties配置文件即可，以免部署或者维护期间因为改动繁杂的XML配置文件而出现问题

PropertyPlaceholderConfigurer允许我们在XML配置文件中使用占位符（PlaceHolder），并将这些占位符所代表的资源单独配置到简单的properties文件中来加载

这里，这些占位符所代表的资源，都放在jdbc.properties文件中

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="url"> 
		<value>${jdbc.url}</value> 
	</property> 
	<property name="driverClassName"> 
		<value>${jdbc.driver}</value> 
	</property> 
	<property name="username"> 
 		<value>${jdbc.username}</value> 
 	</property> 
 	<property name="password"> 
 		<value>${jdbc.password}</value> 
 	</property> 
 	<property name="testOnBorrow"> 
 		<value>true</value> 
 	</property>
</bean>

基本机制：
- 当BeanFactory在第一阶段加载完成所有配置信息时，BeanFactory中保存的对象的属性信息还只是以占位符的形式存在，如${jdbc.url}、${jdbc.driver}
- 当PropertyPlaceholderConfigurer作为BeanFactoryPostProcessor被应用时，它会使用properties配置文件中的配置信息来替换相应BeanDefinition中占位符所表示的属性值
- 这样，当进入容器实现的第二阶段实例化bean时，bean定义中的属性值就是最终替换完成的了
- PropertyPlaceholderConfigurer不单会从其配置的properties文件中加载配置项，同时还会检查Java的System类中的Properties。默认情况下，如果properties文件中找不到相应配置项，则到System的Properties中查找

2. PropertyOverrideConfigurer

可以通过PropertyOverrideConfigurer对容器中任何bean的property信息进行覆盖替换
如dataSource定义中，maxActive=100，如果觉得100不合适，那么可以通过PropertyOverrideConfigurer在其相应的properties文件中做如下所示配置：dataSource.maxActive=200。这样，当容器实例化对象的时候，该dataSource对象对应的maxActive值就是200，而不是原来XML配置中的100
需要提供一个PropertyOverrideConfigurer使用的配置文件：
```
<bean class="org.springframework.beans.factory.config.PropertyOverrideConfigurer"> 
	<property name="location" value="pool-adjustment.properties"/> 
</bean>
```
pool-adjustment.properties文件中没有提供的配置项将继续使用原来XML配置中的默认值

3. CustomEditorConfigurer

其他两个BeanFactoryPostProcessor都是通过修改BeanDefinition中的数据进行以达到目的

与它们不同，CustomEditorConfigurer只是辅助性地将后期会用到的信息注册到容器，对BeanDefinition没有做任何变动
容器从XML格式的文件中读取的都是字符串形式，最终应用程序却是由各种类型的对象所构成。要想完成这种由字符串到具体对象的转换，都需要这种转换规则相关的信息，而CustomEditorConfigurer就是帮助我们传达类似信息的
Spring内部通过JavaBean的PropertyEditor来帮助进行String类型到其他类型的转换工作
Spring容器内部在做具体的类型转换的时候，会采用JavaBean框架内默认的PropertyEditor搜寻逻辑，同时，Spring框架还提供了自身实现的一些PropertyEditor：StringArrayPropertyEditor、ClassEditor、FileEditor、LocaleEditor、PatternEditor。大部分位于org.springframework.beans.propertyeditors包下
但当我们需要指定的类型没有包含在以上所提到的PropertyEditor之列时，就需要给出针对这种类型的PropertyEditor实现，并通过通过CustomEditorConfigurer注册自定义的PropertyEditor 到容器
- 虽然可以直接让PropertyEditor实现类去实现java.beans.PropertyEditor接口，不过，通常直接继承java.beans.PropertyEditorSupport类，以避免实现java.beans.PropertyEditor接口的所有方法
- 如果使用的容器是BeanFactory的实现，比如XmlBeanFactory，就需要通过编码手动应用CustomEditorConfigurer到容器
- 如果使用的是ApplicationContext相应实现，因为它会自动识别BeanFactoryPostProcessor并应用，所以只需要在配置文件中配置一下
Spring 2.0之前通常是通过CustomEditorConfigurer的customEditors属性来指定自定义的PropertyEditor。2.0之后，比较提倡使用propertyEditorRegistrars属性来指定自定义的PropertyEditor。不过，这样我们就需要再多做一步工作，就是给出一个org.springframework.beans.PropertyEditorRegistrar的实现

三、bean的一生

在已经可以借助于BeanFactoryPostProcessor来干预容器启动阶段后，我们开始探索下一个阶段，即bean实例化阶段

容器启动之后，并不会马上就实例化相应的bean定义，容器现在仅仅拥有所有对象的BeanDefinition来保存实例化阶段将要用的必要信息。只有当请求方通过BeanFactory的getBean()方法来请求某个对象实例的时候，才有可能触发Bean实例化阶段的活动
BeanFactory的getBean方法可以被客户端对象显式调用，也可以在容器内部隐式地被调用。隐式调用getBean()有如下两种情况：
- 对于BeanFactory来说，对象实例化默认采用延迟初始化。当对象A被请求而需要第一次实例化的时候，如果它所依赖的对象B之前同样没有被实例化，那么容器会先实例化对象A所依赖的对象，即对象B以及对象A依赖的其他还没有实例化的对象
- ApplicationContext启动之后会实例化所有的bean定义。但ApplicationContext依然遵循Spring容器实现流程的两个阶段，只不过它会在启动阶段的活动完成之后，紧接着调用注册到该容器的所有bean定义的实例化方法getBean()
只有当对应某个bean定义的getBean()方法第一次被调用时，Bean实例化阶段的活动才会被触发，进而执行其createBean()方法，第二次被调用则会直接返回容器缓存的第一次实例化完的对象实例（prototype类型bean除外）
Spring容器将对其所管理的对象全部给予统一的生命周期管理，这些被管理的对象完全摆脱了原来那种“new完后被使用，脱离作用域后即被回收”的命运。每个bean在容器中是如何走过其一生：

在这里插入图片描述

1. Bean的实例化与BeanWrapper

容器采用策略模式来决定采用何种方式初始化bean实例。通常，可以通过反射或者CGLIB动态字节码生成来初始化相应的bean实例或者动态生成其子类
- org.springframework.beans.factory.support.InstantiationStrategy定义是实例化策略的抽象接口，其直接子类SimpleInstantiationStrategy实现了简单的对象实例化功能，可以通过反射来实例化对象实例，但不支持方法注入方式的对象实例化
- CglibSubclassingInstantiationStrategy继承了SimpleInstantiationStrategy的以反射方式实例化对象的功能，并且通过CGLIB的动态字节码生成功能，该策略实现类可以动态生成某个类的子类，进而满足了方法注入所需的对象实例化需求
- 默认情况下，容器内部采用的是CglibSubclassingInstantiationStrategy
容器只要根据相应bean定义的BeanDefintion取得实例化信息，结合CglibSubclassingInstantiationStrategy以及不同的bean定义类型，就可以返回实例化完成的对象实例。但是，返回方式不是直接返回构造完成的对象实例，而是以BeanWrapper对构造完成的对象实例进行包裹，返回相应的 BeanWrapper实例

至此，第一步结束。返回BeanWrapper实例而不是原先的对象实例，就是为了第二步设置对象属性

BeanWrapper接口有一个实现类org.springframework.beans.BeanWrapperImpl。其作用是对某个bean进行包裹，然后对这个包裹的bean进行操作，比如设置或获取bean的相应属性值
BeanWrapper定义继承了org.springframework.beans.PropertyAccessor接口，可以以统一的方式对对象属性进行访问；BeanWrapper定义同时又直接或间接继承了PropertyEditorRegistry和TypeConverter接口
在第一步构造完成对象之后，Spring会根据对象实例构造一个BeanWrapperImpl实例，然后将之前CustomEditorConfigurer注册的PropertyEditor复制一份给BeanWrapperImpl实例（这就是BeanWrapper同时又是PropertyEditorRegistry的原因）。这样，当BeanWrapper转换类型、设置对象属性值时，就不会无从下手了
使用BeanWrapper对bean实例操作很方便，可以免去直接使用Java反射API（Java Reflection API）操作对象实例的烦琐

2. 各色的 Aware接口

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

这些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。在介绍方法注入的时候，我们提到过使用该接口以便每次获取prototype类型bean的不同实例。如果对象声明实现了BeanFactoryAware接口，BeanFactory容器会将自身设置到当前对象实例。这样，当前对象实例就拥有了一个BeanFactory容器的引用，并且可以对这个容器内允许访问的对象按照需要进行访问。

以上几个Aware接口只是针对BeanFactory类型的容器而言，对于ApplicationContext类型的容器，也存在几个Aware相关接口。不过在检测这些接口并设置相关依赖的实现机理上使用的是BeanPostProcessor方式

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接口，则会将自身注入当前对象实例。

3. BeanPostProcessor

BeanPostProcessor的概念容易与BeanFactoryPostProcessor的概念混淆。但BeanPostProcessor是存在于对象实例化阶段，而BeanFactoryPostProcessor则是存在于容器启动阶段

与BeanFactoryPostProcessor通常会处理容器内所有符合条件的BeanDefinition类似，BeanPostProcessor会处理容器内所有符合条件的实例化后的对象实例。该接口声明了两个方法，分别在两个不同的时机执行

public interface BeanPostProcessor{
    Object postProcessBeforeInitialization(Object bean, String beanName) throws 
 																	BeansException; 
 	Object postProcessAfterInitialization(Object bean, String beanName) throws 
        															BeansException;
}

postProcessBeforeInitialization()方法是BeanPostProcessor前置处理这一步将会执行的方法，postProcessAfterInitialization()则是BeanPostProcessor后置处理那一步将会执行的方法。BeanPostProcessor的两个方法中都传入了原来的对象实例的引用，这为扩展容器的对象实例化过程中的行为提供了极大的便利，几乎可以对传入的对象实例执行任何的操作
通常比较常见的使用BeanPostProcessor的场景，是处理标记接口实现类，或者为当前对象提供代理实现。ApplicationContext对应的那些Aware接口实际上就是通过BeanPostProcessor的方式进行处理的。当ApplicationContext中每个对象的实例化过程走到BeanPostProcessor前置处理这一步时，ApplicationContext容器会检测到之前注册到容器的ApplicationContextAwareProcessor这个BeanPostProcessor的实现类，然后就会调用其postProcessBeforeInitialization()方法，检查并设置Aware相关依赖
除了检查标记接口以便应用自定义逻辑，还可以通过BeanPostProcessor对当前对象实例做更多的处理。比如替换当前对象实例或者字节码增强当前对象实例等。Spring的AOP则更多地使用BeanPostProcessor来为对象生成相应的代理对象，如org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator。BeanPostProcessor是容器提供的对象实例化阶段的强有力的扩展点

4. InitializingBean和 init-method

org.springframework.beans.factory.InitializingBean是容器内部广泛使用的一个对象生命周期标识接口。该接口定义很简单，其作用在于，在对象实例化过程调用过“BeanPostProcessor的前置处理”之后，会接着检测当前对象是否实现了InitializingBean接口，如果是，则会调用它的afterPropertiesSet()方法进一步调整对象实例的状态
虽然该接口在Spring容器内部广泛使用，但如果真的让我们的业务对象实现这个接口，则显得Spring容器比较具有侵入性。所以，Spring还提供了另一种方式来指定自定义的对象初始化操作，那就是在XML配置的时候，使用的init-method属性，保证init-method=的方法在class=的类中先被执行
可以认为在InitializingBean和init-method中任选其一就可以帮你完成类似的初始化工作。除非需要在同一个业务对象上按照先后顺序执行两个初始化方法。这个时候，就只好在同一对象上既实现InitializingBean的afterPropertiesSet()，又提供自定义初始化方法并在init-method指定了
通过init-method，系统中业务对象的自定义初始化操作可以以任何方式命名，而不再受制于InitializingBean的afterPropertiesSet()。如果系统开发过程中规定：所有业务对象的自定义初始化操作都必须以init()命名，为了省去挨个的设置init-method这样的烦琐，我们还可以通过最顶层的的default-init-method统一指定这一init()方法名

5. DisposableBean与 destroy-method

当所有的一切，该设置的设置，该注入的注入，该调用的调用完成之后，容器将检查singleton类型的bean实例，看其是否实现了org.springframework.beans.factory.DisposableBean接口。或者其对应的bean定义是否通过的destroy-method属性指定了自定义的对象销毁方法。如果是，就会为该实例注册一个用于对象销毁的回调（Callback），以便在这些singleton类型的对象实例销毁之前，执行销毁逻辑
与InitializingBean和init-method用于对象的自定义初始化相对应，DisposableBean和destroy-method为对象提供了执行自定义销毁逻辑的机会。最常见到的该功能的使用场景就是在Spring容器中注册数据库连接池，在系统退出后，连接池应该关闭，以释放相应资源
不过，这些自定义的对象销毁逻辑，在对象实例初始化完成并注册了相关的回调方法之后，并不会马上执行。回调方法注册后，返回的对象实例即处于使用状态，只有该对象实例不再被使用的时候，才会执行相关的自定义销毁逻辑，此时通常也就是Spring容器关闭的时候
但Spring容器在关闭之前，不会聪明到自动调用这些回调方法。所以，需要我们告知容器，在哪个时间点来执行对象的自定义销毁方法。对于BeanFactory容器来说，需要在独立应用程序的主程序退出之前，或者其他被认为是合适的情况下，调用ConfigurableBeanFactory提供的destroySingletons()方法销毁容器中管理的所有singleton类型的对象实例。不调用destroySingletons()方法，则销毁逻辑形同虚设
对于ApplicationContext容器，AbstractApplicationContext为我们提供了registerShutdownHook()方法，该方法底层使用标准的Runtime类的addShutdownHook()方式来调用相应bean对象的销毁逻辑，从而保证在Java虚拟机退出之前，这些singtleton类型的bean对象实例的自定义销毁逻辑会被执行
所有这些规则不包含prototype类型的bean实例，因为prototype对象实例在容器实例化并返回给请求方之后，容器就不再管理这种类型对象实例的生命周期了