Spring Bean 的初始化过程及销毁过程中的一些问题。
有些bug可在 Spring 异常提示下快速解决，但却不理解背后原理
一些错误，不易在开发环境下被发现，从而在产线上造成较为严重后果
1 使用构造器参数实现隐式注入
类初始化时的常见 bug。构建宿舍管理系统时，有 LightMgrService 来管理 LightService，控制宿舍灯的开启和关闭。
现在期望在 LightMgrService 初始化时自动调用 LightService#check检查所有宿舍灯的电路是否正常：
我们在 LightMgrService 的默认构造器中调用了通过 @Autoware 注入的成员变量 LightService#check：
LightService 对象的原始类
预期现象：
在 LightMgrService 初始化过程中，LightService 因被**@Autowired**标记，所以能被自动装配
在 LightMgrService 构造器执行中，LightService#check() 能被自动调用
打印 check all lights
然而事与愿违，我们得到的只会是 NPE：
1.1 源码解析
根因在于对Spring类初始化过程没有足够的了解。下面这张时序图描述了 Spring 启动时的一些关键结点：
将一些必要系统类，比如Bean后置处理器，注册到Spring容器，包括CommonAnnotationBeanPostProcessor
将这些后置处理器实例化，并注册到Spring容器
实例化所有用户定制类，调用后置处理器进行辅助装配、类初始化等等。
CommonAnnotationBeanPostProcessor 后置处理类是何时被 Spring 加载和实例化的呢？
很多必要系统类，比如Bean后置处理器（CommonAnnotationBeanPostProcessor、AutowiredAnnotationBeanPostProcessor 等），都是被 Spring 统一加载和管理
通过Bean后置处理器，Spring能灵活地在不同场景调用不同后置处理器，比如 @PostConstruct，它的处理逻辑就要用到 CommonAnnotationBeanPostProcessor（继承自 InitDestroyAnnotationBeanPostProcessor）
Spring 初始化单例类的一般过程：
getBean()
doGetBean()
getSingleton()
若发现 Bean 不存在，则调用
createBean()=》doCreateBean()
进行实例化。
doCreateBean()
protectedObjectdoCreateBean(finalString beanName,finalRootBeanDefinition mbd,final@Nullable Object[] args)throwsBeanCreationException{// ...if(instanceWrapper ==null) {// 1.instanceWrapper = createBeanInstance(beanName, mbd, args);}finalObject bean = instanceWrapper.getWrappedInstance();// ...Object exposedObject = bean;try{// 2.populateBean(beanName, mbd, instanceWrapper);// 3.exposedObject = initializeBean(beanName, exposedObject, mbd); }catch(Throwable ex) {// ...}
Bean 初始化关键步骤：
实例化 Bean
注入 Bean 依赖
初始化 Bean （例如执行 @PostConstruct 标记的方法 ）
实例化Bean的createBeanInstance通过依次调用：
DefaultListableBeanFactory.instantiateBean()
SimpleInstantiationStrategy.instantiate()
最终执行到
BeanUtils.instantiateClass()：
publicstaticTinstantiateClass(Constructor
最终调用 ctor.newInstance() 实例化用户定制类LightMgrService，而默认构造器在类实例化时被自动调用，Spring 也无法控制。
而此时负责自动装配的 populateBean 方法还没有执行，LightMgrService 的属性 LightService 还是 null，导致NPE。
修正
问题在于使用 @Autowired 直接标记在成员属性引发的装配行为发生在构造器执行后。
所以可通过如下方案解决：
构造器注入
当使用上述代码，构造器参数 LightService 会被自动注入LightService 的 Bean，从而在构造器执行时，避免NPE。
Spring 在类属性完成注入之后，会回调我们定义的初始化方法。即在 populateBean 方法之后，会调用
AbstractAutowireCapableBeanFactory#initializeBean
applyBeanPostProcessorsBeforeInitialization处理 @PostConstruct
invokeInitMethods处理InitializingBean 接口
两种不同的初始化方案的逻辑
applyBeanPostProcessorsBeforeInitialization与 @PostConstruct
applyBeanPostProcessorsBeforeInitialization 方法最终执行到
InitDestroyAnnotationBeanPostProcessor#buildLifecycleMetadata：
applyBeanPostProcessorsBeforeInitialization处理 @PostConstructinvokeInitMethods处理InitializingBean 接口两种不同的初始化方案的逻辑applyBeanPostProcessorsBeforeInitialization与 @PostConstructapplyBeanPostProcessorsBeforeInitialization 方法最终执行到InitDestroyAnnotationBeanPostProcessor#buildLifecycleMetadata：
在这个方法里，Spring 将遍历查找被 PostConstruct.class 注解过的方法，返回到上层，并最终调用此方法。
invokeInitMethods 与 InitializingBean 接口
给bean一个机会去响应现在它的所有属性都已设置，并有机会了解它拥有的bean工厂（这个对象）。 这意味着检查 bean 是否实现了 InitializingBean 或自定义了 init 方法。
若是，则调用必要的回调。
invokeInitMethods会判断当前 Bean 是否实现了 InitializingBean 接口，只有实现该接口时，Spring 才会调用该 Bean 的接口实现方法 afterPropertiesSet()。
还有两种方式：
init 方法 && @PostConstruct
实现 InitializingBean 接口，回调afterPropertiesSet()
对于本案例，后两种方案并非最优。
但在一些场景下，这两种方案各有所长。
2 意外触发 shutdown 方法
类销毁时，也容易写出一堆 bug。
LightService#shutdown，负责关灯：
之前的案例中，若宿管系统重启，灯是不会被关闭的。但随着业务变化，可能会去掉 @Service ，而使用另外一种产生 Bean 的方式：创建一个配置类 BeanConfiguration（标记 @Configuration）来创建一堆 Bean，其中就包含了创建 LightService 类型的 Bean，并将其注册到 Spring 容器：
让 Spring 启动完成后立马关闭当前 Spring 上下文，这就能模拟模拟宿管系统的启停：
以上代码没有其他任何方法的调用，仅是将所有符合约定的类初始化并加载到 Spring 容器，完成后再关闭当前 Spring 容器。
预期：运行后不会有任何log，只改变 Bean 的产生方式。
运行后，控制台打印：
显然 shutdown 方法未按照预期，被执行了，这就导致一个有意思的 bug：
在使用新的 Bean 生成方式之前，每一次宿舍管理服务被重启时，宿舍里所有的灯都不会被关闭
但修改后，只要服务重启，灯都被意外关闭
你能理解这个bug吗?
源码解析
发现：
只有通过使用 Bean 注解注册到 Spring 容器的对象，才会在 Spring 容器被关闭时自动调用 shutdown
使用 @Component将当前类自动注入到 Spring 容器时，shutdown 方法则不会被自动执行
可尝试到 Bean 注解类的代码中去寻找一些线索，可看到属性 destroyMethod。
使用 Bean 注解的方法所注册的 Bean 对象，如果用户不设置 destroyMethod 属性，则其属性值为
AbstractBeanDefinition.INFER_METHOD。
此时 Spring 会检查当前 Bean 对象的原始类中是否有名为 shutdown 或 close 的方法：
有，此方法会被 Spring 记录下来，并在容器被销毁时自动执行
没有，安然无事
查找 INFER_METHOD 枚举值的引用，很容易就找到了使用该枚举值的方法
DisposableBeanAdapter#inferDestroyMethodIfNecessary
privateStringinferDestroyMethodIfNecessary(Objectbean, RootBeanDefinition beanDefinition) {StringdestroyMethodName = beanDefinition.getDestroyMethodName();if(AbstractBeanDefinition.INFER_METHOD.equals(destroyMethodName) ||(destroyMethodName ==null&& beaninstanceofAutoCloseable)) {if(!(beaninstanceofDisposableBean)) {try// 尝试查找 close 方法returnbean.getClass().getMethod(CLOSE_METHOD_NAME).getName(); }catch(NoSuchMethodException ex) {try{// 尝试查找 shutdown 方法returnbean.getClass().getMethod(SHUTDOWN_METHOD_NAME).getName(); }catch(NoSuchMethodException ex2) {// no candidate destroy method found} } }returnnull; }return(StringUtils.hasLength(destroyMethodName) ? destroyMethodName :null);}
代码逻辑和
Bean 注解类中对于 destroyMethod 属性的注释：
完全一致。
destroyMethodName==INFER_METHOD&&当前类没有实现DisposableBean接口
则先查找类的 close 方法：
找不到
就在抛出异常后继续查找 shutdown 方法
找到
则返回其方法名（close 或者 shutdown）
接着，继续逐级查找引用，最终得到的调用链从上到下为：
doCreateBean
registerDisposableBeanIfNecessary
registerDisposableBean(new DisposableBeanAdapter)
inferDestroyMethodIfNecessary
然后，我们追溯到了顶层的 doCreateBean：
protectedObjectdoCreateBean(finalString beanName,finalRootBeanDefinition mbd,final@Nullable Object[] args)throwsBeanCreationException{// 实例化 beanif(instanceWrapper ==null) { instanceWrapper = createBeanInstance(beanName, mbd, args); }// ...// 初始化 bean 实例.Object exposedObject = bean;try{ populateBean(beanName, mbd, instanceWrapper) exposedObject = initializeBean(beanName, exposedObject, mbd); }// ...// Register bean as disposable.try{ registerDisposableBeanIfNecessary(beanName, bean, mbd); }catch(BeanDefinitionValidationException ex) {thrownewBeanCreationException( mbd.getResourceDescription(), beanName,"Invalid destruction signature", ex); }returnexposedObject;}
doCreateBean 管理了Bean的整个生命周期中几乎所有的关键节点，直接负责了 Bean 对象的生老病死，其主要功能包括：
Bean 实例的创建
Bean 对象依赖的注入
定制类初始化方法的回调
Disposable 方法的注册
接着，继续查看 registerDisposableBean：
publicvoidregisterDisposableBean(String beanName, DisposableBean bean){synchronized(this.disposableBeans) {this.disposableBeans.put(beanName, bean);}}
DisposableBeanAdapter 类（其属性destroyMethodName 记录了使用哪种 destory 方法）被实例化
并添加到
DefaultSingletonBeanRegistry#disposableBeans 属性内，disposableBeans 将暂存这些 DisposableBeanAdapter 实例，直到 AnnotationConfigApplicationContext#close被调用。
而当
AnnotationConfigApplicationContext#close被调用时，即当 Spring 容器被销毁时，最终会调用到 DefaultSingletonBeanRegistry#destroySingleton：
遍历 disposableBeans 属性
逐一获取 DisposableBean
依次调用其 close 或 shutdown
publicvoiddestroySingleton(String beanName){// Remove a registered singleton of the given name, if any.removeSingleton(beanName);// Destroy the corresponding DisposableBean instance.DisposableBean disposableBean; synchronized (this.disposableBeans) { disposableBean = (DisposableBean)this.disposableBeans.remove(beanName); } destroyBean(beanName, disposableBean);}
案例调用了 LightService#shutdown 方法，将所有的灯关闭了。
修正
避免在Java类中定义一些带有特殊意义动词的方法来解决。
如果一定要定义名为 close 或者 shutdown 方法，可以将 Bean 注解内 destroyMethod 属性设置为空。如下：
importorg.springframework.context.annotation.Bean;importorg.springframework.context.annotation.Configuration;@ConfigurationpublicclassBeanConfiguration{@Bean(destroyMethod="")publicLightService getTransmission() {returnnew LightService(); }}
为什么 @Service 注入的 LightService，其 shutdown 方不能被执行？想要执行，则必须要添加 DisposableBeanAdapter，而它的添加是有条件的：
protectedvoidregisterDisposableBeanIfNecessary(StringbeanName,Objectbean, RootBeanDefinition mbd) { AccessControlContext acc = (System.getSecurityManager() !=null? getAccessControlContext() :null);if(!mbd.isPrototype() && requiresDestruction(bean, mbd)) {if(mbd.isSingleton()) {// Register a DisposableBean implementation that performs all destruction// work for the given bean: DestructionAwareBeanPostProcessors,// DisposableBean interface, custom destroy method.registerDisposableBean(beanName,newDisposableBeanAdapter(bean, beanName, mbd, getBeanPostProcessors(), acc)); }else{//省略非关键代码} }}
关键的语句在于：
!mbd.isPrototype() &&requiresDestruction(bean,mbd
案例代码修改前后，我们都是单例，所以区别仅在于是否满足requiresDestruction 条件。
DisposableBeanAdapter#hasDestroyMethod：publicstaticbooleanhasDestroyMethod(Objectbean, RootBeanDefinition beanDefinition) {if(beaninstanceofDisposableBean || beaninstanceofAutoCloseable) {returntrue; }StringdestroyMethodName = beanDefinition.getDestroyMethodName();if(AbstractBeanDefinition.INFER_METHOD.equals(destroyMethodName)) {return(ClassUtils.hasMethod(bean.getClass(), CLOSE_METHOD_NAME) || ClassUtils.hasMethod(bean.getClass(), SHUTDOWN_METHOD_NAME)); }returnStringUtils.hasLength(destroyMethodName);}
如果使用 @Service 产生 Bean，则上述代码获取的destroyMethodName是 null
使用 @Bean，默认值为AbstractBeanDefinition.INFER_METHOD，参考 Bean 定义：
public@interfaceBean{//省略其他非关键代码StringdestroyMethod()defaultAbstractBeanDefinition.INFER_METHOD;}
总结
DefaultListableBeanFactory 类是 Spring Bean 的灵魂，核心就是其doCreateBean，掌控了 Bean 实例的创建、Bean 对象依赖的注入、定制类初始化方法的回调以及 Disposable 方法的注册等关键节点。