Spring揭秘-IOC容器的原理 Spring揭秘-IOC容器的原理

Bean是怎么创建的?
文章图片
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完后被使用,脱离作用域后即被回收的命运。
下图是实例化的过程。

文章图片
Bean的实例化过程

实例化对象
容器内部采用策略模式决定用什么方式初始化bean，通常通过反射或者cglib初始化bean或者动态生成子类，默认情况下，容器内部采用的是CglibSubclassingInstantiationStrategy，它不会在对象初始化完成后直接返回，而是以 BeanWrapper 对构造完成的对象实例进行包装,返回相应的 BeanWrapper 实例。
设置对象属性
BeanWrapper继承了PropertyAccessor接口，可以以统一的方式对对象属性进行访问。
检查Aware相关接口并设置相关依赖
当对象实例化完成并且相关属性以及依赖设置完成之后，Spring容器会检查当前对象实例是否实现了一系列的以 Aware 命名结尾的接口定义。如果是，则将这些 Aware 接口定义中规定的依赖注入给当前对象实例。
- 针对BeanFactory容器，BeanNameAware、BeanClassLoaderAware、BeanFactoryAware这几个接口，分别会将beanName、ClassLoader、BeanFactory注入到当前对象实例。
- 针对ApplicationContext容器，ResourceLoaderAware、ApplicationEventPublisherAware、MessageSourceAware、ApplicationContextAware会将自身(aplicationContext)注入到当前对象实例。
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 这个实现类的前置处理实现的。

检查是否是InitializingBean

public interface InitializingBean { void afterPropertiesSet() throws Exception; }

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

检查是否配置有自定义的init-method
实现InitializingBean，Spring容器会有较强的侵入性，所以Spring还提供了另一种方式来指定自定义的对象初始化操作,那就是在XML配置的时候使用的 init-method 属性。
BeanPostProcessor后置处理
发生在初始化操作后，调用同前置操作。注意，ApplicationContext会自动检测在配置文件中实现了BeanPostProcessor接口的所有bean并把他们注册，BeanFactory需要写代码调用。
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
对象实例在容器实例化并返回给请求方之后，容器就不再管理这种类型对象实例的生命周期了。