Spring Bean 的生命周期是什么？

核心回答

Spring Bean 的生命周期，可以概括为创建实例 → 注入依赖 → 初始化及后处理 → 使用 → 销毁回调。要区分“对象已经创建”和“Bean 已经初始化完成、可以交给业务使用”。

以 Spring Framework 6.2 中普通 Bean 的创建流程为例：

1. 创建实例：根据 Bean 定义，通过构造方法、工厂方法等创建对象。构造器注入的依赖在这一阶段解析并传入。
2. 填充属性：处理字段、Setter 等位置的依赖注入及配置值。
3. 初始化及后处理：调用适用的 Aware 回调，运行初始化前置处理链，再执行初始化方法，最后运行初始化后置处理链。常见初始化回调顺序是 @PostConstruct → InitializingBean.afterPropertiesSet() → 自定义 initMethod。
4. 交给业务使用：容器暴露最终 Bean；如果需要 AOP，最终得到的可能是代理对象。单例通常会被缓存，后续获取时复用。
5. 销毁回调：对于容器负责销毁的 Bean，在正常关闭容器等相应时机，依次执行适用的 @PreDestroy → DisposableBean.destroy() → 自定义 destroyMethod，释放连接、线程等资源。

这些回调只有实现接口或作了相应配置时才会执行。prototype Bean 也会经历创建和初始化，但交给调用方后，Spring 不再负责调用它的销毁回调。

进一步解释

初始化前后都做了什么？

Aware 接口用于向 Bean 提供容器信息，例如 BeanNameAware 获得名称，BeanFactoryAware 获得所属工厂。它们与业务依赖注入的目的不同，不必为了普通依赖都实现 Aware。

BeanPostProcessor 是容器扩展点，可以检查、修改甚至包装处理到的 Bean。它的 before/after 指的是初始化方法前后，不是构造方法前后；实例化阶段还有其他扩展接口。

@PostConstruct 本身就在初始化前置处理链中被触发，通常由 CommonAnnotationBeanPostProcessor 处理，不能把它画成“所有前置处理器执行完后的固定独立阶段”。ApplicationContextAware 等回调同样由相应后处理器触发，各处理器的相对顺序还取决于注册和排序规则。

配置了多种初始化或销毁机制，且它们指向不同方法时，才按上述顺序分别调用；同一方法被重复配置时会避免重复调用。业务通常选择一种清晰的回调方式即可，不需要为了完整展示而把所有接口都实现一遍。Spring 6 使用的是 jakarta.annotation.PostConstruct、jakarta.annotation.PreDestroy。

构造方法里和初始化方法里，各适合做什么？

构造方法适合接收必需依赖、建立对象自身不变条件。字段和 Setter 注入此时尚未完成，因此不能在构造方法里假定这些字段已经可用。

初始化回调适合在依赖注入后做必要校验及有限的准备工作。例如一个参考服务通过构造器接收 DAO，随后在初始化回调中检查配置、建立少量只读映射；如果它持有自己创建的客户端或执行器，则在销毁回调中关闭。这是生命周期的使用示例，不代表每个 Bean 都需要预加载或创建线程。

普通初始化回调作用于正在初始化的目标对象。不要因为类上有事务注解，就认为 @PostConstruct 内部调用本类方法一定会经过事务代理；需要代理能力的业务应放到合适的调用边界。

常见追问

Bean 生命周期和 Spring 容器启动流程是一回事吗？

Bean 生命周期关注一个实例如何从创建走到可用、再释放资源；容器启动还包括读取和注册 Bean 定义、执行工厂后处理器、注册 Bean 后处理器、创建非懒加载单例等。

BeanFactoryPostProcessor 主要处理 Bean 定义等配置元数据，BeanPostProcessor 主要处理 Bean 实例。不能把前者当成每创建一个普通 Bean 都必须执行的一步。

所有 Bean 都在容器启动时创建、关闭时销毁吗？

不是。常规非懒加载单例通常在容器启动时创建；懒加载单例一般在需要时创建，也可能因其他 Bean 的依赖而提前创建。prototype 按请求创建并由使用方处理后续资源清理；request、session 等作用域则有自己的结束时机。销毁回调是资源清理机制，也不等于立即触发 JVM 垃圾回收。

参考资料