Spring为什么启动时要实例化几乎所有的Bean?

Spring 启动时为什么要把几乎所有的 Bean 都提前实例化？

Spring Boot（以及经典的 Spring 容器）在启动阶段默认会把绝大多数单例 Bean 都提前创建出来（即所谓的“eager initialization”），这其实是 Spring 设计上一个非常核心且有深远影响的决定。主要原因可以归纳为以下几点：

排名	原因	根本目的	对启动时间的影响	是否可以关闭/延迟
1	尽早发现配置错误	把配置错误、依赖缺失、Bean 创建异常提前暴露	启动变慢	可以部分关闭
2	保证单例的线程安全性	单例 Bean 在多线程环境下必须先创建好	启动变慢	基本不可关闭
3	支持循环依赖的默认解决方式	Spring 默认靠三级缓存解决循环依赖，需要提前创建对象	启动变慢	关闭循环依赖可缓解
4	AOP、事务等代理的提前织入	@Transactional、@Async、@Cacheable 等切面需要在 Bean 创建时就完成代理	启动变慢	部分可延迟
5	历史包袱与约定优于配置	Spring 从 2003 年开始就是这么设计的，生态全部依赖这个行为	启动变慢	很难彻底改变
6	运行时性能更可预测	启动时把痛苦都承受完，运行期几乎没有首次访问的抖动	运行期更快	—

尽早暴露问题（Fail Fast 原则）
Spring 认为：宁可启动失败，也不要上线后才发现某个 Bean 根本创建不出来。
常见的启动时异常：

循环依赖的默认处理机制
Spring 默认允许单例 Bean 之间的循环依赖，靠的是三级缓存 + 提前暴露对象引用的机制。
这个机制要求：在 Bean 实例化（new）之后、属性填充（populate）之前，就要把半成品对象提前放入缓存。
这就导致：几乎所有单例 Bean 都会在启动阶段被实例化（至少 new 出来），即使后续属性填充失败了。
AOP 代理必须在启动时完成
大部分 AOP 切面（事务、异步、缓存、权限等）都是通过BeanPostProcessor在 Bean 初始化阶段完成的。
如果推迟到第一次调用才代理，就会出现：

单例的线程安全语义
Spring 保证单例 Bean 是线程安全可共享的。
如果启动时不创建，等到并发请求进来时再创建，会出现竞争条件，可能导致多次实例化或空指针。

虽然“几乎全初始化”是 Spring 的设计基石，但现代项目已经有很多成熟的优化手段：

优化手段	启动时间收益	难度	是否推荐生产环境	注意事项
lazy-init=”true” / @Lazy	非常大	★☆☆	推荐	首次访问会有延迟抖动
@Lazy + 按需注入	大	★★☆	强烈推荐	结合 @Lookup 或 ObjectProvider
Spring Boot 3.x 延迟初始化	大	★☆☆	强烈推荐	spring.main.lazy-initialization=true
GraalVM Native Image	极大（启动<1s）	★★★★	强烈推荐（云原生）	需要适配，很多第三方库不支持
Profile 分组 + @Conditional	中等	★★☆	推荐	dev/test/prod 环境差异化
关闭循环依赖检测	中等	★★☆	谨慎	spring.main.allow-circular-references=false
精简组件扫描	小～中	★★☆	推荐	缩小 @ComponentScan 范围

Spring 启动时实例化几乎所有单例 Bean 的根本原因是为了“Fail Fast + 线程安全 + 循环依赖默认支持 + AOP 提前织入”这四个核心设计目标。

牺牲了启动速度，换来了运行期的稳定性和可预测性，以及尽早发现问题的能力。

这也是为什么 Spring Boot 3.x 之后大力推广 lazy-initialization 和 GraalVM Native，试图在保留这些优点的前提下，把启动时间也做到极致。

如果你当前项目启动时间很长，欢迎告诉我大概的规模和场景（微服务数量、Bean 数量、是否大量 AOP），我可以给你更针对性的优化建议～

归档