如何通过 Spring 源码理解 Bean 生命周期的扩展点实现自定义容器逻辑

先分享几个核心判断。如果你试图深入理解Spring Bean的生命周期，最有效的方法不是从头到尾通读AbstractAutowireCapableBeanFactory的全部源码，而是盯住doCreateBean()方法里那几处关键的回调调用点——它们就是所有扩展点落地的物理位置。这个方法论一旦掌握，整个Bean的创建流程就在眼前了。

doCreateBean()是核心战场

在Spring 6.x中，doCreateBean()是处理Bean从实例化、初始化到注册的全流程主干方法。它并非简单顺序执行，而是按阶段插入回调，每个扩展点都在这里被显式调用，具体表现在四个关键动作上：

• applyBeanPostProcessorsBeforeInitialization() 会调用所有注册的BeanPostProcessor.postProcessBeforeInitialization()实现
• invokeInitMethods() 先检查Bean是否实现了InitializingBean接口并调用afterPropertiesSet()，再通过反射调用@Bean中配置的initMethod或XML中定义的init-method
• applyBeanPostProcessorsAfterInitialization() 负责调用所有BeanPostProcessor.postProcessAfterInitialization()实现
• registerDisposableBeanIfNecessary() 将DisposableBean.destroy()或配置的destroy-method封装进DisposableBeanAdapter，等待容器关闭时触发销毁逻辑

需要强调的是，这些并非“约定俗成”的钩子，而是硬编码在流程里的真实方法调用。你加的@PostConstruct注解，最终也是由CommonAnnotationBeanPostProcessor在postProcessBeforeInitialization()中扫描并执行的。

SmartInitializingSingleton的特殊之处

SmartInitializingSingleton.afterSingletonsInstantiated()是一个特例——它不参与单个Bean的生命周期。它的触发时机是在整个容器刷新流程的后期，所有非懒加载单例Bean都已创建完毕后才会被统一回调。具体来说，这个调用发生在finishBeanFactoryInitialization()方法结束之后，属于容器级的扩展，而非Bean级扩展。

这意味着两件事：一方面，它无法访问某个Bean的具体属性或状态，因为此时Bean的初始化可能还没完成；另一方面，它非常适合做全局就绪通知，比如启动健康检查服务、预热缓存、校验配置一致性等场景。但有一点需要明确：它不能替代@PostConstruct或BeanPostProcessor去干预单个Bean的行为。

@PostConstruct与InitializingBean的执行顺序

这两者都发生在初始化阶段，但实际执行顺序由InitDestroyAnnotationBeanPostProcessor严格把控，具体优先级如下：

• 先执行@PostConstruct标注的方法（通过反射调用，不依赖接口）
• 再执行InitializingBean.afterPropertiesSet()
• 最后执行XML或@Bean(initMethod="...")配置的自定义初始化方法

这个顺序并非依靠注册先后，而是写死在InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization()的内部逻辑中。因此，如果你同时使用了这三种方式，必须按照这个顺序设计依赖关系，否则很可能拿到未初始化完成的字段值。

销毁时机的常见陷阱

销毁逻辑看似简单，但有两个地方容易被忽略：

第一个问题是@PreDestroy方法的触发条件。它不是在JVM退出时自动调用，而是在Spring容器调用ConfigurableApplicationContext.close()或AbstractApplicationContext.doClose()时触发。如果应用是war包部署在Tomcat中，这对应于ContextLoaderListener接收到ServletContextEvent；如果是Spring Boot，默认会绑定到JVM shutdown hook。但一旦你禁用了spring.main.register-shutdown-hook=false，@PreDestroy就完全不会执行。

第二个问题是执行入口的统一性。DisposableBean.destroy()和@PreDestroy属于同一轮回调，而destroy-method配置的方法会被包装进DisposableBeanAdapter，三者共享同一个执行入口。它们之间并没有严格的先后顺序，只是被统一收集、统一遍历调用。

换个角度理解：销毁不是“自动发生”的，它强依赖容器是否被显式关闭。容器没关，哪怕JVM还活着，Bean的销毁逻辑就永远卡在内存里。