Spring Framework 系列 #04：Spring IoC 与 Bean 生命周期

本文从理论溯源出发，经 Martin Fowler 2004 年的经典定义，逐层深入 Spring IoC 的单 Bean 微观视角：BeanDefinition 加载、9 阶段生命周期源码链路、@Autowired vs @Resource 注入机制，以及 @Configuration Full/Lite 模式差异，是容器启动流程的配套微观篇。

目录

理论基础

IoC 的本质

控制反转（Inversion of Control） 是一个设计原则，核心是把"谁来负责创建依赖对象"这件事的控制权，从应用代码转移到外部框架。

传统方式，对象自己负责获取依赖：

// 主动查找：控制权在 OrderService 自己手里
public class OrderService {
    private InventoryService inventory = new InventoryService(); // 直接 new
    private UserService user = ServiceLocator.get(UserService.class); // 主动查找
}

IoC 之后，依赖由外部注入：

// 被动接收：控制权交给容器
public class OrderService {
    private final InventoryService inventory;
    private final UserService user;

    public OrderService(InventoryService inventory, UserService user) {
        this.inventory = inventory; // 由容器注入
        this.user = user;
    }
}

好莱坞原则（Hollywood Principle）："Don't call us, we'll call you." 对象不主动寻找依赖，等容器来调用。

Fowler 2004：IoC → Dependency Injection

2004 年，Martin Fowler 在《Inversion of Control Containers and the Dependency Injection pattern》中指出：IoC 太泛化，几乎任何框架都涉及控制反转，需要更精确的术语——依赖注入（Dependency Injection）。

Fowler 定义了三种注入形式：

Spring 在此基础上延伸，将字段注入（Field Injection，直接注入成员变量）作为第四种方式，但 Fowler 原文没有提及，也是争议最大的一种。

Service Locator vs Dependency Injection

Fowler 在同篇文章中对比了两种模式：

Fowler 的结论：两者都能实现服务配置与使用的分离，DI 的优势在于更彻底地消除应用代码对容器的感知，可测试性更强。

Spring 早期（1.x）同时支持 Service Locator 风格（BeanFactory.getBean()），但官方明确推荐 DI 风格，getBean() 仅用于容器入口点。

IoC 容器体系

BeanFactory vs ApplicationContext

ApplicationContext 持有一个 DefaultListableBeanFactory 作为内部委托，所有 Bean 的注册和查找最终都走它。

继承关系（简化）

BeanFactory
  └── HierarchicalBeanFactory（支持父容器）
        └── ConfigurableBeanFactory
              └── ConfigurableListableBeanFactory
                    └── DefaultListableBeanFactory ← 核心实现

ApplicationContext
  └── ConfigurableApplicationContext
        └── AbstractApplicationContext
              └── AnnotationConfigApplicationContext（注解驱动）
              └── ClassPathXmlApplicationContext（XML 驱动）

BeanDefinition

是什么

BeanDefinition 是 Bean 的"配方"——Spring 先把所有配置信息解析成 BeanDefinition 注册到 BeanDefinitionRegistry，实例化阶段再按配方创建对象。

配置来源                   解析器                       注册目标
──────────────────────────────────────────────────────────────
@Component 扫描   →  ClassPathBeanDefinitionScanner  →  BeanDefinitionRegistry
@Configuration   →  ConfigurationClassPostProcessor  →  BeanDefinitionRegistry
XML              →  XmlBeanDefinitionReader           →  BeanDefinitionRegistry

核心字段

// AbstractBeanDefinition 核心字段
String beanClassName;           // Bean 的全限定类名
String scope;                   // singleton / prototype / request ...
boolean lazyInit;               // 是否懒加载
String[] dependsOn;             // depends-on 依赖
ConstructorArgumentValues constructorArgumentValues; // 构造器参数
MutablePropertyValues propertyValues;  // 属性注入值
String initMethodName;          // init-method
String destroyMethodName;       // destroy-method
boolean primary;                // @Primary
boolean abstractFlag;           // 是否抽象（不实例化）

BeanDefinition 合并

子 BeanDefinition 会继承父 BeanDefinition 的属性，通过 getMergedLocalBeanDefinition() 合并为 RootBeanDefinition 后才用于实例化。这是 XML 时代 <bean parent="..."> 的配方继承机制。

Bean 生命周期

完整流程（9 阶段）

源码主干路径

// AbstractBeanFactory#doGetBean（精简）
protected <T> T doGetBean(String name, ...) {
    // 1. 先查单例池（三级缓存）
    Object sharedInstance = getSingleton(beanName);
    if (sharedInstance != null) {
        return getObjectForBeanInstance(sharedInstance, name, beanName, null);
    }
    // 2. 合并 BeanDefinition
    RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
    // 3. 处理 depends-on
    // 4. 创建 Bean
    if (mbd.isSingleton()) {
        sharedInstance = getSingleton(beanName, () -> createBean(beanName, mbd, args));
    }
    return (T) getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}

// AbstractAutowireCapableBeanFactory#doCreateBean（精简）
protected Object doCreateBean(String beanName, RootBeanDefinition mbd, Object[] args) {
    // ④ 实例化
    BeanWrapper instanceWrapper = createBeanInstance(beanName, mbd, args);
    Object bean = instanceWrapper.getWrappedInstance();

    // ⑤ 提前暴露（解决循环依赖）
    if (earlySingletonExposure) {
        addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
    }

    // ⑥ 属性注入
    populateBean(beanName, mbd, instanceWrapper);

    // ⑦ 初始化
    Object exposedObject = initializeBean(beanName, bean, mbd);

    return exposedObject;
}

initializeBean 展开

// AbstractAutowireCapableBeanFactory#initializeBean（精简）
protected Object initializeBean(String beanName, Object bean, RootBeanDefinition mbd) {
    // Aware 回调
    invokeAwareMethods(beanName, bean);

    // BeanPostProcessor before（@PostConstruct 由 CommonAnnotationBeanPostProcessor 处理）
    Object wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);

    // init-method（afterPropertiesSet → init-method）
    invokeInitMethods(beanName, wrappedBean, mbd);

    // BeanPostProcessor after（AbstractAutoProxyCreator 在此创建 AOP 代理）
    wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);

    return wrappedBean;
}

初始化方法执行顺序

@PostConstruct          ← CommonAnnotationBeanPostProcessor 处理（before 阶段）
afterPropertiesSet()    ← InitializingBean 接口
init-method             ← XML / @Bean(initMethod="...") 指定

销毁顺序与之镜像：@PreDestroy → destroy() → destroy-method

构造器推断

createBeanInstance() 调用 determineConstructorsFromBeanPostProcessors()（实际由 AutowiredAnnotationBeanPostProcessor 处理），推断规则：

关键扩展点

BeanPostProcessor 家族

BeanPostProcessor
  ├── postProcessBeforeInitialization    ← 初始化前（@PostConstruct 在此）
  └── postProcessAfterInitialization     ← 初始化后（AOP 代理在此）

InstantiationAwareBeanPostProcessor（继承 BPP）
  ├── postProcessBeforeInstantiation     ← 实例化前（可短路）
  ├── postProcessAfterInstantiation      ← 实例化后（可跳过注入）
  └── postProcessProperties              ← 属性注入（@Autowired 在此）

DestructionAwareBeanPostProcessor（继承 BPP）
  └── postProcessBeforeDestruction       ← 销毁前（@PreDestroy 在此）

常见 BeanPostProcessor 实现

BeanFactoryPostProcessor vs BeanPostProcessor

BeanDefinitionRegistryPostProcessor 继承 BeanFactoryPostProcessor，还能动态注册新的 BeanDefinition（ConfigurationClassPostProcessor 是其典型实现）。

注入机制

@Autowired vs @Resource

@Autowired 源码路径

// AutowiredAnnotationBeanPostProcessor#postProcessProperties
// → findAutowiringMetadata（扫描 @Autowired 字段/方法）
// → InjectionMetadata#inject
// → AutowiredFieldElement#inject（字段注入）
//   → beanFactory.resolveDependency(descriptor, beanName, ...)
//     → DefaultListableBeanFactory#doResolveDependency
//       → findAutowireCandidates（byType 查找候选）
//       → determineAutowireCandidate（byName 决胜 或 @Primary/@Priority）

三种注入方式对比

Spring 官方推荐构造器注入；@Autowired 作用于唯一构造器时可省略注解（Spring 4.3+）。

配置类模式

Full 模式（@Configuration）

@Configuration 类会被 CGLIB 代理，代理逻辑拦截所有 @Bean 方法调用：

@Configuration
public class AppConfig {

    @Bean
    public ServiceA serviceA() {
        return new ServiceA(serviceB()); // 多次调用 serviceB() 返回同一实例
    }

    @Bean
    public ServiceB serviceB() {
        return new ServiceB();
    }
}

serviceA() 内调用 serviceB() 时，CGLIB 代理拦截，先查容器单例池，找到则直接返回，不会创建新对象。

Lite 模式（@Component / @ComponentScan）

@Component 类上的 @Bean 方法不走 CGLIB 代理：

@Component
public class AppConfig {

    @Bean
    public ServiceA serviceA() {
        return new ServiceA(serviceB()); // ⚠️ 直接 new ServiceB()，每次新建
    }

    @Bean
    public ServiceB serviceB() {
        return new ServiceB();
    }
}

对比

@SpringBootApplication 内含 @SpringBootConfiguration，后者是 @Configuration 的派生注解，因此 Spring Boot 主类是 Full 模式。

proxyBeanMethods=false

Spring Boot 2.2+ 引入，@Configuration(proxyBeanMethods = false) 可手动切换为 Lite 模式，常用于自动配置类提升启动速度：

@Configuration(proxyBeanMethods = false) // 大量 Spring Boot AutoConfiguration 使用此模式
@ConditionalOnClass(DataSource.class)
public class DataSourceAutoConfiguration { ... }

面试常见题

Q1：Bean 生命周期说一下

实例化（构造器）→ 属性注入（@Autowired）→ Aware 回调 → @PostConstruct → afterPropertiesSet → init-method → AOP 代理（BPP after）→ 使用 → @PreDestroy → destroy → destroy-method

Q2：@PostConstruct 和 afterPropertiesSet 哪个先？

@PostConstruct 先。两者都在 initializeBean() 中触发，@PostConstruct 由 CommonAnnotationBeanPostProcessor 在 postProcessBeforeInitialization 阶段处理，而 afterPropertiesSet 在随后的 invokeInitMethods 中调用。

Q3：@Configuration 加不加有什么区别？

加了是 Full 模式（CGLIB 代理），@Bean 方法互调返回同一实例；不加（或 proxyBeanMethods=false）是 Lite 模式，每次调用 @Bean 方法都 new 新对象。

Q4：BeanFactory 和 FactoryBean 的区别？

• BeanFactory：IoC 容器接口，管理所有 Bean
• FactoryBean：一种特殊 Bean，getObject() 返回的是它生产的目标对象，而非 FactoryBean 本身。&beanName 可获取 FactoryBean 实例，beanName 获取目标对象。MyBatis 的 MapperFactoryBean 是典型实现。

Q5：单例 Bean 是线程安全的吗？

不是。Spring 单例只保证容器中只有一个实例，不保证线程安全。若 Bean 中有可变状态（成员变量），需自行加锁或使用 ThreadLocal。无状态 Bean（Controller / Service 通常无状态字段）天然安全。

Q6：prototype Bean 会执行销毁方法吗？

不会。Spring 不会跟踪 prototype Bean 的生命周期，容器不持有其引用，@PreDestroy 和 destroy-method 不会被调用。需手动管理。

参考资料

• Martin Fowler — Inversion of Control Containers and the Dependency Injection pattern (2004)
• Spring Framework Reference — IoC Container
• Spring 容器启动流程源码分析（容器宏观启动流程 / refresh() 12 步）
• Spring 三级缓存与循环依赖（循环依赖解决机制）