Spring揭秘-IOC容器的原理

Bean是怎么创建的?

Spring揭秘-IOC容器的原理_第1张图片
Magic?

上图中Magic Happens Here实现可以分为两个阶段,容器启动阶段、Bean实例化阶段。

容器启动阶段

容器依赖BeanDefinitionReader对加载的Configuration Metadata进行解析,将得到的信息保存为BeanDefinition,注册到BeanDefinitionRegistry后,容器的启动阶段就完成了。

BeanFactoryPostProcessor

Spring提供了一种叫做 BeanFactoryPostProcessor 的容器扩展机制,它允许我们在容器启动阶段的最后修改BeanDefinition,达到修改Bean属性的目的,
Spring提供了几个现成的 BeanFactoryPostProcessor 实现类

  • PropertyPlaceholderConfigurer
    我们配置DataSource时通常会用${jdbc.url}等占位符,容器启动阶段完成后,BeanDefinition中仍存在占位符,当PropertyPlaceholderConfigurer 作为 BeanFactoryPostProcessor 被应用时,它会使用properties或yml配置文件中的配置信息来替换相应 BeanDefinition 中占位符所表示的属性值。
  • PropertyOverrideConfigurer
    它的properties文件中的配置项覆盖掉了原来XML中的bean定义的property信息,并且对于Bean是透明的。
  • CustomEditorConfigurer
    配置文件的property都是 String 类型,但在程序中我们可能需要各种类型的对象,比如Date,CustomEditorConfigurer能帮我们完成这种类型的转换。

Bean实例化阶段

经过容器启动阶段,现在所有的bean定义信息都通过 BeanDefinition 的方式注册到了 BeanDefinitionRegistry 中。当某个请求方通过容器的 getBean 方法明确地请求某个对象,或者因依赖关系容器需要隐式地调用 getBean 方法时,就会触发Bean实例化阶段。Spring容器将对其所管理的对象全部给予统一的生命周期管理,这些被管理的对象完全摆脱了原来那种new完后被使用,脱离作用域后即被回收的命运。
下图是实例化的过程。


Spring揭秘-IOC容器的原理_第2张图片
Bean的实例化过程
  1. 实例化对象
    容器内部采用策略模式决定用什么方式初始化bean,通常通过反射或者cglib初始化bean或者动态生成子类,默认情况下,容器内部采用的是CglibSubclassingInstantiationStrategy,它不会在对象初始化完成后直接返回,而是以 BeanWrapper 对构造完成的对象实例进行包装,返回相应的 BeanWrapper 实例。
  2. 设置对象属性
    BeanWrapper继承了PropertyAccessor接口,可以以统一的方式对对象属性进行访问。
  3. 检查Aware相关接口并设置相关依赖
    当对象实例化完成并且相关属性以及依赖设置完成之后,Spring容器会检查当前对象实例是否实现了一系列的以 Aware 命名结尾的接口定义。如果是,则将这些 Aware 接口定义中规定的依赖注入给当前对象实例。
    • 针对BeanFactory容器,BeanNameAware、BeanClassLoaderAware、BeanFactoryAware这几个接口,分别会将beanName、ClassLoader、BeanFactory注入到当前对象实例。
    • 针对ApplicationContext容器,ResourceLoaderAware、ApplicationEventPublisherAware、MessageSourceAware、ApplicationContextAware会将自身(aplicationContext)注入到当前对象实例。
  4. BeanPostProcessor前置处理
public interface BeanPostProcessor {
    //前置处理
    Object postProcessBeforeInitialization(Object var1, String var2) throws BeansException;
    //后置处理
    Object postProcessAfterInitialization(Object var1, String var2) throws BeansException;
}

如图,BeanPostProcessor 接受当前对象实例,它可以对当前对象做任何操作,一般用于处理标记接口实现类,或者为当前对象提供代理实现(AOP)。针对 ApplicationContext 容器检查Aware相关接口就是使用之前注册到容器的
ApplicationContextAwareProcessor 这个实现类的前置处理实现的。

  1. 检查是否是InitializingBean
public interface InitializingBean {
    void afterPropertiesSet() throws Exception;
}

在对象实例化过程调用过 BeanPostProcessor 的前置处理之后,会接着检测当前对象是否实现了 InitializingBean 接口,如果是,则会调用其 afterPropertiesSet() 方法进一步调整对象实例的状态,比如在有些情况下,某个业务对象实例化完成后,还不能处于可以使用状态。这个时候就可以让该业务对象实现该接口,并在方法 afterPropertiesSet()中完成对该业务对象的后续处理。

  1. 检查是否配置有自定义的init-method
    实现InitializingBean,Spring容器会有较强的侵入性,所以Spring还提供了另一种方式来指定自定义的对象初始化操作,那就是在XML配置的时候使用 的 init-method 属性。

  2. BeanPostProcessor后置处理
    发生在初始化操作后,调用同前置操作。注意,ApplicationContext会自动检测在配置文件中实现了BeanPostProcessor接口的所有bean并把他们注册,BeanFactory需要写代码调用。

  3. DisposableBean 与 destroy-method,注册必要的Destruction相关回调接口
    当所有的一切,该设置的设置,该注入的注入,该调用的调用完成之后,容器将检查singleton类型的bean实例,看其是否实现了 DisposableBean 接口。或者其对应的bean定义是否通过 的 destroy-method 属性指定了自定义的对象销毁方法。如果是就会为该实例注册一个用于对象销毁的回调(Callback),以便在这些singleton类型的对象实例销毁之前,执行销毁逻辑。但是销毁逻辑不会自动执行。

    • 对于BeanFactory
      我们必须手动调用 ConfigurableBeanFactory 提供的 destroySingletons() 方法销毁容器中管理的所有singleton类型的对象实例。
    • 对于ApplicationContext
      AbstractApplicationContext 为我们提供了 registerShutdownHook() 方法,该方法底层使用标准的 Runtime 类的 addShutdownHook() 方式来调用相应bean对象的销毁逻辑,从而保证在Java虚拟机退出之前,这些singtleton类型的bean对象实例的自定义销毁逻辑会被执行。

    不过,所有这些规则不包含prototype类型的bean实例,因为prototype
    对象实例在容器实例化并返回给请求方之后,容器就不再管理这种类型对象实例的生命周期了。

你可能感兴趣的:(Spring揭秘-IOC容器的原理)