面经策

Spring 中的 BeanFactory 是什么？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

BeanFactory 是 Spring 最底层的容器接口，定义了 getBean 这样的基本能力，负责 Bean 的注册与获取，是整个 IOC 体系的地基。它是最简版本：默认懒加载，你 getBean 时才真正创建对象，资源占用极小。

业务架构视角，我对 BeanFactory 的定位理解是"分层供给"：

  • BeanFactory 管基本生存：能创建、能注入，仅此而已；
  • ApplicationContext 在其上叠加企业能力：国际化、事件发布、环境 Profile、注解驱动，并且启动时默认预实例化所有单例——宁可启动慢一点，也要把配置错误在上线前暴露出来。

这个分层对我的启发是：基础能力和业务增值能力分层供给，按需选择。写一个嵌入式工具、Agent 脚本，用 BeanFactory 级别的轻量容器就够了；做业务系统，一定用 ApplicationContext，因为事件机制、国际化、声明式事务这些"企业特性"背后都是真实的业务需求。

实际项目里几乎不会直接 new BeanFactory，但理解它有两个实际价值：一是排查启动问题时分得清哪层在报错；二是阅读 Spring Boot 源码（自动配置、条件装配都构建在这套接口体系上）时不会迷路。面试时点出"分层与按需"，比背接口方法更能体现架构思维。

🏗 系统架构师 ​

BeanFactory 是容器最底层的接口，定义 getBean、作用域、别名等最小能力集，默认懒加载。ApplicationContext 是它的超集，叠加了事件、国际化、资源加载、环境抽象（Profile 与属性源）和自动的 BeanPostProcessor 注册。

我关注它两个架构特性：

  • 分层：底层只做「Bean 工厂」，上层做「应用上下文」。最小内核加增量增强的分层，是 Spring 能在 Servlet、Reactive、批处理、Native Image 等不同运行形态里复用同一套内核的原因；
  • 父子容器：HierarchicalBeanFactory 支持容器嵌套，子可见父、父不可见子。历史上 Spring MVC 的 Root/Servlet 双容器基于此；在平台类产品（规则引擎、SaaS 插件体系）里，我用父子容器做「平台内核与租户插件」的隔离，防止不同插件的 Bean 定义互相污染——这是它仍然有现实价值的地方。

💻 全栈开发专家 ​

BeanFactory 是 Spring 容器的顶层接口，只定义最基本的能力：getBean、containsBean、getType 这些。真正干活的是默认实现 DefaultListableBeanFactory——IOC 的核心发动机，BeanDefinition 注册表、三级缓存、@Autowired 解析都在这条实现线上。

和 ApplicationContext 的区别一句话：BeanFactory 是"懒"的基础容器，ApplicationContext 是"急"的超级容器。前者第一次 getBean 才实例化；后者 refresh 时就把非懒加载单例全部创建好，还多了事件发布、国际化、资源加载、自动注册 BeanPostProcessor 和 AOP 代理这些企业能力。AbstractApplicationContext 内部就持有一个 beanFactory 成员，本质是"BeanFactory + 一堆 refresh 步骤"的门面。

工程上很少直接 new BeanFactory，但排查离不开它：条件断点打在 DefaultListableBeanFactory#doGetBean，能完整看一个 Bean 从三级缓存到一级缓存的流转。另一个实用技巧：注入 getBeansOfType(PayService.class) 或 Map<String, PayService> 拿某接口全部实现做策略路由，比 if-else 分发干净得多。