Spring Bean生命周期详解：从实例化到销毁的完整流程

原创

于 2026-06-20 13:13:25 发布 · 323 阅读

标签

#Bean生命周期 #Spring Boot 3.2 #BeanPostProcessor

1. 为什么“Bean生命周期”是Spring面试里永远绕不开的硬核题

我带过十几届校招实习生，也参与过上百场中高级Java岗位的技术面试。每次问到Spring，90%以上的候选人会从“IOC容器”“AOP原理”开始讲起，但只要我追问一句：“那一个Bean从new出来到被销毁，中间到底经历了多少个明确的、可干预的节点？”——当场卡壳的人超过七成。不是他们没背过“实例化→属性赋值→初始化→销毁”这八个字，而是根本说不清：哪个阶段能拿到尚未注入依赖的对象？哪个回调里能安全访问数据库连接？为什么@PostConstruct方法比InitializingBean.afterPropertiesSet()先执行？如果同时定义了多个BeanPostProcessor，它们的执行顺序又怎么控制？

这背后不是记忆问题，而是对Spring底层设计哲学的理解断层。Spring从来不是一个“把对象塞进Map里就完事”的简单容器，它是一套精密的、分阶段的、可插拔的生命周期编排系统。你写的每一个@Component、@Service、@Configuration，最终都会被包装成一个BeanDefinition，再由BeanFactory按严格时序驱动其演进。这个过程就像一条装配流水线：每个工位（回调接口）只负责一个特定动作，上一工位不完成，下一工位绝不启动；而你作为开发者，就是这条线上的工艺工程师——既要清楚每个工位的功能边界，更要明白在哪个工位加装自定义夹具（比如日志埋点、资源预热、健康检查），才能让整条线高效、稳定、可观测。

更关键的是，这个生命周期模型直接决定了你能否写出健壮的代码。比如你在@PostConstruct里调用了一个远程服务，结果该服务因网络抖动超时，整个Bean初始化失败，容器直接抛出BeanCreationException导致应用启动失败；又比如你在destroy()方法里试图关闭一个已被GC回收的线程池，引发NullPointerException却无从捕获。这些都不是理论风险，而是我在三个不同项目里亲手踩过的坑。所以今天这篇，不讲教科书定义，不列干巴巴的流程图，而是带你 逐帧拆解Spring Boot 3.2+环境下Bean从诞生到消亡的完整生命切片，用真实调试日志还原每一步的触发条件、参数状态和常见陷阱 。你不需要记住所有接口名，但必须知道：当你的业务逻辑需要在某个特定时刻介入时，该去哪个“工位”申请权限。

2. Spring Boot 3.2下的生命周期全景图：从BeanDefinition注册到JVM卸载

要真正理解生命周期，必须先看清它的运行载体——不是某个孤立的类，而是一整套协同工作的基础设施。在Spring Boot 3.2（基于Spring Framework 6.1）中，整个链条已高度模块化，各环节职责清晰，我们按时间轴梳理：

2.1 阶段零：BeanDefinition的静态注册（非运行时，但决定后续一切）

很多人误以为生命周期从 new 开始，其实真正的起点早在应用启动前就已完成。当你在类上标注 @Component 、 @Service ，或在 @Configuration 类中用 @Bean 声明方法时，Spring的 ClassPathBeanDefinitionScanner 会在启动初期扫描所有类路径，将这些元信息解析为 BeanDefinition 对象，并存入 BeanDefinitionRegistry （通常是 DefaultListableBeanFactory ）。此时Bean尚未实例化，甚至没有类加载——它只是一个描述“将来如何创建Bean”的配方。

提示： @ConditionalOnMissingBean 这类条件注解，就是在这一阶段生效的。Spring会先扫描所有已注册的BeanDefinition，再根据条件判断是否跳过当前Bean的注册。如果你在 @Bean 方法里手动 new 了一个对象并返回，这个对象不会被Spring管理，自然也不进入后续生命周期。

2.2 阶段一：实例化（Instantiation）——“造出空壳子”

当容器首次需要某个Bean（比如通过 getBean() 显式获取，或作为其他Bean的依赖被注入时）， AbstractAutowireCapableBeanFactory 会调用 createBeanInstance() 。这里的关键是： 此时Bean只是一个刚分配内存、未执行任何构造函数逻辑的“空壳子” 。Spring默认使用反射调用无参构造器，但你也可以通过 @Autowired 标注构造器，强制Spring用有参构造器创建——这是推荐的不可变依赖注入方式。

@Component
public class UserService {
    private final UserRepository userRepository; // final修饰，强调不可变性
    
    // Spring会优先选择此构造器，确保userRepository在实例化时即注入
    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
        System.out.println("UserService实例化完成，但userRepository尚未注入！"); 
        // 注意：此处userRepository仍为null！因为属性注入在下一阶段
    }
}

2.3 阶段二：属性填充（Populate Properties）——“往壳子里塞零件”

实例化完成后，容器立即进入属性填充阶段。 populateBean() 方法会遍历BeanDefinition中记录的所有属性（包括 @Value 、 @Autowired 、 @Resource 等标注的字段或setter方法），通过 BeanWrapper 进行赋值。此时，所有依赖的Bean（如上面的 UserRepository ）必须已创建并处于可用状态，否则抛出 BeanCurrentlyInCreationException 。

注意： @Autowired 字段注入和 @PostConstruct 方法执行之间存在一个隐含但关键的间隙—— 所有依赖注入完成后，Bean才真正“完整”，但此时其业务逻辑尚未初始化 。很多初学者在此处犯错：在 @PostConstruct 里调用依赖对象的方法，却忘了检查该依赖自身是否也完成了初始化（比如依赖的DataSource是否已建立连接池）。

2.4 阶段三：初始化（Initialization）——“点亮设备，让它能干活”

这才是生命周期中最复杂、最常被干预的阶段。它分为三个子阶段，严格按序执行：

2.4.1 BeanPostProcessor前置处理（postProcessBeforeInitialization）

所有实现了 BeanPostProcessor 接口的Bean（如 CommonAnnotationBeanPostProcessor 处理 @PostConstruct ， AutowiredAnnotationBeanPostProcessor 处理 @Autowired ）会在此刻介入。Spring会遍历所有已注册的 BeanPostProcessor ，按 Ordered 接口或 @Order 注解排序，依次调用其 postProcessBeforeInitialization() 方法。这是你插入自定义逻辑的第一个黄金窗口。

@Component
@Order(1)
public class LoggingBeanPostProcessor implements BeanPostProcessor {
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("【前置处理】Bean '" + beanName + "' 开始初始化，类型：" + bean.getClass().getSimpleName());
        return bean; // 必须返回bean，否则后续流程中断
    }
}

2.4.2 初始化回调（InitializingBean & @PostConstruct）

紧接着，容器检查Bean是否实现了 InitializingBean 接口，若是，则调用 afterPropertiesSet() ；同时， CommonAnnotationBeanPostProcessor 会扫描Bean的 @PostConstruct 标注方法并执行。 注意执行顺序：