1. 从一个让人头疼的重复代码说起如果你写过一段时间的业务代码大概率遇到过这样的场景系统里有一个配置对象字段有几十个每次需要一个新的实例时要么手动一个个 set要么在构造函数里塞一大串参数。更麻烦的是这个对象在创建之后还需要经过几步加工——先加载默认值再覆盖用户配置最后做一些校验和预处理。这套流程在代码里重复出现了七八次每次改动都要同步修改所有地方。我最早接触原型设计模式就是因为被这类问题折磨得不行。当时有一个报表导出模块导出配置对象包含数据源、字段映射、格式化规则、分页参数等一大堆属性。每次新增一种报表类型就要重新构建一遍这个配置对象代码里到处是重复的初始化逻辑。后来我把这个配置对象改成了“可克隆”的先创建一个基准配置然后通过克隆加微调来生成新的配置代码量直接砍掉了三分之二。原型设计模式的核心思想其实就一句话用一个已经存在的对象作为模板通过复制它来创建新对象而不是从头开始构造。这听起来简单但在实际项目里它能解决很多让人头疼的问题。尤其是在 Spring 这样的框架中原型模式有着非常自然的应用场景——Spring 本身就有一个prototype作用域虽然它和设计模式里的原型模式不完全是一回事但背后的思路是相通的。这篇文章会从原型模式的底层原理讲起然后重点聊它在 Spring 框架中的实际应用方式包括BeanDefinition的克隆、prototype作用域的底层实现、以及我们自己如何在业务代码中优雅地使用原型模式。文章会涉及不少源码级别的分析但我会尽量用大白话把逻辑讲清楚不管你是刚接触设计模式的新手还是已经用过但没深究过原理的老手应该都能有所收获。2. 原型模式的底层逻辑为什么是“克隆”而不是“新建”2.1 从对象创建的代价说起在讨论原型模式之前先想一个问题创建一个对象到底有多“贵”对于简单的 POJO 来说new一个对象的代价几乎可以忽略不计。但如果对象的创建过程涉及以下情况代价就会显著上升构造函数逻辑复杂需要在构造时读取配置文件、连接数据库、加载远程数据。初始化步骤多创建之后还需要经过多步加工才能达到可用状态。对象图庞大一个对象内部嵌套了多层子对象构造时需要递归创建。创建频率高在循环或高频调用的场景中反复创建同类对象。原型模式的思路是既然创建一个对象这么麻烦那我能不能直接复制一个已经创建好的对象就像复印一份文件比重新手写一份要快得多。这就是原型模式的核心——通过克隆已有对象来创建新对象把“创建”这个动作从“从零构建”变成“复制现有”。2.2 浅克隆与深克隆一个绕不开的选择原型模式在实现层面最核心的问题就是克隆到底要克隆到什么程度Java 提供了Cloneable接口和Object.clone()方法来实现克隆。但Object.clone()默认实现的是浅克隆——它只复制对象本身的字段值如果字段是引用类型复制的是引用地址而不是引用指向的对象。举个例子public class ReportConfig implements Cloneable { private String name; private ListString fields; private DataSourceConfig dataSource; Override public ReportConfig clone() throws CloneNotSupportedException { return (ReportConfig) super.clone(); } }用这种方式克隆出来的对象name是独立的因为 String 是不可变对象但fields和dataSource指向的还是同一个对象。修改克隆对象的fields列表原对象的fields也会跟着变。这在实际使用中往往不是我们想要的结果。深克隆则是把对象内部所有引用类型的字段也一并复制。实现深克隆有几种常见方式方式实现难度性能适用场景手动递归克隆中等较好对象结构不复杂字段可控序列化/反序列化低较差对象图复杂对性能要求不高JSON 序列化低中等对象是标准 POJO无循环引用拷贝构造函数中等好需要精细控制克隆逻辑手动递归克隆是最可控的方式但代码量较大。序列化方式最省事但性能开销明显尤其是对象图很大的时候。JSON 序列化介于两者之间在业务代码中用得比较多。选择哪种克隆方式取决于你的对象结构复杂度和性能要求。如果对象内部只有基本类型和不可变对象浅克隆就够了。如果有可变引用类型就必须考虑深克隆。2.3 原型模式在经典 GoF 中的定位在经典的 GoF 二十三种设计模式中原型模式属于创建型模式和单例、工厂方法、抽象工厂、建造者并列。它的 UML 结构非常简单Prototype声明克隆方法的接口。ConcretePrototype实现克隆方法的具体类。Client通过调用克隆方法来创建新对象。原型模式的适用条件也很明确创建对象的代价较大而复制对象的代价较小。系统需要动态地创建对象且对象的类型在运行时才能确定。需要避免使用工厂类层级来创建对象减少类的数量。但说实话在日常业务开发中纯粹的原型模式用得并不多。它更多是作为一种“思路”渗透在各种框架和工具中。Spring 框架里就有大量原型模式的影子只是很多人用了却没意识到。3. Spring 中那些“隐藏”的原型模式3.1 BeanDefinition 的克隆Spring 启动时的原型实践Spring 在启动过程中需要解析配置文件或注解生成大量的BeanDefinition对象。每个BeanDefinition描述了如何创建一个 Bean包括类名、作用域、依赖关系、初始化方法等信息。问题来了如果多个 Bean 的配置大部分相同只有少部分不同Spring 会怎么做答案是克隆。在 Spring 的DefaultListableBeanFactory中有一个方法叫registerBeanDefinition它会将解析好的BeanDefinition注册到容器中。而在解析阶段比如ConfigurationClassBeanDefinitionReader处理Bean注解时会先创建一个基准的BeanDefinition然后根据具体的方法签名和注解信息进行定制。更典型的例子是ScopedProxyFactoryBean和RootBeanDefinition的使用。RootBeanDefinition提供了一个拷贝构造函数public RootBeanDefinition(RootBeanDefinition original) { super(original); this.targetType original.targetType; this.factoryMethodName original.factoryMethodName; // ... 复制其他属性 }这个拷贝构造函数就是原型模式的体现——通过复制已有的BeanDefinition来创建一个新的定义而不是从头解析。为什么 Spring 要这么做因为BeanDefinition的解析过程涉及注解扫描、元数据读取、条件判断等操作代价不低。通过克隆已有的定义再微调可以显著减少重复解析的开销。3.2 prototype 作用域每次获取都是新对象Spring 的prototype作用域是很多人最早接触到的“原型”概念。配置一个 Bean 为prototype后每次通过getBean()获取时容器都会创建一个新的实例。但这里有个容易混淆的点Spring 的 prototype 作用域并不是通过克隆来实现的。它的底层逻辑是每次请求 Bean 时调用createBean()方法走完整的 Bean 创建流程——实例化、属性填充、初始化。也就是说它本质上还是“新建”而不是“克隆”。那为什么叫 prototype因为它模拟了原型模式的效果——每次获取都是一个独立的、全新的对象。但从实现机制上看它和 GoF 的原型模式是两回事。这一点在面试中经常被问到很多人会答错。我个人的理解是Spring 的 prototype 作用域是“原型模式思想”在容器层面的一种体现但实现上用的是工厂方法模式。真正在 Spring 内部用到克隆的地方是BeanDefinition的复制和BeanWrapper的处理。3.3 BeanUtils.copyProperties最常用的“伪原型”说到 Spring 里的对象复制BeanUtils.copyProperties可能是用得最多的工具方法。它把一个对象的属性值复制到另一个对象中常用于 DTO 和 Entity 之间的转换。UserDTO userDTO new UserDTO(); BeanUtils.copyProperties(userEntity, userDTO);这算不算原型模式严格来说不算因为它没有创建新对象只是复制属性值。但它体现了原型模式的核心思路——基于已有对象来生成新对象的状态。在实际项目中我经常用BeanUtils.copyProperties配合一个“模板对象”来快速创建配置对象。比如ReportConfig template configService.getDefaultConfig(); ReportConfig custom new ReportConfig(); BeanUtils.copyProperties(template, custom); custom.setName(自定义报表); custom.setFields(customFields);这种方式比手动 set 每个字段要简洁得多而且当模板对象的字段增加时不需要修改复制代码。注意BeanUtils.copyProperties是浅拷贝。如果模板对象内部有可变引用类型复制后的对象和原对象会共享这些引用。需要深拷贝时得配合序列化或其他方式处理。4. 在业务代码中落地原型模式几个真实场景4.1 场景一配置对象的快速派生这是我最常用的场景。系统里有一类“配置对象”它们有大量的默认值用户只需要覆盖其中少数几个字段。如果每次都从头构建代码会非常冗长。我的做法是先创建一个“基准配置”作为原型然后通过克隆来派生新的配置。public class ExportConfig implements Cloneable { private String templateName default; private String format xlsx; private int pageSize 1000; private boolean includeHeader true; private ListString columns new ArrayList(); private MapString, Object extraParams new HashMap(); Override public ExportConfig clone() { try { ExportConfig cloned (ExportConfig) super.clone(); // 深克隆可变字段 cloned.columns new ArrayList(this.columns); cloned.extraParams new HashMap(this.extraParams); return cloned; } catch (CloneNotSupportedException e) { throw new RuntimeException(克隆失败, e); } } }使用的时候ExportConfig baseConfig configService.getBaseConfig(); ExportConfig customConfig baseConfig.clone(); customConfig.setFormat(csv); customConfig.setPageSize(500);这样做的好处是新增字段时只要在clone()方法里处理好深克隆逻辑所有派生配置都会自动带上新字段的默认值。4.2 场景二测试数据的构造写单元测试时经常需要构造各种测试数据。如果每个测试方法都手动 new 一个对象再逐个 set 字段代码会非常臃肿。我的做法是在测试基类里定义一个“数据模板”各个测试方法通过克隆模板来快速构造数据。public abstract class BaseTest { protected User createDefaultUser() { User user new User(); user.setName(测试用户); user.setAge(25); user.setEmail(testexample.com); user.setRoles(Arrays.asList(USER)); return user; } protected User createUserWithRole(String role) { User user createDefaultUser(); user.setRoles(Collections.singletonList(role)); return user; } }这种方式在测试代码中用得非常多本质上就是原型模式的思想——用一个基准对象作为模板通过微调来生成不同的测试数据。4.3 场景三缓存对象的副本返回在缓存场景中如果直接把缓存中的对象返回给调用方调用方修改了这个对象缓存里的数据就被污染了。这时候就需要返回一个副本。public class ConfigCache { private final MapString, Config cache new ConcurrentHashMap(); public Config getConfig(String key) { Config cached cache.get(key); if (cached null) { return null; } return cached.clone(); // 返回副本保护缓存 } }这种方式在并发环境下尤其重要。如果多个线程同时获取同一个配置对象并修改它不加保护的话会出现各种诡异的问题。这里有个性能考量如果配置对象很大每次获取都克隆一份开销可能不小。这时候可以考虑用不可变对象Immutable Object来替代克隆——对象创建后不允许修改所有“修改”操作都返回一个新对象。这样就不需要克隆了直接返回即可。4.4 场景四动态生成相似对象在一些规则引擎或工作流引擎中需要根据模板动态生成任务节点。每个任务节点的结构相似但参数不同。这时候可以用原型模式来快速生成。public class TaskNode implements Cloneable { private String nodeType; private MapString, String params; private ListTaskNode children; Override public TaskNode clone() { try { TaskNode cloned (TaskNode) super.clone(); cloned.params new HashMap(this.params); cloned.children new ArrayList(); for (TaskNode child : this.children) { cloned.children.add(child.clone()); } return cloned; } catch (CloneNotSupportedException e) { throw new RuntimeException(e); } } }这种递归克隆的方式可以完整复制一棵任务树然后在此基础上做局部调整。5. 克隆的坑那些年我踩过的雷5.1 浅克隆引发的数据污染这是我踩过的最大的坑。早期做一个报表配置功能时我用Object.clone()克隆了一个配置对象然后修改了克隆对象的字段列表。结果发现原对象的字段列表也跟着变了导致所有使用该配置的报表都出了问题。排查了半天才意识到Object.clone()是浅克隆List字段复制的是引用。修改克隆对象的列表等于修改了原对象的列表。解决方案在clone()方法中手动深克隆所有可变引用类型字段。或者改用序列化方式做深克隆。5.2 Cloneable 接口的“空接口”陷阱Cloneable是一个标记接口里面没有任何方法。clone()方法定义在Object类中而且是protected的。这意味着如果一个类没有实现Cloneable接口调用clone()会抛出CloneNotSupportedException。如果子类没有重写clone()调用的是父类的实现可能不符合子类的需求。我见过有同事在子类中忘记重写clone()结果克隆出来的对象类型不对运行时才报错。解决方案每个需要克隆的类都显式实现Cloneable并重写clone()在方法中处理好深克隆逻辑。5.3 构造函数不会被调用Object.clone()创建对象时不会调用构造函数。这意味着如果构造函数中有一些初始化逻辑比如注册监听器、初始化缓存克隆出来的对象不会执行这些逻辑。这个特性有时候是好事避免重复初始化有时候是坑遗漏必要的初始化。解决方案如果克隆后需要执行某些初始化逻辑可以在clone()方法中手动调用或者提供一个initAfterClone()方法。5.4 final 字段无法被克隆修改如果类中有final字段clone()方法无法修改它的值。因为final字段只能在构造函数或初始化块中赋值。这在某些场景下会造成麻烦。比如一个类有一个final的 ID 字段克隆后希望生成一个新的 ID但final字段不允许修改。解决方案不要把需要克隆后修改的字段声明为final。或者改用其他方式创建对象比如拷贝构造函数。5.5 循环引用导致栈溢出如果对象之间存在循环引用A 引用 BB 引用 A递归深克隆会导致无限递归最终栈溢出。解决方案使用序列化方式做深克隆序列化框架通常能处理循环引用或者在克隆时用一个 Map 记录已克隆的对象避免重复克隆。6. 原型模式 vs 其他创建型模式怎么选6.1 和工厂模式的对比工厂模式关注的是“创建什么类型的对象”原型模式关注的是“基于哪个对象来创建”。工厂模式通常需要为每种产品定义一个工厂类而原型模式只需要一个克隆方法。如果对象的创建逻辑复杂且多变工厂模式更合适。如果对象的结构相似只是属性值不同原型模式更简洁。6.2 和建造者模式的对比建造者模式适合构建步骤固定但组合方式多变的对象。原型模式适合基于已有对象快速派生新对象。在实际项目中两者经常结合使用用建造者模式构建一个“基准对象”然后用原型模式克隆它来生成变体。6.3 选型决策表场景特征推荐模式理由对象创建步骤复杂需要分步构建建造者模式可以精细控制构建过程对象类型在运行时决定工厂模式可以根据条件选择创建逻辑对象结构相似只需微调属性原型模式克隆比重新构建更高效需要保证全局唯一实例单例模式控制实例数量对象创建代价大但复制代价小原型模式避免重复的高代价创建7. 进阶技巧让原型模式更好用7.1 用拷贝构造函数替代 CloneableCloneable和clone()的设计一直被人诟病——标记接口、protected 方法、浅克隆默认行为都容易出错。Joshua Bloch 在《Effective Java》中就建议用拷贝构造函数替代clone()。public class ExportConfig { private String format; private ListString columns; public ExportConfig(ExportConfig other) { this.format other.format; this.columns new ArrayList(other.columns); } }拷贝构造函数的好处是类型安全、不需要处理CloneNotSupportedException、可以精细控制每个字段的复制方式。7.2 用序列化实现通用深克隆如果不想为每个类手写克隆逻辑可以用序列化实现一个通用的深克隆工具public class DeepCloneUtil { SuppressWarnings(unchecked) public static T extends Serializable T deepClone(T obj) { try { ByteArrayOutputStream baos new ByteArrayOutputStream(); ObjectOutputStream oos new ObjectOutputStream(baos); oos.writeObject(obj); oos.close(); ByteArrayInputStream bais new ByteArrayInputStream(baos.toByteArray()); ObjectInputStream ois new ObjectInputStream(bais); return (T) ois.readObject(); } catch (Exception e) { throw new RuntimeException(深克隆失败, e); } } }这种方式简单粗暴但要求对象实现Serializable接口且性能不如手动克隆。7.3 用 JSON 序列化做深克隆在 Spring 项目中通常已经有 Jackson 或 Gson 的依赖。用 JSON 序列化做深克隆也很方便public class JsonCloneUtil { private static final ObjectMapper mapper new ObjectMapper(); public static T T deepClone(T obj, ClassT clazz) { try { String json mapper.writeValueAsString(obj); return mapper.readValue(json, clazz); } catch (Exception e) { throw new RuntimeException(JSON 深克隆失败, e); } } }这种方式不需要对象实现Serializable但要求对象是标准 POJO且不能有循环引用。7.4 原型注册表管理可克隆对象的集合如果系统中有多个可克隆的原型对象可以维护一个“原型注册表”来统一管理public class PrototypeRegistry { private final MapString, Cloneable prototypes new ConcurrentHashMap(); public void register(String key, Cloneable prototype) { prototypes.put(key, prototype); } public Cloneable getClone(String key) { Cloneable prototype prototypes.get(key); if (prototype null) { throw new IllegalArgumentException(未注册的原型: key); } return (Cloneable) prototype.clone(); } }这种方式在需要动态切换原型的场景中很有用比如根据用户配置选择不同的报表模板。8. 我在实际项目中的几点体会原型模式不是一个“显眼”的设计模式它不像单例、工厂那样在代码中随处可见。但它的思想——基于已有对象来创建新对象——在实际开发中非常实用。我个人的经验是不要为了用模式而用模式。如果一个对象的创建逻辑很简单直接 new 就行了没必要搞克隆。只有当创建代价明显大于复制代价或者需要基于已有对象做大量微调时原型模式才真正有价值。另外克隆的深拷贝问题一定要重视。我见过太多因为浅克隆导致的数据污染问题排查起来非常费劲。如果决定用克隆一定要在clone()方法或拷贝构造函数中把所有可变引用类型都处理干净。在 Spring 项目中BeanUtils.copyProperties配合模板对象是一种很实用的“轻量级原型模式”。它不需要实现Cloneable也不需要处理CloneNotSupportedException代码更简洁。但要注意它也是浅拷贝需要深拷贝时得额外处理。最后分享一个小技巧如果一个对象需要频繁克隆可以考虑把它设计成不可变对象。不可变对象天然线程安全不需要克隆就能安全共享。所有“修改”操作都返回一个新对象本质上也是一种原型模式的变体。这种方式在函数式编程中很常见在 Java 中也可以通过final字段和防御性拷贝来实现。