容器与 Bean

1.1IoC 容器 = ApplicationContext

容器是管理对象创建与装配的运行时。

容器并不神秘。剥开注解语法糖，内部结构是三件东西：

• 单例池——Map<String, Object> singletonObjects，存放已实例化的单例 Bean；
• BeanDefinition 元数据——描述"怎么造这个 Bean"的蓝图集合；
• 后置处理器列表——两类处理器（BeanFactoryPostProcessor 和 BeanPostProcessor）的有序队列，负责在蓝图阶段和实例阶段介入。

BeanFactory 是最基础的 DI 接口，只提供 getBean() 和注册/查询 BeanDefinition。ApplicationContext 继承 BeanFactory，并在其上叠加了五项能力：AOP 代理集成、应用事件发布/监听、i18n 消息资源、自动组件扫描、以及 Environment 抽象（统一管理 profiles 和属性源）。

下面的示意代码展示注解只是配置容器的语法糖——AnnotationConfigApplicationContext 可以在不扫描任何包的情况下手动注册 BeanDefinition：

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
class AppConfig {
    @Bean  // 注解只是让容器知道"有这个蓝图"，Bean 本身仍由容器实例化
    public OrderService orderService() {
        return new OrderService();
    }
}

public class ContainerDemo {
    public static void main(String[] args) {
        // 手动建容器，无需 Spring Boot — 验证容器本质
        var ctx = new AnnotationConfigApplicationContext(AppConfig.class);

        // getBean() 触发：若单例池已有则直接返回，否则按蓝图实例化后放入单例池
        OrderService svc = ctx.getBean(OrderService.class);
        System.out.println(svc == ctx.getBean(OrderService.class)); // true — 同一对象

        ctx.close();
    }
}

1.2BeanDefinition（蓝图）vs Bean（实例）

BeanDefinition 是"怎么造这个 Bean"的元数据，不是 Bean 本身。

一个 BeanDefinition 持有的信息包括：目标 class、scope（singleton/prototype…）、构造参数、属性值、是否懒加载（lazyInit）、初始化方法名（initMethodName）、销毁方法名（destroyMethodName）。容器在 refresh 的前半段把所有 BeanDefinition 收齐，蓝图先于实例存在——这是 BeanFactoryPostProcessor 能够介入的前提：此时还没有任何 Bean 实例，BFPP 可以自由读写蓝图中的任何字段。

1.3两类后置处理器（本教程第一刀）

区分 BeanFactoryPostProcessor（BFPP）和 BeanPostProcessor（BPP）是理解 Spring 机制的第一刀。两者作用在不同的对象、不同的时机：

ConfigurationClassPostProcessor 是最关键的 BFPP：它解析 @Configuration 类及其 @Bean、@Import、@ComponentScan，把应用中所有 BeanDefinition（包括自动配置产生的）全部加载进容器。自动配置的发现机制（AutoConfigurationImportSelector 读 .imports 文件）在这一步触发，详见 第 3 章。

1.4Bean 生命周期 + 三级缓存与循环依赖

单例 Bean 的完整生命周期按以下顺序推进：

1. 实例化——调用构造函数，对象分配内存（此时属性尚未注入）；
2. 属性注入——AutowiredAnnotationBeanPostProcessor 填充 @Autowired 依赖；
3. Aware 回调——BeanNameAware、BeanFactoryAware、ApplicationContextAware 等；
4. BPP before——postProcessBeforeInitialization()；
5. 初始化——@PostConstruct（JSR-250，jakarta 包）→ InitializingBean.afterPropertiesSet() → initMethod；
6. BPP after——postProcessAfterInitialization()（代理在此替换原对象）；
7. 就绪——放入单例池，供 getBean() 返回；
8. 销毁——容器关闭时：@PreDestroy → DisposableBean.destroy() → destroyMethod。

三级缓存与循环依赖

Spring 用三级缓存让 field/setter 注入的循环依赖能够成立：

• singletonObjects——成品 Bean（完全初始化）；
• earlySingletonObjects——早期引用（已实例化但尚未注入完毕）；
• singletonFactories——工厂对象，按需产出早期引用（用于 AOP 场景，把半成品的代理暴露出去）。

循环依赖成立的过程：A 开始实例化 → 把 A 的工厂放入 singletonFactories → 注入 B → B 开始实例化 → 注入 A 时命中 singletonFactories，取出 A 的早期引用放入 earlySingletonObjects → B 完成初始化 → A 拿到 B 完成注入 → A 完成初始化 → A 进入 singletonObjects。整个过程不需要 A 已经完全就绪，只需要 A 的早期引用（内存地址）已固定。

构造器注入的环解不了：造 A 的构造函数需要 B 已存在，造 B 的构造函数需要 A 已存在——此时 A 连实例都还没有，无早期引用可暴露，Spring 直接抛出 BeanCurrentlyInCreationException。

Spring Boot 2.6+ 默认 spring.main.allow-circular-references=false，在启动时主动检测并拒绝所有循环依赖（包括 field/setter 注入的环），把隐式依赖变成显式构建错误。

初始化回调（@PostConstruct）来自 Jakarta EE，Spring Boot 4.0 / Jakarta EE 11 下使用 jakarta.annotation.PostConstruct，不再是旧的 javax.annotation.PostConstruct。

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.springframework.beans.factory.BeanNameAware;
import org.springframework.stereotype.Service;

@Service
public class CacheWarmupService implements BeanNameAware {

    private String beanName;

    // ③ Aware 回调 — 容器注入 Bean 名称
    @Override
    public void setBeanName(String name) {
        this.beanName = name;
    }

    // ⑤ 初始化回调 — 此时依赖已注入完毕
    @PostConstruct
    public void warmup() {
        // 容器保证：走到这里时所有 @Autowired 字段已就绪
        System.out.println(beanName + " warmup done");
    }

    // ⑧ 销毁回调 — 容器关闭时触发
    @PreDestroy
    public void cleanup() {
        System.out.println(beanName + " cleanup");
    }
}