Spring —— 容器内部逻辑

引言

上一篇关于IoC容器的详解《Spring —— IoC 容器详解》真是工程浩大,可以说Spring官网对核心中的核心IOC容器做了非常全面的使用说明,包括在《Spring揭秘》中让我一直没有成功的Method Injection,官网也解决了我的疑惑,并最终实验成功(未来会另起一篇单独对“方法注入”做以总结)。

Spring官网的容器说明虽然全面,但是对于容器内部的处理并未深入解释,因此本篇博客做理论性的补充,总结自王富强老师的《Spring揭秘》第四章——“容器背后的秘密”。而且,本篇文章在工作和面试中更具有理论性的指导意义。

一、概述

Spring容器通过某种方式加载xml(或注解、JavaConfig)中的配置数据,然后根据这些信息绑定整个系统的对象,最终组装成一个可用的基于轻量级容器的应用系统。这个过程分为两个阶段,即容器启动阶段Bean实例化阶段:

1、容器启动阶段(四步:加载、解析、组装BeanDefinition、注册):

容器刚开始启动时,首先加载配置,然后是解析并分析配置信息,将分析后的信息装配到相应的BeanDefinition,最后把将BeanDefinition注册到BeanDefinitionRegistry,启动完成。

总的来说,该阶段所做的工作可以认为是准备性的,重点更加侧重于对象管理信息的收集,一些验证性或辅助性的工作也可以在这个阶段完成。

2、Bean实例化阶段(四步:检查、实例化、装配、生命周期回调):

第一阶段后,所有的bean定义信息都通过BeanDefinition的方式注册到了BeanDefinitionRegistry中。当某个请求方通过getBean()方法明确地请求某个对象,或因依赖关系容器需要隐式地调用getBean方法时,就会触发第二阶段。

容器首先会检查所请求的对象之前是否已经初始化。如果没有,则会根据注册的BeanDefinition所提供的信息实例化被请求对象,并为其注入依赖。如果该对象实现了某些回调接口,也会根据回调接口(Aware)的要求来装配它。当该对象装配完毕之后,容器会立即将其返回请求方使用。

二、容器启动阶段的扩展

Spring提供了一种叫做BeanFactoryPostProcessor的容器扩展机制。

该机制允许我们在容器实例化对象之前,对注册到容器中的BeanDefinition进行修改。相当于在容器实现的第一阶段最后加入一道工序,让我们对最终的BeanDefinition做一些额外的操作,比如修改bean的某些属性,为bean定义增加其他信息等。

如果要自定义BeanFactoryPostProcessor,通常就需要实现该接口,因为一个容器可能拥有多个后处理器,因此可能需要同时实现Ordered接口(如果顺序确实必要)。因为Spring已经提供了几个现成的后处理器实现,因此大多数时候我们很少去实现某个后处理器。其中PropertyPlaceholderConfigurer和PropertyOverrideConfigurer是两个比较常用的BeanFactoryPostProcessor。

1、对于BeanFactory需要手动装配BeanFactoryPostProcessor。

2、对于ApplicationContext,可以自动识别配置中的BeanFactoryPostProcessor。xml配置形式如下:

<bean class=”...PropertyPlaceholderConfigurer”>
// 后处理器的一些属性
</bean>

三、bean的生命周期

容器在启动之后,并不会马上就实例化相应的bean定义。刚刚启动的容器仅仅拥有所有对象的BeanDefinition来保存实例化阶段将会用到的必要信息。

BeanFactory的getBean方法可以被客户端对象显式调用,也可以在容器内隐式调用。

隐式调用有以下两种情况:

1、对于BeanFactory来说,对象实例化默认采用延迟初始化。A依赖B,如果当程序请求A对象时,容器会检测A依赖的B是否已经实例化,如果没有会隐式调用getBean实例化B对象,这对于本次请求者是隐式的。

2、ApplicationContext启动之后会实例化所有的bean定义,在ApplicationContext的实现过程中,依然遵循Spring容器的两个阶段,只不过它会在启动阶段完成后,立刻调用所有bean定义的实例化方法getBean这就是为什么当你得到ApplicationContext类型的容器引用时,容器内所有对象已经被全部实例化完成)。

提示:AbstractBeanFactory类的getBean()方法的完整实现逻辑,和AbstractAutowiredCapableBeanFactory类的createBean()方法的全貌

3.1 Bean的实例化策略与BeanWrapper

容器在内部实现的时候,采用“策略模式”来决定采用何种方式实例化bean。

通常可以通过反射或CGLIB动态字节码生成来实例化相应的bean实例或动态生成其子类。

InstantiationStrategy接口定义了bean的实例化策略

SimpleInstantiationStrategy实现了简单的对象实例化功能,可以通过反射来实例化对象,但不支持方法注入方式的对象实例化。

CglibSubclassingInstantiationStrategy扩展了SimpleInstantiationStrategy,加入了CGLIB的动态字节码生成功能,可以动态的生成某个类的子类,满足了方法注入所需的对象实例化需求。这是容器默认采用的实例化策略。

容器只要根据相应的bean的BeanDefinition,和

CglibSubclassingInstantiationStrategy以及不同的bean定义类型,就可以返回实例化完成的对象实例。但不是直接返回构造完成的对象实例,而是以BeanWrapper对构造完成的bean进行了包裹,返回相应的BeanWrapper实例。到这里,第一步实例化结束。

BeanWrapper接口通常在Spring框架内部使用,它有一个实现类:BeanWrapperImpl,其作用是对某个bean进行“包裹”,然后对这个“包裹”的bean进行操作,比如设置或者获取bean的相应属性值。第一步结束后返回BeanWrapper实例而不是原先的对象实例,其目的就是为了第二步的“设置对象属性”。

BeanWrapper继承了PropertyAccessor接口,可以以统一的方式对对象属性进行访问,同时又继承了PropertyEditorRegistry和TypeConverter接口(间接)。当把各种PropertyEditor注册给容器时,后面就会被BeanWrapper用到。

在第一步构造完成对象之后,Spring会根据对象实例构造一个BeanWrapperImpl实例,然后将之前CustomEditorConfigurer注册的PropertyEditor复制一份给BeanWrapperImpl实例,这就是为什么BeanWrapper同时也是PropertyEditorRegistry,这样,BeanWrapper就可以完成类型转换、设置对象属性值等操作了。

以下是两段分别通过BeanWrapper和Java反射API来设置对象属性值和获取属性值的代码片段,相比于Java反射API,Spring提供的BeanWrapper操作起来更加流程简洁:

BeanWrapper方式:

Object provider = Class.forName(“package.name.FXNewsProvider”).newInstance();
Object listener = Class.forName(“...DowJonesNewsListener”).newInstance();
Object persister = Class.forName(“...DowJonesNewsPersister”).newInstance();
BeanWrapper newsProvider = new BeanWrapperImpl(provide);
newsProvider.setPropertyValue(“newsListener”, listener);
newsProvider.setPropertyValue(“newsPersister”, persister);
assertTrue(newsProvider.getWrapperedInstance() instanceof FXNewsProvider);
assertSame(provider, newsProvider.getWrapperedInstance());
assertSame(listener, newsProvider.getPropertyValue(“newsListener”));

Java反射API方式:

Object provider = Class.forName(“package.name.FXNewsProvider”).newInstance();
Object listener = Class.forName(“...DowJonesNewsListener”).newInstance();
Object persister = Class.forName(“...DowJonesNewsPersister”).newInstance();
Class providerClazz= provider.getClass();
Field listenerField = providerClazz.getField(“newsListener”);
listenerField.set(provider , listener);// 只演示listener属性设置,persister类似
assertSame(listener, listenerField.get(provider));

可以看出,Java反射API的方式在使用上相对混乱,且不便于记忆,而且还有紧随其后的各种异常需要处理(上面并未写出)。

3.2 Aware生命周期回调

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

常见的Aware接口有:

1、BeanNameAware,容器会将bean定义对应的beanName设置到当前对象的实例。

2、BeanClassLoaderAware,容器会将对应加载当前bean的Classloader注入到当前对象实例。默认会使用加载springframework..ClassUtils类的Classloader。

3、BeanFactoryAware,BeanFactory容器会将自身设置到当前对象实例。当前对象就拥有了一个BeanFactory容器的引用,并且可以对这个容器内允许访问的对象按照需要进行访问。

这三个Aware接口只针对BeanFactory类型的容器而言,对于ApplicationContext类型的容器,也存在几个Aware相关接口。

ApplicationContext检测以下这些Aware接口并设置相关依赖的实现方式是通过BeanPostProcessor,这与前面的三个有所不同。不过设置Aware接口与BeanPostProcessor是相邻的,也可以放在一起讨论

1、ResourceLoaderAware,ApplicationContext实现了Spring的ResourceLoader接口,当容器检测到对象实现了ResourceLoaderAware接口后,会将当前ApplicationContext自身设置到对象中,这样当前对象就拥有了其所在ApplicationContext的一个引用。

2、ApplicationEventPublisherAware,ApplicationContext同样实现了ApplicationEventPublisher接口,这样,它就可以作为ApplicationEventPublisher来使用,所以,如果对象实现了ApplicationEventPublisherAware接口,容器就同样会将自身注入当前对象。

3、ApplicationContextAware,和前面一样,容器会将自身注入当前对象。

4、MessageSourceAware,和前面一样,容器会将自身注入当前对象。

3.3 BeanPostProcessor

如何与BeanFactoryPostProcessor区分?

BeanPostProcessor存在于对象实例化阶段,BeanFactoryPostProcessor存在于容器启动阶段。BeanFactoryPostProcessor会处理容器内所有符合条件的BeanDefinition,BeanPostProcessor会处理容器内所有符合条件的实例化后的对象实例。它包含两个接口方法:

postProcessBeforeInitialization(Object bean, String beanName);
postProcessAfterInitialization(Object bean, String beanName);

常见的使用场景是处理标记接口实现类,或者为当前对象提供代理实现。

ApplicationContext对应的那些Aware接口实际上就是通过BeanPostProcessor的方式进行处理的。当ApplicationContext中每个对象的实例化过程走到BeanPostProcessor前置处理这一步时,容器会检测到之前注册到容器的ApplicationContextAwareProcessor这个BeanPostProcessor的实现类,然后调用其postProcessBeforeInitialization方法,检查并设置Aware相关依赖:

if (bean instanceof EnvironmentAware) {
	((EnvironmentAware) bean).setEnvironment(this.applicationContext.getEnvironment());
}
if (bean instanceof EmbeddedValueResolverAware) {
	((EmbeddedValueResolverAware) bean).setEmbeddedValueResolver(this.embeddedValueResolver);
}
if (bean instanceof ResourceLoaderAware) {
	((ResourceLoaderAware) bean).setResourceLoader(this.applicationContext);
}
if (bean instanceof ApplicationEventPublisherAware) {
	((ApplicationEventPublisherAware) bean).setApplicationEventPublisher(this.applicationContext);
}
if (bean instanceof MessageSourceAware) {
	((MessageSourceAware) bean).setMessageSource(this.applicationContext);
}
if (bean instanceof ApplicationContextAware) {
	((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
}

3.4 自定义BeanPostProcessor

首先需要明确,BeanPostProcessor处理的是bean实例化阶段的一个过程,因此需要处理的对象必须是bean,即必须注册到ApplicationContext容器中,才能够被该接口实现类处理。

第一步:明确需要执行的操作,比如需要提前为目标bean的某个属性做转化,或赋值。然后定义该功能的标记接口,提供可以被BeanPostProcessor访问的接口方法。

第二步:让目标bean实现标记接口。

第三步:实现BeanPostProcessor接口,并注册到容器。通过instanceof关键字判断目标bean是否为标记接口的子类,如果是,则进行相关处理逻辑,最后返回bean。

注意,标记接口和BeanPostProcessor接口本身不存在直接的继承或依赖关系,另外,标记接口实际上并不是必须的,这是为了更好的限定处理逻辑的操作范围而存在的,也就是说,我们可以通过自定义的BeanPostProcessor子类,通过instanceof直接判断是否为目标bean类型的对象,然后直接处理,但这样可能会在BeanPostProcessor中暴露太多无关于处理逻辑的属性细节。标记接口很好的隔绝了BeanPostProcessor与目标bean类型之间的耦合。

3.5 InitializingBean和init-method

InitializingBean是容器内部广泛使用的一个对象生命周期标识接口。

它只有一个接口方法:afterPropertiesSet()。其作用是在对象实例化过程调用过“BeanPostProcessor的前置处理”之后,会接着检测当前对象是否实现了InitializingBean接口,如果是,则会调用afterPropertiesSet()方法进一步调整对象实例的状态。

比如,在某些情况下,某个业务对象实例化完成后,还不能处于可以使用的状态。这个时候就可以让该业务对象实现该接口,并在方法afterPropertiesSet()中完成对该业务对象的后续处理。

实现这个接口会让Spring框架带有侵入性,因此init-method属性可以替代“实现InitializingBean接口”完成初始化方法。另外,可以让bean直接定义名为init()的方法,Spring容器也会在这一阶段执行初始化逻辑。

一般,我们在集成第三方库,或者其他特殊的情况下,才会需要使用该特性。

 

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页