Spring中的工厂模式：BeanFactory、FactoryBean与@Bean解析

1. 别被概念绕晕工厂模式在Spring里到底长什么样Spring对工厂模式的运用几乎可以说是刻在骨子里的。很多人最开始接触Spring接触的就是BeanFactory和ApplicationContext从名字上就能闻到一股“工厂”的味道。但真正要把它讲透得先回答一个很基本的问题工厂模式到底是什么它为什么在Spring里无处不在先看最朴素的例子。假设你有一个短信发送服务发送前需要初始化一个客户端对象带上appId、appSecret这些参数。如果每次用到都new一遍参数散落在业务代码里一旦初始化逻辑变了改起来会想骂人。于是你会自然而然地写一个工具类提供一个静态方法专门负责创建这个客户端public class SmsClientFactory { public static SmsClient createClient() { return new SmsClient(appId, appSecret); } }这就是最简单的“简单工厂”。调用方不再关心SmsClient怎么构建只关心从工厂里拿到的结果。工厂模式的核心思想本质上是“把创建对象的过程从使用对象的过程中剥离出来”。但工厂模式并不只有一种形态。我见过很多初学者把工厂模式等同于“一个静态方法返回对象”这其实只看到了冰山一角。在经典的设计模式分类里工厂模式通常拆成三种简单工厂一个工厂类根据参数判断返回哪种产品通常用静态方法实现。工厂方法定义一个创建对象的接口让子类决定实例化哪一个类。抽象工厂围绕一个超级工厂创建其他工厂用来创建一组相关或相互依赖的对象。Spring里三种形态都能找到对应物。getBean(smsClient)根据不同的Bean类型和名称返回不同的对象这就是简单工厂的思路BeanFactory有一整套继承体系不同的子类用不同的方式创建对象这是工厂方法的骨架而ApplicationContext在启动时会把Bean的依赖关系、配置、生命周期全部组装好再交给业务方使用这更接近抽象工厂要解决的问题——不是单独创建某一个对象而是创建一整套“可运行的系统”。之所以要花篇幅区分这三种形态是因为网上大量教程把“工厂模式”当作一个孤立的设计模式来讲但Spring的使用方式把它们的边界打散了。你在Configuration类里写的每一个Bean方法本质上都是一个工厂方法你配置的factory-method属性是直接用XML写一个静态工厂你实现FactoryBean接口是给Spring容器插入了一个自定义生产逻辑的专用工厂。理解这层对应关系后面看源码才不会迷路。2. 容器的本质从BeanFactory到ApplicationContext的工厂进化2.1 BeanFactory最原始的工厂接口BeanFactory是整个Spring IoC容器的底层接口。它做的事情非常纯粹管理Bean的定义、实例化和获取。你调用getBean(userService)它负责返回一个userService对象给你至于这个对象是怎么来的你不需要知道。如果以工厂模式的理论去看BeanFactory就是那个定义了“生产产品”行为的核心抽象。它不关心你这个Bean是用构造器创建、静态工厂创建、实例工厂创建还是FactoryBean创建它只约定结果——你给我Bean的名字我还你Bean的实例。正因为这样Spring才能做到“配置驱动”。同一个UserService今天你告诉容器它应该从数据库读数据明天你换成从缓存读数据只要Bean的定义变了容器就能生产出不同配置的对象但调用方代码一行都不用改。这就是工厂模式带来的最大价值解耦。动手验证一下BeanFactory的存在感可以写一段最原始的启动代码BeanFactory factory new XmlBeanFactory(new ClassPathResource(beans.xml)); UserService userService (UserService) factory.getBean(userService);XmlBeanFactory在现版本中已经不推荐使用了但它的代码风格非常直观地展示了“BeanFactory 一个工厂接口 一个XML配置里的Bean定义”。后来Spring推荐使用ApplicationContext但ApplicationContext本质上也是一个BeanFactory只是加了更多“大厂配置”。2.2 ApplicationContext加了“服务能力”的自动化工厂我们的项目里几乎不会直接用BeanFactory而是用ApplicationContext。原因很现实BeanFactory只负责最基本的“按需生产”但一个真正的业务系统还需要资源加载、事件发布、国际化、自动扫描这些能力。ApplicationContext就是在BeanFactory之上做了一堆扩展。打个比方BeanFactory像是一个标准车间只负责按图纸加工零件ApplicationContext则是一个完整工厂除了车间还配了仓库、物流、质量检测和调度中心。你要一个零件它不只是现加工而是先把原料、设备、人员全部准备好再高效地按订单生产。ApplicationContext最明显的一个行为差异是在容器启动时就会预加载所有单例Bean。BeanFactory则是你什么时候getBean什么时候才创建。这在最开始可能不觉得有什么直到你遇到“为什么系统启动很慢但某次接口第一次调用特别慢”的问题时你才意识到容器预加载做了多少事。选择建议也很简单日常项目一律用ApplicationContext的某个子类比如AnnotationConfigApplicationContext或者ClassPathXmlApplicationContext。只有在极端需要节省启动资源、对内存锱铢必较的场景才考虑直接使用BeanFactory。2.3 单例池与工厂的产物管理工厂模式里还有个很容易被忽略的细节工厂创建的产品是否需要缓存每次调用都创建新对象还是一起共享同一个对象Spring的默认策略是单例。这背后的存储结构就是“单例池”。在Spring中单例Bean创建完成后会被放入一个Map里下次再用同一个名字获取时直接从这个Map中拿不再重复创建。如果你希望每次getBean都拿到一个新对象需要把Bean的scope改成prototype。实际开发中我见过不少人在自定义工厂类时自己写缓存逻辑其实完全没必要。Spring已经把这件事做得很成熟了Bean public SmsClient smsClient() { return new SmsClient(appId, appSecret); }Spring保证smsClient这个Bean在容器中是单例的。但这里有一个隐藏的坑如果你在Bean方法里调用了另一个Bean方法而不是通过参数注入单例是否仍然成立这取决于你所在的类是不是Configuration后面章节会专门展开。所以工厂模式在Spring里不是孤立存在的它和生命周期、作用域、依赖注入是交织在一起的。理解工厂模式不能只看“怎么创建对象”还要看“创建完之后容器怎么管它”。3. 在Spring里亲手搭建工厂三种配置方式实操3.1 静态工厂方法最直接的“模板方法”在XML时代静态工厂方法是Spring配置里非常常见的一种手法。所谓静态工厂方法就是说这个工厂类里的方法是static的Spring不需要实例化工厂类直接调用静态方法就能拿到产品。举一个真实的例子。假设我们有一个JSON解析器框架要求只能通过它提供的静态方法来获取实例public class JsonParserFactory { public static JsonParser createJsonParser() { return new JsonParser(JsonParserConfig.defaultConfig()); } }XML里配置成bean idjsonParser classcom.example.JsonParserFactory factory-methodcreateJsonParser/Spring容器启动后获取jsonParser这个Bean时实际执行的是JsonParserFactory.createJsonParser()返回给调用方的是JsonParser实例而不是JsonParserFactory的实例。这一点是静态工厂方法最容易让人困惑的地方配置的class是工厂类但最终产出的Bean类型取决于工厂方法返回什么。切换到注解配置后这种场景基本可以用Bean平替Configuration public class JsonConfig { Bean public JsonParser jsonParser() { return JsonParserFactory.createJsonParser(); } }不过静态工厂方法有一个天然缺陷工厂方法本身是静态的它无法访问Spring容器里的其他Bean。如果你的工厂方法依赖了某个Spring管理的服务静态方法就没有任何办法拿到这个依赖只能在参数里传入。这也是后来大家更愿意使用Bean方式的原因——一个Bean方法可以随意注入依赖。3.2 实例工厂方法工厂Bean引路实例工厂方法解决的就是静态工厂“拿不到依赖”的问题。在这种方式里工厂类本身要注册为一个Bean然后Spring通过调用这个工厂Bean的实例方法来创建目标Bean。配置形式大概长这样bean idsmsClientFactory classcom.example.SmsClientFactory/ bean idsmsClient factory-beansmsClientFactory factory-methodcreateClient/这里smsClientFactory是一个普通的BeanSpring会先创建它然后执行它的createClient()方法把返回值作为smsClientBean提供出去。因为工厂Bean本身是容器管理的所以它可以在createClient()里注入其他Spring依赖Component public class SmsClientFactory { Autowired private SmsConfig smsConfig; public SmsClient createClient() { return new SmsClient(smsConfig.getAppId(), smsConfig.getAppSecret()); } }这种方式比静态工厂灵活但配置起来比较绕。现在注解开发环境下Bean已经完全覆盖了这个功能而且更加直观Configuration public class SmsConfig { Autowired private SmsProperties smsProperties; Bean public SmsClient smsClient() { return new SmsClient(smsProperties.getAppId(), smsProperties.getAppSecret()); } }3.3 FactoryBean接口Spring最特色的工厂扩展点如果说前面两种工厂方式只是“配置技巧”那FactoryBean就是Spring专门为工厂模式设计的一套“官方接口”。很多人把FactoryBean和BeanFactory搞混名字实在太像了但两者的定位完全不同BeanFactory是容器本身FactoryBean是放进容器里的一个特殊Bean它被用来“生产另外一些Bean”。FactoryBean接口一共有三个方法public interface FactoryBeanT { T getObject() throws Exception; Class? getObjectType(); default boolean isSingleton() { return true; } }getObject()返回真正要暴露给容器的产品对象。getObjectType()返回产品的类型Spring可以用它做类型匹配。isSingleton()控制产品是否是单例。这种设计最大的好处是你可以在创建Bean时加入大量定制逻辑而这些逻辑对调用方完全透明。以前我接手过一个老项目需要把某个第三方SDK的客户端注册成Spring Bean但这个客户端的构造函数非常复杂要读配置文件、要初始化连接池、还要做版本检查。如果放在Bean方法里写代码会非常臃肿。后来我把它封装成一个FactoryBean创建逻辑收拢到getObject()里清爽很多Component public class OssClientFactoryBean implements FactoryBeanOssClient { private final OssProperties properties; public OssClientFactoryBean(OssProperties properties) { this.properties properties; } Override public OssClient getObject() { return new OssClient(properties.getEndpoint(), properties.getAccessKey(), properties.getSecretKey(), properties.getBucketName()); } Override public Class? getObjectType() { return OssClient.class; } Override public boolean isSingleton() { return true; } }有意思的是当你想获取某个FactoryBean生产的Bean时直接getBean(ossClientFactoryBean)拿到的并不是FactoryBean本身而是它生产的OssClient对象。如果你真的想拿到FactoryBean的实例需要加一个前缀OssClient ossClient applicationContext.getBean(ossClientFactoryBean, OssClient.class); OssClientFactoryBean factoryBean applicationContext.getBean(ossClientFactoryBean, OssClientFactoryBean.class);这个规则听起来很冷门但用到了才觉得设计得很微妙。它保证了对使用方来说大多数时候只需要关心“产品”而不需要关心“工厂”。3.4 Bean与Configuration注解风潮下的工厂方法随着注解开发成为主流Bean已经成了日常代码中出现频率最高的工厂模式体现。你可能没意识到自己每天都在写工厂方法。当一个类上标注Configuration里面的每一个Bean方法就是一个工厂方法。Spring容器的职责就是调用这些方法把返回值纳入容器管理。这和XML里配置factory-method本质上没有区别只是换了一种表达语言。Configuration public class WebConfig { Bean public RestTemplate restTemplate(RestTemplateBuilder builder) { return builder.connectTimeout(Duration.ofSeconds(5)) .readTimeout(Duration.ofSeconds(5)) .build(); } Bean public ObjectMapper objectMapper() { ObjectMapper mapper new ObjectMapper(); mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); return mapper; } }需要注意一个细节Bean方法可以接收参数这些参数会由Spring容器按类型自动注入。这一点其实很重要意味着你的工厂方法不必是静态的也不必依赖一个专门的FactoryBeanSpring自己就完成了“工厂方法需要依赖其他Bean”的问题。另一个容易被忽视的点是Bean方法所在的类必须是Configuration才能保证单例语义。如果类上用的是ComponentBean方法也有效但Spring不会对组件类做CGLIB代理增强每次调用Bean方法时可能生成不同实例。这个问题放到后面排雷部分细说。刚才说的所有这些方式在Spring源码里都会殊途同归最终都是在AbstractAutowireCapableBeanFactory的某个环节被处理。接下来我们就进源码看看一个Bean到底是怎么被“生产”出来的。4. 源码视角一个Bean在工厂里走过的完整产线4.1 从getBean开始的生产链路结构化的理解工厂模式在Spring中的落地光会配置还不够。我们随便打开一版Spring源码从getBean开始追会发现一条非常清晰的生产链路。调用方执行context.getBean(userService)时进入的是AbstractBeanFactory.doGetBean。这里有几个关键步骤先尝试从单例池中获取如果拿到说明之前已经生产过直接返回这叫“有缓存就不重复生产”。如果拿不到检查当前Bean是否有其他Bean在创建过程中引用它这就涉及循环依赖的三级缓存机制。最后走createBean流程。createBean在AbstractAutowireCapableBeanFactory里实现它做的工作是检查BeanPostProcessor是否可以返回代理对象比如AOP场景下这里可能直接返回一个增强后的对象。如果不需要代理调用doCreateBean正式创建。doCreateBean里调用createBeanInstance这一步就是“实例化决策”的核心。从工厂模式的角度看createBeanInstance才是真正的“生产车间”。它要根据当前Bean的配置信息决定使用哪条产线。值得一提的是这个过程中Spring会执行一个InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation让外部有机会在正式创建之前“截胡”。比如某些框架就是在这里做Bean替换的。4.2 createBeanInstance中的“工厂决策树”我们继续往下看createBeanInstance这个方法的逻辑。以Spring 5.x的源码为例它内部大致按顺序检查了这几条路径第一检查instanceSupplier。这是Spring 5.0引入的编程式注册Bean的一个入口允许你直接提供一个Supplier回调Spring调用它生成实例。这是最简单、最直白的工厂回调。第二检查factoryMethod。如果这个Bean是通过XML的factory-method、factory-bean配置或者通过Bean注解方法定义的那么这里就会走工厂方法路径。Spring会找到对应的工厂方法处理参数通过反射调用它返回对象。第三检查是否有多个构造函数如果有且无法确定用哪个启动通常会报错或者需要显式标注Autowired和Primary来提示Spring。第四退回到最常见的无参构造函数直接反射实例化。把这段逻辑对应到工厂模式factoryMethod的存在意味着Spring定义的Bean并不是直接new出来的而是“从工厂方法里取”。这就让Bean的定义变得极其灵活。你可以在Bean方法里做参数判断、依赖调用、缓存检查然后决定返回A实现还是B实现Bean public PaymentService paymentService(ListPaymentStrategy strategies) { if (enableQuickPay) { return new QuickPayService(strategies); } return new StandardPayService(strategies); }这在运行期通过环境配置或某种开关动态决定创建哪个产品是工厂模式非常典型的使用场景。4.3 初始化阶段的织入与后处理实例化完成不等于Bean已经可以用了。Spring接下来要做依赖注入、初始化回调、BeanPostProcessor增强这一整套动作。从工厂模式的角度看这相当于“产品出厂前的质检、包装和定制”。依赖注入发生在实例化之后。Spring会扫描Bean里的Autowired、Resource等注解把依赖的其他Bean注入进来。这一步如果失败比如BeanA需要BeanB但BeanB不存在容器会直接启动失败。用工厂类比的话就是产线发现缺料直接停机报警。接着是BeanPostProcessor的postProcessBeforeInitialization、PostConstruct、InitializingBean、init-method、postProcessAfterInitialization这一串执行顺序。很多AOP代理就是在postProcessAfterInitialization这一步生成的。也就是说工厂把Bean生产出来之后还给了一条“后处理流水线”让各个框架可以趁机对Bean进行包装。理解这条链路之后你会发现一个很重要的点Spring的工厂模式不是简单的“创建对象”就结束了它把对象从“创建”到“可用”完整地管了起来。这也是为什么Spring容器叫IoC容器而不叫“对象工厂”——它不仅仅负责制造还负责装配、改造和交付。5. 实战排雷工厂模式在Spring中的高频问题与个人经验5.1 高频问题速查BeanFactory与FactoryBean的思维错位先列一个最容易被混淆的概念对比我在很多代码评审里都见过这方面的误解对比项BeanFactoryFactoryBean定位IoC容器的顶层接口一种特殊的Bean职责管理所有Bean的生命周期专门生产某一个或某一类Bean获取方式容器本身加前缀获取工厂本身常见实现DefaultListableBeanFactory自定义FactoryBean实现类如果你发现同事在代码里写applicationContext.getBean(xxxFactoryBean)然后强转成业务对象多半是对FactoryBean的机制不熟悉。这个问题的排查方式也简单先看Bean定义是不是FactoryBean类型再决定要不要加前缀。还有一个容易踩的坑是FactoryBean的getObjectType()返回泛型或null。Spring在做类型匹配时如果拿不到类型会自动调用getObject()来推测类型这会导致提前初始化产品对象如果产品创建逻辑很重启动时间会明显变长。所以实现FactoryBean时getObjectType()务必尽量准确。5.2 Configuration和Component对Bean工厂方法的不同影响这个坑我在很多团队里见过而且它非常隐蔽。假设我们有这样一段代码Component public class AppConfig { Bean public A a() { return new A(); } Bean public B b() { return new B(a()); } }启动时Spring会创建A和B两个Bean。现在问题来了b()方法里调用了a()如果返回的是新对象那么B里持有的A就和容器里的A不是同一个对象破坏了单例语义。这在不经意间会引发一堆诡异问题比如事务代理不生效、状态不一致等。当类上标注的是Configuration时Spring会对这个类做CGLIB代理所以b()里调用a()实际上调用的是被代理后的方法会从容器中复用同一个A实例。但类上是Component时Spring不做这个代理a()就会返回一个新对象。这里给个坚决的建议如果类里有多个Bean方法并且它们之间存在调用关系类上必须使用Configuration不要偷懒用Component。内部调用改成参数注入则更安全Configuration public class AppConfig { Bean public A a() { return new A(); } Bean public B b(A a) { return new B(a); } }用参数注入不但绕开了代理问题也让依赖关系更明显。这是我个人极力推荐的做法。5.3 工厂方案选型的判别清单写到这里我整理一份在Spring中使用工厂模式的选型清单方便你在项目中做决定如果只是想创建一个Bean且需要从Spring拿依赖优先用Bean方法简单直接。如果创建逻辑复杂涉及大量配置和第三方资源准备考虑使用FactoryBean把复杂逻辑封装在工厂内部。如果只是想把一个外部静态方法的结果注册成Bean用Bean封装一下别再用XML的静态工厂配置。如果需要在运行时根据条件决定创建哪个实现类在Bean方法里做判断或配合Conditional注解。如果产品对象不需要Spring管理生命周期只是想用一个工厂类来自动创建完全可以在Service里自己定义一个私有方法不一定要把工厂暴露成Spring Bean。这套清单基本覆盖了我日常开发中遇到的大部分场景。核心思路永远是优先选最直观、最不容易出错的方案而不是最“设计模式”的方案。工厂模式的本质是为了让代码更好维护而不是为了展示你懂多少种写法。再分享一个排查技巧。当你怀疑某个Bean的创建有问题时可以直接在AbstractAutowireCapableBeanFactory.createBeanInstance处打一个条件断点条件设为Bean名然后观察它走了哪条创建路径。是走了factoryMethod还是默认构造器一目了然。这个方法在调试第三方框架集成时极其好用建议你下次遇到类似问题可以试试。在实际项目中工厂模式在Spring里还有一个经常被忽略的用途当你需要给一组Bean统一加某种行为时可以利用FactoryBean配合BeanPostProcessor来实现。比如所有产品Bean创建完成后自动打日志、做权限校验或者注入公共上下文。这种组合虽然有一定复杂度但在中大型系统里非常有价值。我自己维护的一个老项目里就用FactoryBean统一管理所有外部接口客户端接入新的第三方渠道时只需要新增一个工厂实现类主流程完全不用改。这种“加需求不加改动”的体验正是工厂模式带来的长期红利。