直接切入正题。Spring 的 IOC 容器是很多人学习框架源码的第一站但也是最容易劝退的一站。原因很简单refresh()方法里十几个子方法一环扣一环BeanFactory、ApplicationContext、BeanDefinition这些概念满天飞光是搞清楚先后顺序就够喝一壶的。这篇文章我不打算逐行贴源码注释而是沿着一次完整的容器启动过程把加载流程拆成一条可追踪的主线讲清楚每一步在做什么、为什么这么做、背后经历了哪些关键转折点。适合看过一点 Spring 源码但没串成体系的开发者也适合想从“会用”跨到“懂原理”的人。1. 容器启动的全景图先从上帝视角看一遍1.1 两个核心概念BeanFactory 和 ApplicationContext学习 IOC 加载流程之前必须先分清 Spring 里的两个顶层角色。BeanFactory是容器最底层的规范定义了getBean()、containsBean()等最基础的操作相当于一家公司的“基本法”。ApplicationContext在它之上又加上了事件发布、资源加载、国际化、环境抽象等能力相当于“基本法 全套行政制度”我们平时用的ClassPathXmlApplicationContext、AnnotationConfigApplicationContext都属于这一层。真正干活的默认实现是DefaultListableBeanFactory。它内部维护了一张核心注册表beanDefinitionMap这是一个ConcurrentHashMapString, BeanDefinitionkey 是 Bean 的名字value 是对该 Bean 的完整描述——类名、作用域、初始化方法、属性值、依赖关系全部塞在这里。可以这样说IOC 容器的加载过程本质上是回答两个问题——Bean 的“说明书”BeanDefinition是怎么进到这张 map 里的进了 map 之后又是怎么变成一个活的对象的注意getBean()只是触发创建的手段真正决定“能不能创建、怎么创建”的是BeanDefinition是否已经完整注册。很多人调试时发现getBean()报NoSuchBeanDefinitionException九成是第一步注册环节就没走到。1.2 加载流程的一页纸总结为了后面不迷路先用最粗的粒度把完整流程分四段阶段核心动作关键参与者配置读取定位并解析 XML/注解/配置类XmlBeanDefinitionReader、ConfigurationClassPostProcessor注册定义把解析结果封装成BeanDefinition放入注册表DefaultListableBeanFactory.registerBeanDefinition()容器刷新触发后处理器、事件、单例预创建AbstractApplicationContext.refresh()Bean 实例化按需或预创建单例完成属性填充与初始化AbstractAutowireCapableBeanFactory.createBean()后面所有篇幅都在给这张表填肉。先记住一个结论IOC 的加载流程可以概括为“读配置 → 转定义 → 刷容器 → 造对象”四步每一大步内部还能继续细化但主线绝对不会偏离这四步。2. BeanDefinition 的加载与注册容器先得攒齐“积木图纸”2.1 XML 时代的读取链路从new ClassPathXmlApplicationContext(applicationContext.xml)说起。构造函数最终会走到refresh()但在refresh()之前Spring 已经通过XmlBeanDefinitionReader把 XML 里的bean标签解析成了BeanDefinition。整个读取链路是ClassPathXmlApplicationContext持有XmlBeanDefinitionReader→ 调用loadBeanDefinitions(resource)→ 内部用DocumentLoader把 XML 文件转成 DOM 树 → 再交给DefaultBeanDefinitionDocumentReader遍历元素节点 → 最终由BeanDefinitionParserDelegate逐个解析bean的属性并封装成GenericBeanDefinition。一个值得注意的设计是Spring 虽然用了 DOM 解析但不是一次性把整个文件塞进内存无脑遍历而是通过BeanDefinitionDocumentReader这个 SPI 接口扩展了自定义标签的空间。比如context:component-scan这种标签实际是由ContextNamespaceHandler转发给对应的XmlBeanDefinitionReader处理逻辑最终会触发注解扫描器ClassPathBeanDefinitionScanner去扫包。也就是说XML 的解析本质是一个“命名空间分发器”不是单纯的数据读取。2.2 注解时代的扫描注册到了 Spring Boot / Spring 注解驱动的年代XML 不再是入口。AnnotationConfigApplicationContext在构造时会注册两个内置处理器ConfigurationClassPostProcessor处理Configuration、Bean、ComponentScan和AutowiredAnnotationBeanPostProcessor处理Autowired注入实际在后续实例化阶段生效。ComponentScan触发后ClassPathBeanDefinitionScanner会把指定包下的所有Component、Service、Repository、Controller标注类扫描出来逐个注册成ScannedGenericBeanDefinition。这地方有个细节扫描器默认只认Component及其派生注解但Service这些注解本身都标了Component所以能被正确识别靠的是元注解的传递关系。2.3 注册到容器后的“合并”操作BeanDefinition进 map 不是终点。Spring 在真正创建 Bean 之前会执行一次mergedBeanDefinition合并。什么意思在 XML 里可以用parent指定父子 Bean子 Bean 可以覆盖父 Bean 的属性也可以继承父 Bean 的init-method、scope等配置。BeanDefinition本身存储的是原始配置真正实例化用的是合并后的完整定义。这一步在AbstractBeanFactory.getMergedLocalBeanDefinition()里完成涉及缓存和递归逻辑平时不怎么被人提及但它是理解“Bean 配置继承”的关键。提示看beanDefinitionMap的内容时每个BeanDefinition能配置的属性非常多SCOPE_SINGLETON、LAZY_INIT、PRIMARY、DEPENDS_ON、AUTOWIRE_MODE、INIT_METHOD_NAME、DESTROY_METHOD_NAME等。排查问题先确认这些值是否符合预期比直接进createBean里找半天高效得多。3. 核心枢纽 refresh()容器初始化的总指挥3.1 为什么所有入口最终都汇聚到 refresh()不管是ClassPathXmlApplicationContext还是AnnotationConfigApplicationContext只要容器是“可刷新的”初始化时的AbstractApplicationContext.refresh()就是总入口。这个方法一共做了 12 件左右的事必须背下主干顺序才能理解 Spring 的设计哲学。refresh()的骨架如下关键步骤版Override public void refresh() throws BeansException, IllegalStateException { // 1. 准备刷新记录时间、设置容器关闭标志 prepareRefresh(); // 2. 获取 BeanFactory子类可覆写比如注册特殊 Bean ConfigurableListableBeanFactory beanFactory obtainFreshBeanFactory(); // 3. 给 BeanFactory 做准备工作类加载器、表达式解析器、注册环境 Bean prepareBeanFactory(beanFactory); // 4. 允许子类对 BeanFactory 做后处理比如注册 Web 相关 Scope postProcessBeanFactory(beanFactory); // 5. 执行 BeanFactoryPostProcessor重点解析 Configuration、Bean、扫描路径 invokeBeanFactoryPostProcessors(beanFactory); // 6. 注册 BeanPostProcessor重点处理 Autowired、Resource 的处理器 registerBeanPostProcessors(beanFactory); // 7. 初始化消息源国际化 initMessageSource(); // 8. 初始化事件广播器 initApplicationEventMulticaster(); // 9. 刷新子类扩展点比如 Web 容器的 onRefresh onRefresh(); // 10. 注册监听器 registerListeners(); // 11. 实例化所有非懒加载单例 Bean finishBeanFactoryInitialization(beanFactory); // 12. 完成刷新发布事件、清理缓存 finishRefresh(); }看到这段代码最大的启示是Bean 的真正创建被放在了几乎所有准备工作之后。第 5、6 步是在收集“扩展插件”第 7 到 10 步是搭建基础设施直到第 11 步才真正触发对象创建。3.2 第 5 步和第 6 步的深意后处理器的“前置埋伏”invokeBeanFactoryPostProcessors和registerBeanPostProcessors是容器加载过程中最容易忽略、又最能体现 Spring 设计精髓的两环。BeanFactoryPostProcessor的定位是“修改容器里的 BeanDefinition”比如ConfigurationClassPostProcessor就是通过它完成Bean方法解析和ComponentScan扫描的。换句话说容器这时还在“攒图纸”阶段后处理器可以往注册表里新增或修改图纸。BeanPostProcessor则完全不同。它的职责是“干预 Bean 的创建过程”。举例来说AutowiredAnnotationBeanPostProcessor会在 Bean 的属性填充阶段介入找到带Autowired的字段并完成注入。它的注册时间必须早于createBean否则后续实例化时根本没有“拦截器”可用。这里有个常见的困惑BeanPostProcessor对象本身也是 Bean它在注册时还没创建没错registerBeanPostProcessors里会先通过getBean()把实现了BeanPostProcessor接口的类实例化出来但普通 Bean 的创建不会在这一步触发。3.3 单例预创建之前的“最后检查”第 11 步finishBeanFactoryInitialization是加载流程的分水岭。前 10 步做完后容器已经把该准备的准备好了接下来的规则是只初始化非懒加载的singletonBeanprototype或lazy-init的 Bean 继续“按需创建”创建顺序由beanDefinitionMap的注册顺序和依赖关系共同决定。这一步会调用preInstantiateSingletons()遍历beanDefinitionNames列表逐一调用getBean(beanName)。看到没有真正创建 Bean 的动作被后置到了这个位置——Spring 把扩展机制前置把对象创建后置这一前一后的时序是框架扩展性的根基。4. 深入 getBean()Bean 实例化的完整生命线4.1 从单例缓存到 doCreateBeangetBean()的入口在AbstractBeanFactory.getBean()内部转调doGetBean()。其中第一件事是查单例缓存这直接关联到循环依赖处理后面专门讲。此处先看核心路径protected T T doGetBean(...) { // 1. 从单例缓存查询三级缓存之一 Object sharedInstance getSingleton(beanName); // 2. 没有缓存则走创建流程 if (sharedInstance null || !isPrototypeCurrentlyInCreation(beanName)) { // 父子容器处理、depends-on 解析 // 按 scope 分发创建策略 if (mbd.isSingleton()) { sharedInstance getSingleton(beanName, () - createBean(beanName, mbd, args)); } } }最终触发的createBean()在AbstractAutowireCapableBeanFactory里真正的实例化逻辑在doCreateBean()。这条链路是getBean()→doGetBean()→getSingleton(beanName, singletonFactory)→createBean()→doCreateBean()。4.2 实例化前、实例化、属性填充、初始化四阶段doCreateBean的内部节奏可以切成四段1) 实例化前。这里有个resolveBeforeInstantiation()扩展点给InstantiationAwareBeanPostProcessor一个机会返回代理对象。如果某 Bean 在这里被 AOP 提前代理了后续常规创建流程就不会走。这是Async、AOP 等注解生效的关键之一。2) 实例化。如果 Bean 有自定义Supplier或工厂方法则优先用工厂方式创建否则使用推断好的构造函数通过InstantiationStrategy反射创建实例。注意这里创建出来的还只是一个“空壳对象”没有属性值字段全是默认值。3) 属性填充。populateBean()把BeanDefinition里的propertyValues和Autowired依赖注入进去。这里会先收集InstantiationAwareBeanPostProcessor对属性值的后处理意见比如Autowired的解析结果就发生在该环节然后统一应用到实例上。4) 初始化。initializeBean()先激活Aware方法比如BeanNameAware获取 Bean 名再执行BeanPostProcessor.postProcessBeforeInitialization()接着按顺序触发PostConstruct、InitializingBean.afterPropertiesSet()、自定义init-method最后执行BeanPostProcessor.postProcessAfterInitialization()。这一步结束一个完整的 Bean 才真正可用。为了记清楚我常给团队画这样一条线空对象 - 属性填充 - Aware回调 - Before初始化 - PostConstruct - afterPropertiesSet - init-method - After初始化 - 放入单例缓存PostConstruct、InitializingBean、init-method三者的执行顺序常考常问答案就是上面这条线上从左到右一个都不能乱。4.3 SmartInitializingSingleton全量 Bean 创建完毕后的收尾动作finishBeanFactoryInitialization里还有一个隐藏的钩子SmartInitializingSingleton。它是在非懒加载单例全部创建完成之后统一回调afterSingletonsInstantiated()的处理器。和BeanPostProcessor的“每创建一个 Bean 回调一次”不同它是“全部创建完了只回调一次”。Spring 内部很多“容器级启动逻辑”比如EventListener监听器注册就依赖这个机制。很多业务开发者不知道这个扩展点做“等所有 Bean 都准备好后再执行某逻辑”的场景时只能靠PostConstruct但它只能在单个 Bean 初始化完时触发无法感知全局。SmartInitializingSingleton才是这类场景的标准解法。5. 循环依赖与三级缓存为什么必须设计成三级5.1 三级缓存的真相Spring 容器在DefaultSingletonBeanRegistry里维护了三层 map缓存级别存储内容生命周期一级缓存singletonObjects完整可用单例容器存活期二级缓存earlySingletonObjects提前暴露的半成品实例Bean 创建完成后会移到一级三级缓存singletonFactories对象工厂可生成提前暴露的引用Bean 创建完成后清空三级缓存的本质不是“解决循环依赖的唯一方案”而是应对“A 依赖 B、B 又依赖 A且 A 还需要被代理”的两难问题。当 A 创建时发现自己需要 BB 创建时又需要 A如果 A 不提前暴露一个引用B 就永远拿不到 A。三级缓存的意义在于A 实例化后立即把ObjectFactory丢进三级缓存B 需要 A 时取出工厂调用getEarlyBeanReference()拿到一个早期引用必要时生成代理从而完成注入。为什么不能只用二级缓存直接存半成品对象不行么关键在 AOP。如果 A 最终要被代理那么早期暴露给 B 的必须和最终放进容器的代理对象是同一个。但 Spring 通常是在postProcessAfterInitialization阶段才创建代理。没有三级缓存getEarlyBeanReference就没法在早期判断“这个 Bean 是否命中切点并提前生成代理”。所以三级缓存存的是“工厂”不是“实例”就是为了把这个决策点推迟到真正需要的时候。注意Lazy注入循环依赖其实是最省心的方案之一。Lazy会为依赖生成一个代理对象B 里的 A 起初只是一个“占位符”真正调用时才去容器拿。这绕过了三级缓存的整个机制用起来反而简单。5.2 构造器注入的循环依赖为什么没法治因为三级缓存解决的是“实例已经创建、只是属性未填充”的场景。构造器注入发生在实例化阶段A 还没创建出来B 需要 A 时容器连“半成品”都给不了。这就是为什么官方明确构造器循环依赖会直接报错。日常开发里最稳妥的做法是能用Autowired字段注入就用字段注入构造器注入只用于“明确无循环依赖”的核心依赖链。这不是说字段注入多高级而是从 Spring 现有机制的设计边界出发做的务实选择。5.3 代理 Bean 的循环依赖到底做了什么当 A 需要代理而循环依赖又存在时getEarlyBeanReference()会对 A 做早期代理判断。如果命中切点则提前生成代理对象放入二级缓存后续 B 拿到的引用就是这个代理实际创建完成后最终容器里存的也是这个代理。如果没命中切点二级缓存存的是原始对象引用。这里有个容易踩的坑如果你自定义了BeanPostProcessor且在其中注入了原始 Bean 的引用而该 Bean 实际被代理了那你持有的就是原始对象而不是代理对象调用方法时不会经过切面。排查这类问题时先识别目标 Bean 是否是代理对象再讨论引用传递。6. 加载流程与 Spring Boot 的衔接两条路线殊途同归6.1 SpringApplication.run() 和 refresh() 的关系很多人学完 Spring 的refresh()后去翻 Spring Boot 源码会有点对不上启动入口明明是SpringApplication.run()怎么没直接看到refresh()因为 Boot 在启动过程中先做了一堆环境准备推断应用类型、加载外部配置、准备 Environment、打印 Banner最后才通过SpringApplication.run()内部的refreshContext()触达SpringApplication创建的AnnotationConfigApplicationContext的refresh()。从容器加载本身的视角看Boot 依然逃不出我们前面描述的BeanDefinition注册和单例创建流程。Boot 对加载流程最大的贡献是“自动配置”。SpringBootApplication里的EnableAutoConfiguration会导入AutoConfigurationImportSelector它读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里面的自动配置类然后注册成BeanDefinition。这个注册行为发生在ConfigurationClassPostProcessor处理配置类的阶段所以自动配置的本质也是容器加载过程中的“图纸增强”。6.2 条件注解为什么能拦截注册ConditionalOnClass、ConditionalOnProperty这类条件注解是在配置类被解析时通过ConditionEvaluator判断是否跳过注册的。也就是说条件失效的类根本不会进入beanDefinitionMap。排查“为什么某个自动配置没生效”时别盯着运行时代码先在启动过程里确认条件匹配的结果常见工具是启用debugtrue查看自动配置报告可以看到正负匹配清单直接定位被拒绝的原因。这里的经验是把 Boot 的启动过程映射到 Spring 的refresh()流程中问题会立刻简单化。遇到“配置没加载”先分清是环境变量读取阶段的问题还是BeanDefinition注册阶段的问题还是 Bean 实例化阶段的初始化异常。三类问题的排查路径完全不同。7. 常见问题与源码级排查技巧实录7.1 问题速查表现象根源排查重点NoSuchBeanDefinitionExceptionBeanDefinition 未注册或注册名不准beanDefinitionMap里查 name注意是首字母小写还是全限定名BeanCurrentlyInCreationException构造器循环依赖看堆栈创建链改造为字段注入或用Lazy属性为 null属性填充被跳过或注入点未被识别确认Autowired所在类是否被扫描、AutowireCandidateResolver是否排除初始化方法执行两次PostConstruct和init-method同时声明或代理增强重复检查BeanDefinition的initMethodName和注解是否重复配置属性注入的是代理对象而非原始对象AOP 代理导致断点检查 bean 类型和getEarlyBeanReference参与情况7.2 源码阅读的三个高效路径读源码最怕“抓不住主线”。我的经验是三个路径并行路径一断点跟踪实例生命线。在doCreateBean的createBeanInstance、populateBean、initializeBean三个方法入口打条件断点过滤指定 Bean 名观察参数变化。这是最快建立起“Bean 生命周期”感知的方式。路径二利用beanDefinitionNames列表看注册顺序。在preInstantiateSingletons()里断点能看到容器最终会按什么顺序创建单例这对理解依赖顺序、depends-on行为非常有帮助。路径三用Configuration类做最小复现实验。想要理解某个后处理器的作用创建一个只有该处理器的最小配置打印日志看影响范围。切忌直接拿生产大型工程当实验场一个大项目动辄上千 Bean断点信息噪声大到根本看不下去。7.3 一个典型的排查过程我最近遇到过一个现场升级 Spring Boot 版本后某个 Bean 的Value注入一直是 null代码没改过。第一反应是查配置项结果配置文件没问题。后来在populateBean断点发现propertyValues里根本没有该项说明Value的解析压根没参与。继续追查在BeanPostProcessor注册环节发现AutowiredAnnotationBeanPostProcessor存在但它默认不处理Value。真正处理Value的是AutowiredAnnotationBeanPostProcessor内的AutowiredFieldElement.inject()逻辑它只认Autowired和Value两个注解。它存在但 null 的原因锁定到候选解析——AutowireCandidateResolver默认是QualifierAnnotationAutowireCandidateResolver在判断当前 Bean 是否能注入该字段值时因为泛型不匹配将其排除了。最后换了注入类型解决。整个过程核心就是沿着BeanDefinition — 后处理器 — populateBean — 候选解析一条线走下来定位效率比瞎猜高得多。7.4 推荐的学习顺序如果刚接触源码建议的顺序是先手写一个极简 XML 工程用断点走一遍refresh()的前 6 步和getBean()的全流程不追求全懂只要求“见过”再通过Bean和Component各注册一个 Bean 对比BeanDefinition的属性差异接着阅读DefaultSingletonBeanRegistry的三级缓存代码最后再看 Boot 的自动配置。这个顺序把底层容器机制放在最前面后面看 Boot 时基本是顺水推舟。补充一点我踩过的坑看源码时别只在 IDE 里翻静态代码一定要配合运行时断点和BeanFactory的实际内容观察。源码里的分支逻辑太多光靠脑补很容易被分析带偏只有运行时数据才能说明代码到底走了哪条分支。回到最初那句话IOC 加载流程本质上不复杂复杂的是它在每一个环节都预留了扩展点这些扩展点相互组合后形成了庞大的网状结构。但只要抓住BeanDefinition 注册 → 容器刷新 → 单例预创建这三段主线再掌握BeanPostProcessor和BeanFactoryPostProcessor这两个“拦截时机”绝大多数源码问题都能在一个小时内定位到具体代码行。最后分享一个我自己的阅读习惯每次深入一个 Spring 机制之前先在纸上写出“谁调用谁、什么时候调用、在哪注册的”把时序图画出来再动手学习效率和事后复盘的收获都会明显不同。