Spring Bean的生命周期详解：不只是@PostConstruct和@PreDestroy那么简单

> 曾经我以为在方法上加个@PostConstruct注解就是理解了Bean生命周期，直到那个Spring容器启动时诡异的NPE让我重新审视了整个初始化过程。

记得那是我们微服务项目上线前的一次压力测试，一个看似简单的配置Bean在容器启动时抛出了空指针异常。但奇怪的是，这个异常只在特定环境下出现，而且代码中明明有@PostConstruct初始化逻辑。这次排查让我深入理解了Spring Bean生命周期的复杂性，也让我明白了为什么简单的注解背后隐藏着如此精妙的设计。

## 一、从一个诡异的空指针异常说起

先来看看我当时遇到的问题代码：

```java
@Component
public class ConfigLoader {
    
    @Autowired
    private Environment env;
    
    private Map<String, String> configMap;
    
    @PostConstruct
    public void init() {
        // 加载配置到内存
        configMap = loadConfigFromDB();
        System.out.println("配置加载完成，数量：" + configMap.size());
    }
    
    @EventListener
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // 这里偶尔会抛出NPE！
        System.out.println("容器刷新完成，当前配置数：" + configMap.size());
    }
    
    private Map<String, String> loadConfigFromDB() {
        // 模拟从数据库加载配置
        return Collections.singletonMap("key", "value");
    }
}
```

在大多数情况下，这段代码运行正常。但在高并发启动多个Spring容器时，`onApplicationEvent`方法中的`configMap.size()`偶尔会抛出NPE。这让我开始怀疑：**@PostConstruct真的能保证在事件监听器之前执行吗？**

## 二、Bean生命周期的全景图：比想象中复杂得多

通过阅读Spring源码和大量调试，我绘制出了完整的Bean生命周期图谱：

```
实例化 → 属性赋值 → Aware接口回调 → BeanPostProcessor前置处理 → 
初始化方法 → BeanPostProcessor后置处理 → Bean就绪 → 
容器关闭 → 销毁方法
```

但这只是表面，每个阶段都有更深层的细节。

### 2.1 生命周期阶段的详细分解

```java
// 这是Spring内部处理Bean生命周期的核心方法
protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
    // 1. Aware接口回调
    invokeAwareMethods(beanName, bean);
    
    // 2. BeanPostProcessor前置处理
    Object wrappedBean = bean;
    if (mbd == null || !mbd.isSynthetic()) {
        wrappedBean = applyBeanPostProcessorsBeforeInitialization(bean, beanName);
    }
    
    // 3. 初始化方法
    try {
        invokeInitMethods(beanName, wrappedBean, mbd);
    } catch (Throwable ex) {
        throw new BeanCreationException(...);
    }
    
    // 4. BeanPostProcessor后置处理
    if (mbd == null || !mbd.isSynthetic()) {
        wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
    }
    return wrappedBean;
}
```

## 三、深入每个关键阶段的理解

### 3.1 实例化阶段：不只是new一个对象那么简单

Spring通过反射实例化对象，但这过程中包含了复杂的策略判断：

```java
@Component
public class UserService {
    
    private final DataSource dataSource;
    
    // 构造器注入：实例化阶段就完成依赖注入
    public UserService(DataSource dataSource) {
        this.dataSource = dataSource;
        System.out.println("1. 构造器执行 - 实例化阶段");
    }
}
```

**关键点**：如果使用构造器注入，依赖解析在实例化阶段就完成了。

### 3.2 Aware接口回调：让Bean感知容器环境

Spring提供了一系列Aware接口，让Bean能够感知到容器信息：

```java
@Component
public class MyBean implements BeanNameAware, BeanFactoryAware, ApplicationContextAware {
    
    private String beanName;
    private BeanFactory beanFactory;
    private ApplicationContext applicationContext;
    
    @Override
    public void setBeanName(String name) {
        this.beanName = name;
        System.out.println("2. BeanNameAware回调: " + name);
    }
    
    @Override
    public void setBeanFactory(BeanFactory beanFactory) {
        this.beanFactory = beanFactory;
        System.out.println("3. BeanFactoryAware回调");
    }
    
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
        System.out.println("4. ApplicationContextAware回调");
    }
}
```

**执行顺序**：BeanNameAware → BeanFactoryAware → ApplicationContextAware

### 3.3 BeanPostProcessor：Spring扩展性的基石

BeanPostProcessor是Spring框架扩展性的核心。理解它就能理解Spring很多功能的实现原理：

```java
@Component
public class MyBeanPostProcessor implements BeanPostProcessor {
    
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        if (bean instanceof UserService) {
            System.out.println("5. BeanPostProcessor前置处理: " + beanName);
        }
        return bean;
    }
    
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        if (bean instanceof UserService) {
            System.out.println("7. BeanPostProcessor后置处理: " + beanName);
            // 这里可以返回代理对象，AOP就是在这里实现的
        }
        return bean;
    }
}
```

### 3.4 初始化方法的三种方式及其执行顺序

这是最容易混淆的部分，也是我遇到问题的根源：

```java
@Component
public class LifecycleBean implements InitializingBean {
    
    private boolean initialized = false;
    
    // 方式1：@PostConstruct注解
    @PostConstruct
    public void postConstruct() {
        System.out.println("6.1 @PostConstruct方法执行");
        initialized = true;
    }
    
    // 方式2：InitializingBean接口
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("6.2 InitializingBean.afterPropertiesSet执行");
        if (!initialized) {
            throw new IllegalStateException("@PostConstruct未执行？");
        }
    }
    
    // 方式3：XML配置的init-method或@Bean(initMethod)
    public void customInit() {
        System.out.println("6.3 自定义init方法执行");
    }
}
```

**关键发现**：这三种方式的执行顺序是固定的：

1. @PostConstruct注解的方法
2. InitializingBean.afterPropertiesSet()
3. 自定义的init方法

### 3.5 事件监听器的执行时机

回到我最初的问题，事件监听器在什么时候执行？

```java
@Component
public class EventListenerBean {
    
    @EventListener
    public void handleContextRefreshed(ContextRefreshedEvent event) {
        System.out.println("8. ContextRefreshedEvent事件处理");
        // 这个事件在所有单例Bean初始化完成后触发
    }
    
    @EventListener  
    public void handleContextStarted(ContextStartedEvent event) {
        System.out.println("ContextStartedEvent事件处理");
    }
}
```

**问题根源**：ContextRefreshedEvent在**所有**Bean初始化完成后发布，但Bean的初始化顺序是不确定的。如果事件监听器Bean在其他Bean之前初始化，就可能访问到未完全初始化的Bean。

## 四、解决实际问题：Bean依赖和初始化顺序

基于对生命周期的深入理解，我重构了有问题的代码：

### 4.1 方案1：使用@DependsOn控制初始化顺序

```java
@Component
@DependsOn("configLoader")  // 明确声明依赖关系
public class ServiceBean {
    
    @Autowired
    private ConfigLoader configLoader;
    
    @EventListener
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // 现在configLoader肯定已经初始化完成
        System.out.println("安全访问: " + configLoader.getConfigMap().size());
    }
}
```

### 4.2 方案2：使用SmartLifecycle精确控制启动顺序

```java
@Component
public class MyService implements SmartLifecycle {
    
    private volatile boolean running = false;
    
    @Override
    public void start() {
        System.out.println("SmartLifecycle.start()执行");
        // 在这里执行初始化逻辑，可以控制精确的执行时机
        running = true;
    }
    
    @Override
    public void stop() {
        running = false;
    }
    
    @Override
    public boolean isRunning() {
        return running;
    }
    
    @Override
    public int getPhase() {
        return 0;  // 通过phase控制多个SmartLifebean的执行顺序
    }
}
```

### 4.3 方案3：使用@EventListener的条件判断

```java
@Component
public class SafeEventListener {
    
    @Autowired
    private ConfigLoader configLoader;
    
    @EventListener
    public void onContextRefreshed(ContextRefreshedEvent event) {
        // 添加空值检查
        if (configLoader != null && configLoader.getConfigMap() != null) {
            System.out.println("安全访问配置: " + configLoader.getConfigMap().size());
        }
    }
}
```

## 五、高级话题：原型Bean和FactoryBean的生命周期

### 5.1 原型Bean的特殊性

```java
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Component
public class PrototypeBean {
    
    @PostConstruct
    public void init() {
        System.out.println("原型Bean初始化 - 每次获取新实例都会执行");
    }
    
    @PreDestroy
    public void destroy() {
        System.out.println("这个通常不会执行，因为原型Bean的生命周期不由容器管理");
    }
}
```

**重要区别**：原型Bean的@PreDestroy不会自动执行，需要手动清理。

### 5.2 FactoryBean的复杂生命周期

```java
@Component
public class MyFactoryBean implements FactoryBean<MyService> {
    
    @Override
    public MyService getObject() throws Exception {
        System.out.println("FactoryBean.getObject()被调用");
        return new MyService();
    }
    
    @Override
    public Class<?> getObjectType() {
        return MyService.class;
    }
    
    @PostConstruct
    public void init() {
        System.out.println("FactoryBean自身的初始化");
    }
}
```

FactoryBean本身是一个Bean，它生产的对象又是另一个Bean，这带来了双重生命周期。

## 六、实际应用：利用生命周期解决复杂业务问题

在我参与的交易系统中，我们利用Bean生命周期实现了优雅的启动检查：

```java
@Component
public class SystemHealthChecker implements SmartInitializingSingleton {
    
    @Autowired
    private List<HealthCheckable> healthCheckables;
    
    @Override
    public void afterSingletonsInstantiated() {
        // 在所有单例Bean实例化后执行
        System.out.println("开始系统健康检查...");
        
        for (HealthCheckable checker : healthCheckables) {
            if (!checker.healthCheck()) {
                throw new IllegalStateException("健康检查失败: " + checker.getClass().getSimpleName());
            }
        }
        System.out.println("系统健康检查通过");
    }
}
```

**SmartInitializingSingleton.afterSingletonsInstantiated()** 的特别之处：它在所有单例Bean实例化完成后、初始化方法执行前被调用。

## 七、生命周期相关的常见坑点总结

四年经验中遇到的典型问题：

### 7.1 循环依赖导致的初始化顺序问题

```java
@Component
public class ServiceA {
    @Autowired private ServiceB serviceB;
    
    @PostConstruct
    public void init() {
        serviceB.doSomething();  // 可能serviceB还未初始化完成
    }
}

@Component
public class ServiceB {
    @Autowired private ServiceA serviceA;
}
```

### 7.2 AOP代理导致的@PostConstruct不执行

```java
@Component
public class MyService {
    
    @PostConstruct
    public void init() {
        this.internalMethod();  // 直接调用，不会被AOP拦截
    }
    
    @Async
    public void internalMethod() {
        // 异步执行
    }
}
```

### 7.3 事件监听器中的事务问题

```java
@Component
public class TransactionalEventListener {
    
    @TransactionalEventListener
    public void handleEvent(MyEvent event) {
        // 如果事件发布在事务中，这个监听器会在事务提交后执行
        // 但要注意事务回滚的情况
    }
}
```

## 总结

Spring Bean的生命周期远不止@PostConstruct和@PreDestroy那么简单。理解完整的生命周期对于编写健壮的Spring应用至关重要。四年经验让我明白了几个关键点：

1. **顺序很重要**：理解各个回调方法的执行顺序
2. **依赖关系决定初始化顺序**：使用@DependsOn或SmartLifecycle精确控制
3. **事件监听不是万能的**：要注意事件发布时其他Bean的初始化状态
4. **原型Bean有特殊规则**：生命周期管理方式与单例Bean不同

真正的掌握不是记住所有的阶段顺序，而是理解设计背后的哲学：**Spring通过清晰的生命周期阶段，为开发者提供了充分的扩展点，让我们能够在合适的时机介入Bean的创建过程**。

这次深入探究不仅解决了我当时遇到的NPE问题，更重要的是让我建立了系统性理解Spring框架的能力。在后续的Spring Boot自动配置、Spring Cloud组件集成等工作中，这种对生命周期的深刻理解都发挥了重要作用。

AI摘要

文章以一次诡异NPE为引，拆解Spring Bean完整生命周期：实例化→属性赋值→Aware→BeanPostProcessor→初始化（@PostConstruct、InitializingBean、自定义init）→就绪→销毁。指出事件监听器执行顺序不确定是问题根源，给出@DependsOn、SmartLifecycle、空值检查三种解法，并总结原型Bean、FactoryBean、循环依赖、AOP代理等常见坑，强调“顺序+依赖+事件+扩展点”是掌握Spring的关键。

曾经我以为在方法上加个@PostConstruct注解就是理解了Bean生命周期，直到那个Spring容器启动时诡异的NPE让我重新审视了整个初始化过程。

一、从一个诡异的空指针异常说起

先来看看我当时遇到的问题代码：

@Component
public class ConfigLoader {
    
    @Autowired
    private Environment env;
    
    private Map<String, String> configMap;
    
    @PostConstruct
    public void init() {
        // 加载配置到内存
        configMap = loadConfigFromDB();
        System.out.println("配置加载完成，数量：" + configMap.size());
    }
    
    @EventListener
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // 这里偶尔会抛出NPE！
        System.out.println("容器刷新完成，当前配置数：" + configMap.size());
    }
    
    private Map<String, String> loadConfigFromDB() {
        // 模拟从数据库加载配置
        return Collections.singletonMap("key", "value");
    }
}

在大多数情况下，这段代码运行正常。但在高并发启动多个Spring容器时，onApplicationEvent方法中的configMap.size()偶尔会抛出NPE。这让我开始怀疑：@PostConstruct真的能保证在事件监听器之前执行吗？

二、Bean生命周期的全景图：比想象中复杂得多

通过阅读Spring源码和大量调试，我绘制出了完整的Bean生命周期图谱：

实例化 → 属性赋值 → Aware接口回调 → BeanPostProcessor前置处理 → 
初始化方法 → BeanPostProcessor后置处理 → Bean就绪 → 
容器关闭 → 销毁方法

但这只是表面，每个阶段都有更深层的细节。

2.1 生命周期阶段的详细分解

// 这是Spring内部处理Bean生命周期的核心方法
protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
    // 1. Aware接口回调
    invokeAwareMethods(beanName, bean);
    
    // 2. BeanPostProcessor前置处理
    Object wrappedBean = bean;
    if (mbd == null || !mbd.isSynthetic()) {
        wrappedBean = applyBeanPostProcessorsBeforeInitialization(bean, beanName);
    }
    
    // 3. 初始化方法
    try {
        invokeInitMethods(beanName, wrappedBean, mbd);
    } catch (Throwable ex) {
        throw new BeanCreationException(...);
    }
    
    // 4. BeanPostProcessor后置处理
    if (mbd == null || !mbd.isSynthetic()) {
        wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
    }
    return wrappedBean;
}

三、深入每个关键阶段的理解

3.1 实例化阶段：不只是new一个对象那么简单

Spring通过反射实例化对象，但这过程中包含了复杂的策略判断：

@Component
public class UserService {
    
    private final DataSource dataSource;
    
    // 构造器注入：实例化阶段就完成依赖注入
    public UserService(DataSource dataSource) {
        this.dataSource = dataSource;
        System.out.println("1. 构造器执行 - 实例化阶段");
    }
}

关键点：如果使用构造器注入，依赖解析在实例化阶段就完成了。

3.2 Aware接口回调：让Bean感知容器环境

Spring提供了一系列Aware接口，让Bean能够感知到容器信息：

@Component
public class MyBean implements BeanNameAware, BeanFactoryAware, ApplicationContextAware {
    
    private String beanName;
    private BeanFactory beanFactory;
    private ApplicationContext applicationContext;
    
    @Override
    public void setBeanName(String name) {
        this.beanName = name;
        System.out.println("2. BeanNameAware回调: " + name);
    }
    
    @Override
    public void setBeanFactory(BeanFactory beanFactory) {
        this.beanFactory = beanFactory;
        System.out.println("3. BeanFactoryAware回调");
    }
    
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
        System.out.println("4. ApplicationContextAware回调");
    }
}

执行顺序：BeanNameAware → BeanFactoryAware → ApplicationContextAware

3.3 BeanPostProcessor：Spring扩展性的基石

BeanPostProcessor是Spring框架扩展性的核心。理解它就能理解Spring很多功能的实现原理：

@Component
public class MyBeanPostProcessor implements BeanPostProcessor {
    
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        if (bean instanceof UserService) {
            System.out.println("5. BeanPostProcessor前置处理: " + beanName);
        }
        return bean;
    }
    
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        if (bean instanceof UserService) {
            System.out.println("7. BeanPostProcessor后置处理: " + beanName);
            // 这里可以返回代理对象，AOP就是在这里实现的
        }
        return bean;
    }
}

3.4 初始化方法的三种方式及其执行顺序

这是最容易混淆的部分，也是我遇到问题的根源：

@Component
public class LifecycleBean implements InitializingBean {
    
    private boolean initialized = false;
    
    // 方式1：@PostConstruct注解
    @PostConstruct
    public void postConstruct() {
        System.out.println("6.1 @PostConstruct方法执行");
        initialized = true;
    }
    
    // 方式2：InitializingBean接口
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("6.2 InitializingBean.afterPropertiesSet执行");
        if (!initialized) {
            throw new IllegalStateException("@PostConstruct未执行？");
        }
    }
    
    // 方式3：XML配置的init-method或@Bean(initMethod)
    public void customInit() {
        System.out.println("6.3 自定义init方法执行");
    }
}

关键发现：这三种方式的执行顺序是固定的：

@PostConstruct注解的方法
InitializingBean.afterPropertiesSet()
自定义的init方法

3.5 事件监听器的执行时机

回到我最初的问题，事件监听器在什么时候执行？

@Component
public class EventListenerBean {
    
    @EventListener
    public void handleContextRefreshed(ContextRefreshedEvent event) {
        System.out.println("8. ContextRefreshedEvent事件处理");
        // 这个事件在所有单例Bean初始化完成后触发
    }
    
    @EventListener  
    public void handleContextStarted(ContextStartedEvent event) {
        System.out.println("ContextStartedEvent事件处理");
    }
}

问题根源：ContextRefreshedEvent在所有Bean初始化完成后发布，但Bean的初始化顺序是不确定的。如果事件监听器Bean在其他Bean之前初始化，就可能访问到未完全初始化的Bean。

四、解决实际问题：Bean依赖和初始化顺序

基于对生命周期的深入理解，我重构了有问题的代码：

4.1 方案1：使用@DependsOn控制初始化顺序

@Component
@DependsOn("configLoader")  // 明确声明依赖关系
public class ServiceBean {
    
    @Autowired
    private ConfigLoader configLoader;
    
    @EventListener
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // 现在configLoader肯定已经初始化完成
        System.out.println("安全访问: " + configLoader.getConfigMap().size());
    }
}

4.2 方案2：使用SmartLifecycle精确控制启动顺序

@Component
public class MyService implements SmartLifecycle {
    
    private volatile boolean running = false;
    
    @Override
    public void start() {
        System.out.println("SmartLifecycle.start()执行");
        // 在这里执行初始化逻辑，可以控制精确的执行时机
        running = true;
    }
    
    @Override
    public void stop() {
        running = false;
    }
    
    @Override
    public boolean isRunning() {
        return running;
    }
    
    @Override
    public int getPhase() {
        return 0;  // 通过phase控制多个SmartLifebean的执行顺序
    }
}

4.3 方案3：使用@EventListener的条件判断

@Component
public class SafeEventListener {
    
    @Autowired
    private ConfigLoader configLoader;
    
    @EventListener
    public void onContextRefreshed(ContextRefreshedEvent event) {
        // 添加空值检查
        if (configLoader != null && configLoader.getConfigMap() != null) {
            System.out.println("安全访问配置: " + configLoader.getConfigMap().size());
        }
    }
}

五、高级话题：原型Bean和FactoryBean的生命周期

5.1 原型Bean的特殊性

@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Component
public class PrototypeBean {
    
    @PostConstruct
    public void init() {
        System.out.println("原型Bean初始化 - 每次获取新实例都会执行");
    }
    
    @PreDestroy
    public void destroy() {
        System.out.println("这个通常不会执行，因为原型Bean的生命周期不由容器管理");
    }
}

重要区别：原型Bean的@PreDestroy不会自动执行，需要手动清理。

5.2 FactoryBean的复杂生命周期

@Component
public class MyFactoryBean implements FactoryBean<MyService> {
    
    @Override
    public MyService getObject() throws Exception {
        System.out.println("FactoryBean.getObject()被调用");
        return new MyService();
    }
    
    @Override
    public Class<?> getObjectType() {
        return MyService.class;
    }
    
    @PostConstruct
    public void init() {
        System.out.println("FactoryBean自身的初始化");
    }
}

FactoryBean本身是一个Bean，它生产的对象又是另一个Bean，这带来了双重生命周期。

六、实际应用：利用生命周期解决复杂业务问题

在我参与的交易系统中，我们利用Bean生命周期实现了优雅的启动检查：

@Component
public class SystemHealthChecker implements SmartInitializingSingleton {
    
    @Autowired
    private List<HealthCheckable> healthCheckables;
    
    @Override
    public void afterSingletonsInstantiated() {
        // 在所有单例Bean实例化后执行
        System.out.println("开始系统健康检查...");
        
        for (HealthCheckable checker : healthCheckables) {
            if (!checker.healthCheck()) {
                throw new IllegalStateException("健康检查失败: " + checker.getClass().getSimpleName());
            }
        }
        System.out.println("系统健康检查通过");
    }
}

SmartInitializingSingleton.afterSingletonsInstantiated() 的特别之处：它在所有单例Bean实例化完成后、初始化方法执行前被调用。

七、生命周期相关的常见坑点总结

四年经验中遇到的典型问题：

7.1 循环依赖导致的初始化顺序问题

@Component
public class ServiceA {
    @Autowired private ServiceB serviceB;
    
    @PostConstruct
    public void init() {
        serviceB.doSomething();  // 可能serviceB还未初始化完成
    }
}

@Component
public class ServiceB {
    @Autowired private ServiceA serviceA;
}

7.2 AOP代理导致的@PostConstruct不执行

@Component
public class MyService {
    
    @PostConstruct
    public void init() {
        this.internalMethod();  // 直接调用，不会被AOP拦截
    }
    
    @Async
    public void internalMethod() {
        // 异步执行
    }
}

7.3 事件监听器中的事务问题

@Component
public class TransactionalEventListener {
    
    @TransactionalEventListener
    public void handleEvent(MyEvent event) {
        // 如果事件发布在事务中，这个监听器会在事务提交后执行
        // 但要注意事务回滚的情况
    }
}

总结

Spring Bean的生命周期远不止@PostConstruct和@PreDestroy那么简单。理解完整的生命周期对于编写健壮的Spring应用至关重要。四年经验让我明白了几个关键点：

顺序很重要：理解各个回调方法的执行顺序
依赖关系决定初始化顺序：使用@DependsOn或SmartLifecycle精确控制
事件监听不是万能的：要注意事件发布时其他Bean的初始化状态
原型Bean有特殊规则：生命周期管理方式与单例Bean不同

真正的掌握不是记住所有的阶段顺序，而是理解设计背后的哲学：Spring通过清晰的生命周期阶段，为开发者提供了充分的扩展点，让我们能够在合适的时机介入Bean的创建过程。

版权声明 ▶ 本网站名称：黄磊的博客
▶ 本文标题：Spring Bean的生命周期详解：不只是@PostConstruct和@PreDestroy那么简单
▶ 本文链接：https://www.huangleicole.com/backend-related/47.html
▶ 转载本站文章需要遵守：商业转载请联系站长，非商业转载请注明出处！！

如果觉得我的文章对你有用，请随意赞赏

Spring Bean的生命周期详解：不只是@PostConstruct和@PreDestroy那么简单

一、从一个诡异的空指针异常说起

二、Bean生命周期的全景图：比想象中复杂得多

2.1 生命周期阶段的详细分解

三、深入每个关键阶段的理解

3.1 实例化阶段：不只是new一个对象那么简单

3.2 Aware接口回调：让Bean感知容器环境

3.3 BeanPostProcessor：Spring扩展性的基石

3.4 初始化方法的三种方式及其执行顺序

3.5 事件监听器的执行时机

四、解决实际问题：Bean依赖和初始化顺序

4.1 方案1：使用@DependsOn控制初始化顺序

4.2 方案2：使用SmartLifecycle精确控制启动顺序

4.3 方案3：使用@EventListener的条件判断

五、高级话题：原型Bean和FactoryBean的生命周期

5.1 原型Bean的特殊性

5.2 FactoryBean的复杂生命周期

六、实际应用：利用生命周期解决复杂业务问题

七、生命周期相关的常见坑点总结

7.1 循环依赖导致的初始化顺序问题

7.2 AOP代理导致的@PostConstruct不执行

7.3 事件监听器中的事务问题

总结

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

代码评审的艺术：从挑毛病到促进共同成长

从“能跑就行”到“心中有数”：我的集合框架踩坑实录

深度复制与浅度复制：一次修改引发的“血案”

告别乱糟糟的代码：我如何用Lombok让Java代码更清爽

“魔法值”退散！我用常量类和枚举让代码更健壮

你的线程池还在裸奔吗？详解ThreadPoolExecutor七大核心参数与配置心得

超越CRUD：利用Spring的Validator做更优雅的参数校验

一年回顾：从一个CRUD新手到有思想的开发者

分布式ID生成器：从数据库自增ID到Snowflake算法的选型与实践

别再@Async乱用了：浅尝辄止的异步编程踩坑与思考

Spring Bean的生命周期详解：不只是@PostConstruct和@PreDestroy那么简单

一、从一个诡异的空指针异常说起

二、Bean生命周期的全景图：比想象中复杂得多

2.1 生命周期阶段的详细分解

三、深入每个关键阶段的理解

3.1 实例化阶段：不只是new一个对象那么简单

3.2 Aware接口回调：让Bean感知容器环境

3.3 BeanPostProcessor：Spring扩展性的基石

3.4 初始化方法的三种方式及其执行顺序

3.5 事件监听器的执行时机

四、解决实际问题：Bean依赖和初始化顺序

4.1 方案1：使用@DependsOn控制初始化顺序

4.2 方案2：使用SmartLifecycle精确控制启动顺序

4.3 方案3：使用@EventListener的条件判断

五、高级话题：原型Bean和FactoryBean的生命周期

5.1 原型Bean的特殊性

5.2 FactoryBean的复杂生命周期

六、实际应用：利用生命周期解决复杂业务问题

七、生命周期相关的常见坑点总结

7.1 循环依赖导致的初始化顺序问题

7.2 AOP代理导致的@PostConstruct不执行

7.3 事件监听器中的事务问题

总结

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

Spring Bean的生命周期详解：不只是@PostConstruct和@PreDestroy那么简单

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款