容器是怎么管理 Bean 的？

文章目录1. 核心蓝图BeanDefinition2. 核心管理流程生命周期流水线第一阶段准备与实例化第二阶段装配与填充第三阶段初始化Initialization第四阶段生存与销毁3. 核心机制三级缓存解决循环依赖4. BeanFactory vs ApplicationContext总结Spring 容器对 Bean 的管理不仅仅是“创建对象”那么简单它实际上是一套极其严密的生命周期流水线。容器通过BeanFactory生产工厂和BeanDefinition施工蓝图这两个核心组件完成了从读取配置到销毁对象的所有工作。1. 核心蓝图BeanDefinition在容器真正 new 一个对象之前它首先要把你的配置XML、注解、Starter转化成一个统一的内部结构BeanDefinition。这个蓝图记录了Bean 的全类名Class Name。作用域Scope单例还是多例。是否懒加载Lazy-init。依赖关系它需要注入哪些别的 Bean。初始化和销毁方法名。2. 核心管理流程生命周期流水线你可以把容器想象成一个自动化工厂每一个 Bean 都要走完以下流程第一阶段准备与实例化加载配置容器启动读取扫描路径下的所有类。注册 BeanDefinition将信息存入BeanDefinitionMap。实例化Instantiation通过反射机制调用构造函数创建一个“原生对象”。此时它只是个空的 Java 对象还没注入数据。第二阶段装配与填充属性赋值Populate容器根据蓝图把对应的配置参数和依赖的其他 Bean 注入进去比如Value、Autowired。Aware 回调如果 Bean 实现了BeanNameAware或ApplicationContextAware容器会把 Bean 的名字或容器引用塞给它。第三阶段初始化InitializationBeanPostProcessor 前置处理执行所有拦截器的postProcessBeforeInitialization方法。初始化方法先后执行PostConstruct、InitializingBean接口方法、以及自定义的init-method。BeanPostProcessor 后置处理执行postProcessAfterInitialization。注意AOP动态代理通常就在这一步发生。第四阶段生存与销毁就绪Bean 进入单例池Singleton Objects Map等待被业务代码调用。销毁Destruction当容器关闭时执行销毁逻辑PreDestroy等。3. 核心机制三级缓存解决循环依赖管理中最难的部分是如果 A 依赖 BB 也依赖 A 怎么办容器通过三级缓存本质是三个 Map来解决这个问题一级缓存singletonObjects存放完全初始化好的、可以直接用的“成品”Bean。二级缓存earlySingletonObjects存放已经实例化、但还没填充属性的“半成品”Bean。三级缓存singletonFactories存放创建 Bean 的工厂对象用来处理 AOP 情况下的循环依赖。逻辑A 创建时发现依赖 B先把自己这个“半成品”挂在缓存里跑去创建 BB 发现依赖 A直接从缓存里拿走 A 的“半成品”完成创建再回头把完整的 B 给 A。4. BeanFactory vs ApplicationContext容器的管理能力也分等级特性BeanFactoryApplicationContext定位底层接口提供基本容器功能。高级容器继承了前者。加载时机懒加载。只有获取 Bean 时才创建。预加载。容器启动时就创建所有单例。扩展功能无。支持 AOP、国际化、事件广播、资源访问。应用场景移动端或资源极度受限环境现已少用。几乎所有 Spring/Spring Boot 应用。总结容器管理 Bean 的本质是利用BeanDefinition统一标准利用“反射 缓存”实现自动化组装利用“生命周期接口”提供可扩展性。你现在已经看过了 Bean 的创建、销毁、以及容器的管理逻辑。你是否好奇过为什么 Spring 默认要把 Bean 设计成单例Singleton这种设计在处理高并发请求时会有什么潜在的“坑”