Spring Bean 的生命周期回调方法有哪些？

Question

**常见技术问题：** 在Spring应用中，开发者常混淆`@PostConstruct`、`InitializingBean.afterPropertiesSet()`和自定义`init-method`三者的执行顺序与适用场景。例如：当Bean同时实现`InitializingBean`接口、标注`@PostConstruct`方法并配置了`init-method`时，究竟哪个先执行？若`@PostConstruct`方法抛出异常，后续初始化回调是否还会触发？此外，`@PreDestroy`与`DisposableBean.destroy()`、`destroy-method`的调用时机及容器关闭时的保障机制有何差异？尤其在使用`ApplicationContext`与`BeanFactory`、或集成`@Configuration`类与XML配置时，回调行为是否存在一致性？这些问题若理解不清，易导致资源未正确初始化（如数据库连接池未启动）、预热逻辑失效，或JVM退出时资源泄漏（如线程池未优雅关闭）。请结合Spring 5.3+源码级生命周期流程，厘清各回调的注册时机、执行阶段及优先级规则。

Answer 1

```html

一、生命周期回调的宏观定位：Spring Bean 的三阶段初始化模型

Spring 容器对每个单例 Bean 的生命周期管理严格遵循 实例化 → 属性填充 → 初始化 三阶段模型。其中，@PostConstruct、InitializingBean.afterPropertiesSet() 和 init-method 均属于初始化阶段（Initialization Phase）的回调机制，但它们注册时机、触发来源与执行上下文截然不同。Spring 5.3+ 中，该阶段由 AbstractAutowireCapableBeanFactory#initializeBean() 统一调度，其内部调用链为：applyBeanPostProcessorsBeforeInitialization() → invokeInitMethods() → applyBeanPostProcessorsAfterInitialization()。

二、执行顺序深度解析：源码级优先级规则（Spring 5.3.32 实测验证）

当一个 Bean 同时声明三种初始化回调时，执行顺序严格固定如下（按源码 invokeInitMethods() 方法逻辑）：

1. @PostConstruct：由 CommonAnnotationBeanPostProcessor 在 postProcessBeforeInitialization() 阶段触发（早于 afterPropertiesSet）；
2. InitializingBean.afterPropertiesSet()：在 invokeInitMethods() 中第二顺位执行（仅当 Bean 实现该接口）；
3. 自定义 init-method：最后执行，通过反射调用配置指定方法（XML 中 init-method="init" 或 @Bean(initMethod="init")）。

⚠️ 关键约束：任一回调抛出 Exception（非 RuntimeException 时需显式声明），将立即中断整个初始化流程，后续回调——Spring 将该 Bean 标记为创建失败，并从单例缓存中移除（见 DefaultSingletonBeanRegistry#registerSingleton() 回滚逻辑）。

三、销毁回调对比：@PreDestroy vs DisposableBean vs destroy-method

回调类型	注册时机	执行阶段	容器关闭保障	ApplicationContext 专属？
@PreDestroy	InitDestroyAnnotationBeanPostProcessor 在 postProcessBeforeDestruction() 注册	销毁前第一顺位（destroy() 内部最先调用）	✅ 依赖 AbstractApplicationContext#close() 显式调用或 JVM Shutdown Hook	否（BeanFactory 也支持，但需手动调用 DisposableBean.destroy()）
DisposableBean.destroy()	接口实现即自动识别（isFactoryBean() 判断后注册）	第二顺位（invokeCustomDestroyMethod() 前）	✅ 同上，但若容器未正确关闭（如 kill -9），不保证执行	否
destroy-method	XML 解析时注入 RootBeanDefinition.destroyMethodName，或 @Bean(destroyMethod="close")	第三顺位（最后执行）	✅ 同上；Spring Boot 2.3+ 默认启用 spring.lifecycle.timeout-per-shutdown-phase=30s 保障超时等待	否

四、配置一致性分析：@Configuration vs XML vs @Component

无论使用 @Configuration 类、@Component 扫描，还是传统 XML 配置，Spring 5.3+ 的回调注册与执行逻辑完全统一，其底层均归一至 BeanDefinition 元数据模型：

• @PostConstruct 和 @PreDestroy 依赖 CommonAnnotationBeanPostProcessor（默认启用）；
• InitializingBean/DisposableBean 接口识别由 AbstractAutowireCapableBeanFactory#invokeInitMethods() 和 #destroy() 直接判断；
• init-method/destroy-method 信息存储于 BeanDefinition.getInitMethodName() / .getDestroyMethodName()，与配置源无关。

⚠️ 唯一例外：纯 BeanFactory（非 ApplicationContext 子类）不自动注册 CommonAnnotationBeanPostProcessor 和 InitDestroyAnnotationBeanPostProcessor，需手动添加，否则 @PostConstruct/@PreDestroy 失效。

五、生产级实践建议与反模式警示

graph LR
A[Bean 创建] --> B[实例化 new Instance]
B --> C[属性注入 setXXX / @Autowired]
C --> D[初始化阶段]
D --> D1[@PostConstruct]
D --> D2[afterPropertiesSet]
D --> D3[init-method]
D --> E[初始化完成]
E --> F[Bean 就绪]
F --> G[容器关闭]
G --> H[@PreDestroy]
G --> I[destroy]
G --> J[destroy-method]

✅ 推荐组合：@PostConstruct 用于轻量级资源绑定（如连接池预热）、init-method 用于需解耦的业务初始化逻辑（避免强依赖 Spring API）；

❌ 反模式：
• 在 @PostConstruct 中执行阻塞 IO（如 HTTP 调用）——导致容器启动卡死；
• 混用 InitializingBean 与 init-method 做重复校验——违反单一职责；
• 忽略 @PreDestroy 异常捕获——线程池 shutdownNow() 抛异常将静默吞掉，引发泄漏。

💡 高阶技巧：通过 @Order(Ordered.HIGHEST_PRECEDENCE) 自定义 BeanPostProcessor 插入初始化前/后钩子，实现跨 Bean 初始化编排（如 DB 连接池必须先于 MyBatis SqlSessionFactory 初始化）。

```