Spring Framework 系列 #01：Spring 容器启动流程源码分析

Spring Framework 的核心是 AbstractApplicationContext#refresh()，这是 IOC 容器启动的主干。本文以 refresh 的 12 步为骨架，重点剖析每步做什么、为什么这样排序、有哪些扩展点。SpringBoot 的 refreshContext 最终也委托到这里。

缩写速查：Spring 术语与缩写速查 · 相关笔记：Spring 三级缓存与循环依赖 · SpringBoot 启动流程源码分析

目录

整体架构

ApplicationContext 继承体系

ApplicationContext
  └── ConfigurableApplicationContext          ← 定义 refresh() 接口
        └── AbstractApplicationContext        ← refresh() 的唯一实现
              ├── AnnotationConfigApplicationContext          （NONE）
              └── AbstractRefreshableApplicationContext
                    └── AbstractRefreshableConfigApplicationContext
                          └── ClassPathXmlApplicationContext  （XML 方式）

SpringBoot 扩展：
AbstractApplicationContext
  └── GenericApplicationContext
        └── AnnotationConfigApplicationContext
              └── AnnotationConfigServletWebServerApplicationContext  （Web）

refresh() 12 步全貌

public void refresh() throws BeansException, IllegalStateException {
    synchronized (this.startupShutdownMonitor) {
        // ── 阶段一：容器准备 ──────────────────────────────────
        prepareRefresh();                           // 1. 上下文状态、属性源初始化
        ConfigurableListableBeanFactory beanFactory
            = obtainFreshBeanFactory();             // 2. 获取/刷新 BeanFactory

        // ── 阶段二：BeanFactory 后处理 ────────────────────────
        prepareBeanFactory(beanFactory);            // 3. 配置 BeanFactory 基础设施
        postProcessBeanFactory(beanFactory);        // 4. 🔌 子类扩展点（注册 Web 相关）
        invokeBeanFactoryPostProcessors(beanFactory); // 5. 🔌 执行 BFPP（解析 @Configuration）

        // ── 阶段三：Bean 注册与实例化 ─────────────────────────
        registerBeanPostProcessors(beanFactory);    // 6. 🔌 注册 BPP（AOP/事务代理）
        initMessageSource();                        // 7. 国际化
        initApplicationEventMulticaster();          // 8. 事件广播器
        onRefresh();                                // 9. 🔌 子类扩展（SpringBoot：Tomcat 启动）
        registerListeners();                        // 10. 注册 ApplicationListener
        finishBeanFactoryInitialization(beanFactory); // 11. 实例化所有非懒加载 Bean

        // ── 阶段四：容器就绪 ──────────────────────────────────
        finishRefresh();                            // 12. 发布 ContextRefreshedEvent，启动 Lifecycle
    }
}

为什么这个顺序？ 核心约束：BPP（BeanPostProcessor）必须在普通 Bean 之前实例化，否则它无法拦截普通 Bean 的创建。BFPP 必须在 BPP 之前执行，因为它负责解析 BeanDefinition（BPP 本身就是一种 BeanDefinition）。

阶段一：容器准备

1. prepareRefresh()

protected void prepareRefresh() {
    this.startupDate = System.currentTimeMillis();
    this.closed.set(false);
    this.active.set(true);

    // 🔌 子类可覆写：注册 PropertySource（SpringBoot 在这里注册 servlet 相关属性源）
    initPropertySources();

    // 校验必须存在的属性（通过 setRequiredProperties 指定）
    getEnvironment().validateRequiredProperties();

    // 保存早期事件，等事件广播器就绪后再统一发布
    this.earlyApplicationEvents = new LinkedHashSet<>();
}

关键：earlyApplicationEvents 的存在是为了解决"事件广播器在步骤 8 才初始化，但步骤 1~7 可能需要发布事件"的问题。

2. obtainFreshBeanFactory()

• XML 方式（AbstractRefreshableApplicationContext）：每次 refresh 销毁旧 BeanFactory，重新解析 XML，创建新的 DefaultListableBeanFactory，加载所有 BeanDefinition
• 注解方式（GenericApplicationContext）：BeanFactory 在构造时已创建，此步骤直接返回，BeanDefinition 由后续 BFPP 解析

阶段二：BeanFactory 后处理

3. prepareBeanFactory()

为 BeanFactory 注册基础设施 Bean，使框架能力生效：

4. postProcessBeanFactory() 🔌

空实现，子类覆写。SpringBoot Web 在这里注册：

• WebApplicationContextServletContextAwareProcessor（感知 ServletContext）
• request / session / application scope

5. invokeBeanFactoryPostProcessors() 🔌

这是整个 refresh 中最复杂的一步，自动装配在这里完成。

执行两类接口（有严格优先级顺序）：

BeanDefinitionRegistryPostProcessor（先执行，可新增 BeanDefinition）
  └── ConfigurationClassPostProcessor（优先级最高）
        ├── 解析 @Configuration / @Component / @Bean
        ├── 处理 @Import / @ImportResource
        └── 处理 @EnableAutoConfiguration → 加载 spring.factories 中的 AutoConfiguration

BeanFactoryPostProcessor（后执行，只能修改已有 BeanDefinition）
  └── PropertySourcesPlaceholderConfigurer（解析 @Value 中的 ${...}）

执行顺序（保证 BDRPP 在 BFP 之前，内部按 PriorityOrdered > Ordered > 无序）：

① PriorityOrdered 的 BDRPP（含 ConfigurationClassPostProcessor）
② Ordered 的 BDRPP
③ 无序的 BDRPP
④ PriorityOrdered 的 BFP
⑤ Ordered 的 BFP
⑥ 无序的 BFP

扩展点：实现 BeanDefinitionRegistryPostProcessor 可在运行时动态注册 BeanDefinition（MyBatis 的 MapperScannerConfigurer 就是这样扫描 Mapper 接口的）。

阶段三：Bean 注册与实例化

6. registerBeanPostProcessors() 🔌

只注册，不执行——将所有 BeanPostProcessor Bean 实例化并有序注册到 BeanFactory。

注册顺序（与 BFPP 相同）：PriorityOrdered → Ordered → 无序 → MergedBeanDefinitionPostProcessor（内部用）

7-8. MessageSource + ApplicationEventMulticaster

// 7. 国际化：查找名为 "messageSource" 的 Bean，没有则用空实现
initMessageSource();

// 8. 事件广播器：查找名为 "applicationEventMulticaster" 的 Bean，没有则用 SimpleApplicationEventMulticaster
initApplicationEventMulticaster();
// 此步骤完成后，earlyApplicationEvents 中积压的早期事件被统一发布

自定义异步事件广播：注册名为 applicationEventMulticaster 的 Bean，设置 TaskExecutor，即可让所有事件异步分发。

9. onRefresh() 🔌

子类扩展点，空实现。SpringBoot 最重要的覆写：

// ServletWebServerApplicationContext#onRefresh()
@Override
protected void onRefresh() {
    super.onRefresh();
    createWebServer();  // 创建并启动内嵌 Tomcat/Jetty/Undertow/Netty
}

为什么 Tomcat 在 Bean 实例化之前启动？ 实际上不是——onRefresh（步骤 9）在 finishBeanFactoryInitialization（步骤 11）之前，但 Tomcat 此时只是"创建并初始化"，并不开放端口接受请求。端口开放在步骤 12 的 finishRefresh 里。

10. registerListeners()

将已注册的 ApplicationListener Bean 绑定到广播器，同时发布所有积压的 earlyApplicationEvents。

11. finishBeanFactoryInitialization()

实例化所有非懒加载的 singleton Bean，这是启动最耗时的步骤。

Bean 创建的核心流程：

getBean(beanName)
  └── doCreateBean()
        ├── createBeanInstance()          实例化（反射调用构造器）
        ├── populateBean()                依赖注入（@Autowired / @Value）
        │     └── AutowiredAnnotationBeanPostProcessor
        └── initializeBean()
              ├── invokeAwareMethods()    回调 *Aware 接口
              ├── BPP#beforeInitialization  （含 @PostConstruct）
              ├── afterPropertiesSet()    InitializingBean 接口
              ├── init-method             XML 配置的 init-method
              └── BPP#afterInitialization （AOP 代理在此生成）

三级缓存解决循环依赖：

局限：三级缓存只解决 setter/field 注入的循环依赖。构造器注入的循环依赖无法解决（@Lazy 可绕过）。

阶段四：容器就绪

12. finishRefresh()

protected void finishRefresh() {
    clearResourceCaches();

    // 初始化 LifecycleProcessor（查找名为 "lifecycleProcessor" 的 Bean，否则用默认）
    initLifecycleProcessor();

    // 启动所有 Lifecycle Bean（SmartLifecycle#start()）
    // SpringBoot Web：Tomcat 在这里真正开放端口
    getLifecycleProcessor().onRefresh();

    // 发布 ContextRefreshedEvent
    publishEvent(new ContextRefreshedEvent(this));
}

Lifecycle 执行顺序：SmartLifecycle 按 getPhase() 从小到大启动（从大到小停止）。Tomcat 的 phase 是 Integer.MAX_VALUE，保证最后启动、最先停止。

扩展点汇总

Spring 定义扩展点接口，SpringBoot 通过 spring.factories 注册实现类，在对应步骤自动触发。第四列标注了 SpringBoot 的具体实现，数据来自 spring-boot-2.4.4.jar。

SpringBoot 新增的扩展点（Spring 原生没有）

SpringBoot 在 Spring 之上额外定义了 4 个扩展点，弥补了 Spring 覆盖不到的场景：

自动装配接入路径（扩展点串联）

① 构造阶段
   spring.factories → ApplicationContextInitializer
   └─ SharedMetadataReaderFactoryContextInitializer 注册

② prepareEnvironment
   spring.factories → EnvironmentPostProcessor（SpringBoot 扩展点）
   └─ ConfigDataEnvironmentPostProcessor → 加载 application.yml

③ prepareContext → load(启动类)
   └─ 注册 @SpringBootApplication 启动类为 BeanDefinition

④ refresh 步骤③ applyInitializers
   └─ SharedMetadataReaderFactoryContextInitializer 回调
      → 注册共享 MetadataReader 的 BDRPP

⑤ refresh 步骤⑤ invokeBeanFactoryPostProcessors（Spring 扩展点）
   └─ ConfigurationClassPostProcessor
      → 解析 @EnableAutoConfiguration
      → AutoConfigurationImportSelector
      → spring.factories EnableAutoConfiguration 列表
      → @Conditional 过滤
      → 注册满足条件的 AutoConfiguration BeanDefinition

常见问题

Q1：为什么 BeanPostProcessor 不能依赖普通 Bean？

BPP 在步骤 6 实例化，普通 Bean 在步骤 11 实例化。如果 BPP 依赖普通 Bean，Spring 会提前实例化那个普通 Bean，但此时其他 BPP 还没注册，导致该普通 Bean 跳过了 AOP 代理等处理。Spring 会打印警告：Bean 'xxx' is not eligible for getting processed by all BeanPostProcessors。

解决：BPP 尽量只依赖其他 BPP 或基础设施 Bean，不依赖业务 Bean。

Q2：@EventListener 和 ApplicationListener 的区别？

如果需要监听 ContextRefreshedEvent，必须用 ApplicationListener，不能用 @EventListener。

Q3：构造器注入的循环依赖怎么解？

三级缓存不覆盖构造器注入。解决方案：

1. @Lazy 注解延迟其中一个的注入
2. 重新审视设计，循环依赖通常意味着职责划分有问题
3. 提取公共依赖到第三个 Bean

Q4：@PostConstruct 和 afterPropertiesSet 哪个先执行？

@PostConstruct 先执行（由 CommonAnnotationBeanPostProcessor#postProcessBeforeInitialization 触发），afterPropertiesSet 后执行（在 initializeBean 中直接调用）。

Spring 与 SpringBoot 的设计边界

理解这个边界，是理解"SpringBoot 为什么要重新实现配置文件加载"的关键。

Spring 的设计哲学：提供机制，不强加策略

Spring Framework 官方文档的原话：

Spring makes it possible to build applications from "plain old Java objects" (POJOs) and to apply enterprise services non-invasively to POJOs.

non-invasive（非侵入性） 是 Spring 的核心设计词。它的含义是：Spring 提供能力，但不规定你该怎么用、配置文件叫什么名字、放在哪里。不同场景（Web 服务、桌面应用、嵌入式系统、批处理）的约定完全不同，Spring 不想为某一类场景做硬编码决策。

因此 Spring 原生的配置文件加载只提供了机制：

// Spring 原生：必须显式声明，没有约定
@PropertySource("classpath:application.properties")
@PropertySource("classpath:database.properties")
public class AppConfig { }

Environment 默认只有 systemProperties 和 systemEnvironment 两个属性源，其他全靠显式注册。

SpringBoot 的设计哲学：固执己见的默认值

SpringBoot 官方文档的原话：

Spring Boot takes an opinionated view of building production-ready Spring applications.

opinionated（固执己见） 是 SpringBoot 主动选择的定位。它针对 "生产级 Web 服务"这一具体场景，替你做好了所有决策：

这就是为什么 SpringBoot 要重新实现配置文件加载——不是 Spring 没有这个能力，而是 Spring 故意不做这层约定，SpringBoot 专门为 Web 场景补上了这一层。

两者的边界

Spring Framework
  └── 提供机制：PropertySource、Environment、ApplicationContextInitializer、
               BeanPostProcessor、ApplicationListener……
      （只问"怎么做"，不问"做什么"）

SpringBoot
  └── 定义策略：application.yml 自动发现、profile 切换、
               AutoConfiguration 条件装配、内嵌 Tomcat……
      （基于 Spring 的机制，回答"该做什么"）

说明：上述"机制与策略分离"的表述是对两者关系的归纳，非官方术语。官方原词是 Spring 的 "non-invasive" 和 SpringBoot 的 "opinionated"，两者合在一起能准确传达这层含义。

参考资料

• Spring Framework 源码 — AbstractApplicationContext
• Spring Framework 官方文档 — Container Overview
• 《Spring 揭秘》（王福强著）