Spring Bean生命周期始于容器初始化流程，而非new实例化；依赖注入完成后才触发@PostConstruct等初始化回调；@PreDestroy仅在容器正常关闭时执行；SmartLifecycle可协调多组件就绪顺序；prototype Bean无销毁管理。
Spring Bean的生命周期从哪里开始控制？
Bean的生命周期不是由new出来的那一刻决定的，而是从Spring容器调用BeanFactory或ApplicationContext的初始化流程开始。你写的@PostConstruct、InitializingBean.afterPropertiesSet()、自定义init-method，都只是生命周期中“属性赋值之后、可用之前”的一个环节。
关键点在于：容器必须完成依赖注入（DI）后，才会触发初始化回调。如果某个@Autowired字段为null，那@PostConstruct方法里访问它一定会NPE——这不是生命周期没走完，是DI根本没成功。
@Component
public class UserService {
@Autowired
private UserRepository userRepository; // 若未扫描到实现类，此处为null
@PostConstruct
public void init() {
userRepository.findAll(); // 抛出 NullPointerException
}}
常见原因包括：
-
UserRe接口没有对应
pository
@Repository实现类 - 实现类不在
@ComponentScan路径下 - 使用了
@Primary但多个候选Bean类型冲突，导致注入失败（此时会报NoUniqueBeanDefinitionException，而非静默null）
为什么@PreDestroy有时根本不执行？
@PreDestroy只在Spring容器正常关闭时触发。这意味着：
- 用
AnnotationConfigApplicationContext启动后，必须显式调用close() - Spring Boot应用中，只有JVM收到
SIGTERM（如kill -15）才会触发；直接kill -9或IDE点击红色停止按钮（部分IDE强制kill），@PreDestroy不会执行 - Web环境里，Servlet容器（如Tomcat）销毁
ContextLoaderListener时才调用，若应用被热部署插件绕过标准销毁流程，也会跳过
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
ctx.getBean(UserService.class);
// 忘记这一行 → @PreDestroy 永远不执行
ctx.close();
}
SmartLifecycle比@PostConstruct多解决什么问题？
@PostConstruct只保证单个Bean初始化完成，但不保证它依赖的其他Bean已就绪（哪怕加了@DependsOn，也只是控制创建顺序，不控制“可用状态”）。而SmartLifecycle提供了两个关键能力：
-
isAutoStartup()控制是否随容器自动启动 -
getPhase()定义启动/停止阶段，数值越小越早启动、越晚停止，能精准协调多个组件的就绪顺序（比如消息队列消费者必须等连接池完全建立后才能开始拉取消息）
@Component
public class KafkaConsumerLifecycle implements SmartLifecycle {
private volatile boolean isRunning = false;
@Override
public void start() {
// 真正启动消费逻辑
isRunning = true;
}
@Override
public void stop() {
// 安全关闭消费，等待正在处理的消息完成
isRunning = false;
}
@Override
public int getPhase() {
return Integer.MAX_VALUE; // 最晚启动，确保DB、Cache等已就绪
}}
prototype作用域的Bean真的有完整生命周期吗？
没有。Spring只管理singleton Bean的完整生命周期（创建→初始化→使用→销毁）。对prototype Bean：
- 容器只负责创建和注入依赖（调用构造器 +
@Autowired+@PostConstruct） -
不调用任何销毁回调：
@PreDestroy、DisposableBean.destroy()、destroy-method全部被忽略 - 你必须自己负责清理资源（比如在业务代码里显式调用
close()或shutdown()）
如果你需要类似销毁逻辑，只能：
- 手动持有Bean引用并在合适时机调用清理方法
- 使用
ObjectFactory或Provider延迟获取，配合try-with-resources或finally块 - 改用
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)并配合AOP拦截，但这属于高阶hack，易出错
真正需要“每次新建都带清理”的场景，往往说明设计上该用工厂模式或把资源管理提到更高层，而不是依赖Spring替你管prototype的销毁。
