1. 单例Bean的生命周期全景图
单例Bean作为Spring框架中最基础的组件形态，其创建过程远比表面看到的@Component注解复杂得多。以Spring 5.3.x版本为例，一个单例Bean从代码定义到完全可用，需要经历12个关键阶段。这个过程中既有Spring框架的标准化处理，也留给开发者充分的扩展点。
1.1 容器启动的触发条件
当调用AnnotationConfigApplicationContext的构造方法或refresh()时，容器初始化流程启动。这里有个容易忽略的细节：基于注解的配置和基于XML的配置在Bean定义读取阶段存在差异。注解驱动模式下，ConfigurationClassPostProcessor这个特殊的BeanDefinitionRegistryPostProcessor会扫描所有@Component注解的类。
关键提示：Spring Boot项目中常见的
@SpringBootApplication注解本质上是个复合注解，包含了@ComponentScan的能力。这就是为什么主类所在的package会成为默认扫描路径。
1.2 BeanDefinition的元数据封装
扫描到的每个Bean类会被转化为BeanDefinition对象。这个接口的实现类RootBeanDefinition保存了以下核心元数据：
- beanClass：目标类的Class对象
- scope：单例/原型等作用域标识
- lazyInit：是否延迟初始化
- dependsOn：显式依赖声明
- initMethodName/destroyMethodName：生命周期方法
这些元数据将指导后续的实例化过程。通过ConfigurableListableBeanFactory的getBeanDefinition()方法可以查看这些信息。
2. 实例化阶段的核心技术点
2.1 依赖解析的优先级规则
当容器准备创建Bean实例时，首先需要解决依赖关系。Spring遵循以下优先级：
- 构造器参数（@Autowired标注的构造器）
- 字段注入（@Autowired标注的字段）
- setter方法注入（@Autowired标注的方法）
特别需要注意的是循环依赖问题。虽然Spring通过三级缓存（singletonFactories、earlySingletonObjects、singletonObjects）解决了单例Bean的循环依赖，但构造器注入导致的循环依赖仍然无法处理。这是为什么官方推荐使用setter注入而非构造器注入的重要原因。
2.2 实例化的两种策略
Spring提供了两种实例化策略：
- CGLIB动态代理：用于需要代理的类（如@Configuration类）
- 反射直接实例化：普通Bean的默认方式
通过SimpleInstantiationStrategy的instantiate()方法可以看到，当类没有方法重写时，会直接调用BeanUtils.instantiateClass()通过反射创建实例。否则就需要通过CGLIB生成子类。
3. 初始化过程的扩展点
3.1 Aware接口回调机制
在属性注入完成后，Spring会按顺序调用以下Aware接口：
- BeanNameAware（设置bean名称）
- BeanClassLoaderAware（设置类加载器）
- BeanFactoryAware（设置BeanFactory引用）
- EnvironmentAware（设置环境变量）
- EmbeddedValueResolverAware（值解析器）
- ResourceLoaderAware（资源加载器）
- ApplicationEventPublisherAware（事件发布）
- MessageSourceAware（国际化）
- ApplicationContextAware（应用上下文）
这些接口为Bean提供了访问容器基础设施的能力。开发自定义starter时经常会用到这些扩展点。
3.2 初始化方法的执行顺序
所有初始化方法按固定顺序执行：
- @PostConstruct注解方法
- InitializingBean的afterPropertiesSet()
- init-method指定的自定义方法
这个顺序是硬编码在InitDestroyAnnotationBeanPostProcessor中的。实测发现即使通过@Order注解也无法改变这个顺序。
4. 生产环境中的实战经验
4.1 性能优化关键参数
在高压场景下，以下参数直接影响单例Bean的初始化性能：
spring.main.lazy-initialization：全局延迟初始化@Lazy：单个Bean的延迟加载@DependsOn：显式控制初始化顺序AbstractApplicationContext.setAllowCircularReferences：循环引用开关
某电商项目在启动8000多个单例Bean时，通过合理设置@Lazy使启动时间从47秒降至19秒。
4.2 常见异常排查表
| 异常现象 | 可能原因 | 解决方案 |
|---|---|---|
| BeanCurrentlyInCreationException | 构造器循环依赖 | 改为setter注入 |
| NoSuchBeanDefinitionException | 扫描路径错误 | 检查@ComponentScan |
| BeanInstantiationException | 缺少无参构造器 | 添加默认构造器 |
| UnsatisfiedDependencyException | 依赖Bean未定义 | 检查依赖关系 |
5. 高级应用场景
5.1 条件化Bean注册
通过组合@Conditional与Condition接口实现：
java复制@Bean
@Conditional(ProdEnvCondition.class)
public DataSource prodDataSource() {
// 生产环境专用配置
}
其中ProdEnvCondition需要实现matches()方法，根据环境变量决定是否注册Bean。Spring Boot的大量自动配置类都采用这种机制。
5.2 Bean定义动态注册
在运行时动态添加BeanDefinition：
java复制GenericBeanDefinition definition = new GenericBeanDefinition();
definition.setBeanClass(CustomService.class);
context.getBeanFactory().registerBeanDefinition("customService", definition);
这个技巧在实现插件化架构时非常有用。需要注意的是，动态注册的Bean不会触发配置类处理器的后置处理。
单例Bean的完整生命周期管理体现了Spring框架的设计精髓。理解这些底层机制，可以帮助我们更好地处理复杂场景下的Bean管理问题。在实际项目中，建议通过@Bean方法的调试断点逐步跟踪创建过程，这种实践认知比单纯阅读文档更深刻。