Spring学习2---Bean的生命周期

上一篇学习了容器的概念，那么容器中的bean到底是如何管理的，这就涉及到了另一个核心概念 bean的生命周期

我们为什么要用Spring

本质我们就是想要用容器来管理bean

1.Bean的加载

在容器启动之后，我们得到了每个bean的基本信息 beanDeifinition，然后BeanFactory的getBean方法可以被客户端显示调用，也可以被Spring隐式调用。隐式调用有如下2种方法

BeanFactory
对象实例化默认采用延迟初始化。通常情况下，当对象A被请求而需要第一次实例化的时候，如果它所依赖的对象B之前同样没有被实例化，那么容器会先实例化对象A所依赖的对象。这时容器内部就会首先实例化对象B，以及对象 A依赖的其他还没有实例化的对象。这种情况是容器内部调用getBean()，对于本次请求的请求方是隐式的。
ApplicationContext
启动之后会实例化所有的bean定义，但ApplicationContext在实现的过程中依然遵循Spring容器实现流程的两个阶段，只不过它会在启动阶段的活动完成之后，紧接着调用注册到该容器的所有bean定义的实例化方法getBean()。这就是为什么当你得到ApplicationContext类型的容器引用时，容器内所有对象已经被全部实例化完成。类org.AbstractApplicationContext的refresh()方法可以看到源码。

2.bean的实例化过程

Spring容器将对其所管理的对象全部给予统一的生命周期管理

image.png

tip：org.springframework.beans.factory.support.AbstractBeanFactory类的代码中查看到getBean()方法的完整实现逻辑，可以在其子类org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory的代码中一窥createBean()方法的全貌

2.1 bean和beanWrapper

容器在内部实现的时候，采用“策略模式（Strategy Pattern）”来决定采用何种方式初始化bean实例。通常，可以通过反射或者CGLIB动态字节码生成来初始化相应的bean实例或者动态生成其子类。容器内部采用的是CglibSubclassingInstantiationStrategy
容器只要根据相应bean定义的BeanDefintion取得实例化信息，结合CglibSubclassingInstantiationStrategy以及不同的bean定义类型，就可以返回实例化完成的对象实例。但是，返回方式上有些“点缀”。不是直接返回构造完成的对象实例，而是以BeanWrapper对构造完成的对象实例
进行包裹，返回相应的BeanWrapper实例

为什么要返回BeanWrapper？
其实很简单，是为了后期的各种扩展有统一的接口比较方便BeanWrapper定义继承了org.springframework.beans.PropertyAccessor接口，可以以统一的方式对对象属性进行访问
各类配置文件中的属性，就会在取回BeanWrapper后进行注入

2.2 Aware接口

从实例化图中，可以看到，当设置完对象属性后，会对Aware接口进行检查，设置相关依赖
在实例化到此阶段时，如果Spring容器检查到当前对象实现了Aware命名结尾的接口定义，则根据这些定义规定的依赖注入给当前对象

针对BeanFactory类型的容器而言，BeanNameAware，BeanClassLoaderAware，BeanFactoryAware（会将容器注入给此对象，让这个对象可以获得容器的信息）
对于ApplicationContext而言，还多了几个Aware接口，但实现有所不同，是通过图中的后一步 BeanPostProccessor实现的
但实现的功能是一样的，如ResourceLoaderAware，ApplicationEventPublisherAware，MessageSourceAware，ApplicationContextAware

2.3 BeanPostProcessor

区别上一篇的BeanFactoryPostProcessor，顾名思义，BeanFactoryPostProcessor是插手容器的启动阶段的，而BeanPostProcessor是插手bean的实例化的

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

可以从接口定义中看到，它分为前置处理器和后置处理器，在图中也可以看到，这是2个环节都进行处理通常比较常见的使用BeanPostProcessor的场景，是处理标记接口实现类，或者为当前对象提供代理实现

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

public Object postProcessBeforeInitialization(Object bean, String beanName) throws ➥
BeansException {
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);}
return bean;}

Spring的AOP则更多地使用BeanPostProcessor来为对象生成相应的代理对象，如org.springframework.aop.framework.
autoproxy.BeanNameAutoProxyCreator。

这里特别讲一个特殊的InstantiationAwareBeanPostProcessor
org.springframework.beans.factory.config.InstantiationAwareBeanPostProcessor接口可以在对象的实例化过程中导致某种类似于电路“短路”的效果。实际上，并非所有注册到Spring容器内的bean定义都是按照图4-10的流程实例化的。在所有的步骤之前，也就是实例化bean对象步骤之前，容器会首先检查容器中是否注册有InstantiationAwareBeanPostProcessor类型的BeanPostProcessor。如果有，首先使用相应的InstantiationAwareBeanPostProcessor来构造对象实例。构造成功后直接返回构造完成的对象实例，而不会按照“正规的流程”继续执行。这就是它可能造成“短路”的原因。不过，通常情况下都是Spring容器内部使用这种特殊类型的BeanPostProcessor做一些动态对象代理等工作，我们使用普通的BeanPostProcessor实现就可以。
在开发阶段，可以实现InstantiationAwareBeanPostProcessor，不判断逻辑，把所有的bean Name实例化结果输出，排查空注入的问题

3 Initializing和 init-method

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

虽然该接口在Spring容器内部广泛使用，但如果真的让我们的业务对象实现这个接口，则显得Spring容器比较具有侵入性。所以， Spring还提供了另一种方式来指定自定义的对象初始化操作，那就是在XML配置的时候，使用的init-method属性.一般，我们是在集成第三方库，或者其他特殊的情况下，才会需要使用该特性.

如果既有afterPropertiesSet方法，又在xml里面配置了 init方法，会有先后顺序，最好别这样

4. DisposableBean与destroy-method

与InitializingBean和init-method用于对象的自定义初始化相对应， DisposableBean和destroy-method为对象提供了执行自定义销毁逻辑的机会。最常见到的该功能的使用场景就是在Spring容器中注册数据库连接池，在系统退出后，连接池应该关闭，以释放相应资源
对于BeanFactory容器来说。我们需要在独立应用程序的主程序退出之前，或者其他被认为是合适的情况下

public class ApplicationLauncher
{
public static void main(String[] args) {
BasicConfigurator.configure();
BeanFactory container = new XmlBeanFactory(new ClassPathResource("..."));
BusinessObject bean = (BusinessObject)container.getBean("...");
bean.doSth();
((ConfigurableListableBeanFactory)container).destroySingletons();
// 应用程序退出，容器关闭
}
}

如果不能在合适的时机调用destroySingletons()，那么所有实现了DisposableBean接口的对象实例或者声明了destroy-method的bean定义对应的对象实例，它们的自定义对象销毁逻辑就形同虚设，因为根本就不会被执行！

对于ApplicationContext容器来说。道理是一样的。但AbstractApplicationContext为我们提供了registerShutdownHook()方法，该方法底层使用标准的Runtime类的addShutdownHook()方式来调用相应bean对象的销毁逻辑，从而保证在Java虚拟机退出之前，这些singtleton类型的bean对象实例的自定义销毁逻辑会被执行

public class ApplicationLauncher { 
public static void main(String[] args) {
BasicConfigurator.configure();
BeanFactory container = new ClassPathXmlApplicationContext("..."); 
((AbstractApplicationContext)container).registerShutdownHook();
BusinessObject bean = (BusinessObject)container.getBean("...");
// bean.doSth(); 应用程序退出，容器关闭 
}
}