简介：这份PPT围绕软件设计模式中的原型模式展开，面向正在学习面向对象设计、准备课程汇报或复习创建型模式的学生与开发者，帮助厘清通过复制原型对象创建新实例的核心思路。内容从概念与意图切入，延伸到适用场景、优缺点权衡，并重点区分浅克隆与深拷贝的实现差异，结合Java中clone()方法、Cloneable接口及CloneNotSupportedException异常说明落地要点。课件还梳理客户类、抽象原型类与具体原型类的角色关系，给出ConcretePrototype与Client的代码示例，便于对照理解复制过程、异常处理以及对象状态一致性等注意点。压缩包共1个pptx文件，约5.93MB，以幻灯片形式组织理论、对比与示例，适合课堂展示或自学查阅。目前已有192人学习，可作为设计模式专题的轻量参考资料，也便于面试前快速梳理创建型模式的要点。

1. 原型模式：复制一个对象，为什么反而比 new 更快

第一次接触原型模式，多数人的直觉是反的：复制一个对象怎么可能比 new 一个更快？new 只是分配一块干净内存，复制还得把字段一个个抄过去。这个直觉在对象只有三五个字段时成立，但落到真实系统里常常反过来——真正贵的从来不是那块内存，而是构造过程：读配置、查缓存、算校验码、拼装子对象、灌一堆默认值。

原型模式解决的正是这件事。它是设计模式里的一种创建型模式，思路朴素到有点"作弊"：把一个已经构造好的对象当作图纸，后续实例都从它身上抄，而不是重新描述一遍怎么造。

这套课件把原型模式的角色结构、浅克隆与深克隆的内存差异、以及一份完整的邮件复制代码摆在一起，恰好覆盖了"知道它会用"到"明白它为什么这么设计"之间那段最容易卡住的路。所以，下面就从 clone() 这个看起来平平无奇的方法说起。

2. clone() 的契约：为什么复制对象可以绕开构造器

2.1 Cloneable 是个空接口，凭什么能拦住一次 clone 调用

翻开 JDK 源码，Cloneable里面什么都没有，没有方法，没有常量，纯得像个占位符。而Object.clone()的声明是：

protected native Object clone() throws CloneNotSupportedException;

native说明它在 Java 层面看不到实现，真正的逻辑在虚拟机里。那么"类必须实现 Cloneable 才能被克隆"这条规则由谁保证？答案是运行时检查，不是编译期检查。虚拟机在进入克隆逻辑之前会先判断当前对象的类型是否实现了Cloneable，没实现就直接抛CloneNotSupportedException。

这是一个相当特别的设计取舍。换成"合理"的做法，应该是把 clone 定义成接口方法，让编译器替你检查——但那样所有类都被迫重写它。标记接口的方案让不需要克隆的类什么都不用做，代价是把一部分错误从编译期推迟到了运行期。血泪经验通常就诞生在这一次推迟上：代码编译通过，跑起来才炸。

课件里的抽象原型类是这样的：

// 抽象原型类：给出所有具体原型类所需的接口 abstract class Prototype implements Cloneable { @Override protected Prototype clone() throws CloneNotSupportedException { // super.clone() 是 Object 的 native 方法，返回的是 Object，必须强转 return (Prototype) super.clone(); } }

这里有两件事值得单独说清。第一，super.clone()返回类型是Object，强转不是可选项；第二，可见性是protected，这意味着跨包调用时Client根本看不到这个方法，实际项目里通常在具体原型类中把可见性提升到public，Java 5 之后还允许覆盖方法返回子类型（协变返回类型），于是ConcretePrototypeA.clone()可以直接声明返回ConcretePrototypeA，调用方连强转都省了：

public class ConcretePrototypeA extends Prototype { @Override public ConcretePrototypeA clone() throws CloneNotSupportedException { // 协变返回类型：覆盖时收窄返回类型，调用方无需强转 return (ConcretePrototypeA) super.clone(); } }

2.2 三条契约：判断一次克隆是否"还算个克隆"

课件的概述部分列了三条约定，这三条不是形式主义，它们是判断clone()有没有被写歪的标准：

第二条尤其容易被忽略。如果用"新建一个空对象再手动 set 一遍"的方式实现 clone，一旦父类被继承、子类没跟着改，返回的就会是父类型的实例，getClass()立刻对不上。而super.clone()走的是虚拟机路径，返回的对象和原对象属于同一个运行时类，这条契约天然成立——包括子类的额外字段，因为整块内存是被原样复制的。

课件里 Client 的验证代码就是把这三条拉开看一眼：

public class Client { public static void main(String[] args) throws CloneNotSupportedException { Prototype prototypeA = new ConcretePrototypeA(); Prototype copyA1 = prototypeA.clone(); Prototype copyA2 = prototypeA.clone(); // 三个引用打印出来的哈希段不同，说明是不同的实例 System.out.println("原对象A：" + prototypeA + "，类型：" + prototypeA.getClass()); System.out.println("克隆A1：" + copyA1 + "，类型：" + copyA1.getClass()); System.out.println("克隆A2：" + copyA2 + "，类型：" + copyA2.getClass()); } }

客户类在这里只依赖抽象原型类Prototype，它不知道ConcretePrototypeA构造时做了哪些准备工作，也不需要知道。这正是"对扩展开放"的落点——新增一种原型，只需要新增一个实现类，Client 一行不改。

2.3 Object.clone() 内部到底做了什么

克隆之所以比 new 便宜，秘密在于它跳过了构造器。虚拟机在克隆时做的动作大致是：按原对象的大小分配一块新内存，然后把原对象的字段逐个复制过去，整个过程不执行构造方法、不执行实例初始化块、不重跑字段的默认赋值。

这解释了为什么克隆能绕开"昂贵的构造过程"，也解释了后面所有坑的来源：如果构造器里做过某些登记性质的副作用（往缓存里写一份、把自己挂到监听器列表、生成一个唯一 ID），那么克隆出来的对象就完全没参与过这些流程——它存在于内存里，却不在系统的账本上。这类故障的表现非常玄学：对象明明打印得出、字段全对，就是"不生效"。

再看字段复制这一步。基本类型（int、long、boolean）复制的是值本身，彼此独立；引用类型复制的是引用，也就是地址。也就是说，克隆完成后，两个对象的引用字段指向堆上的同一块区域。这个行为有个正式名字，叫浅拷贝，它是Object.clone()的默认行为，也是一个必须由使用者自己决定要不要改的默认值。

还有一点常被忽略：clone()不区分字段是不是final，也不走任何访问控制，它复制的是内存布局，不是"你觉得该复制的那些字段"。所以一个类只要有一个可变引用字段，浅克隆就会把它带过来共享。

3. 浅克隆与深克隆：引用字段的两份内存到底怎么算

3.1 浅克隆：值类型复制一份，引用类型只抄地址

课件对浅克隆的定义很干脆：原型对象的成员变量是值类型时，复制一份给克隆对象；是引用类型时，把引用对象的地址复制一份，两个对象的成员变量指向同一块内存。

把这句话画成内存视图，大致是这样：

栈 堆 emailA ──▶ [ Email 实例 A ] sender → "aroma"（字符串常量池，共享） subject → "原型设计" attachment ─┐ ▼ emailB ──▶ [ Email 实例 B ] [ Attachment 实例 ] sender → "aroma" download() subject → "原型设计" （只有一份） attachment ─┘

两个 Email 实例是两块独立内存，这是x.clone() != x保证的；但attachment这个字段抄过去的是地址，两个箭头落到了同一个 Attachment 对象上。于是"修改克隆对象的附件"和"修改原对象的附件"其实是同一件事。

这个特性在某些场景下是优点——共享一份只读的大对象，省内存又省时间；在另一些场景下就是灾难。判断标准只有一条：这个引用字段会不会被改动。只读就共享，可写就必须断开。

3.2 深克隆：两条路线，手写递归和序列化

深克隆的要求是：无论值类型还是引用类型，都复制一份，克隆对象与原对象不共享任何子对象。常见实现思路有两条。

第一条是手工递归：每个引用字段都在 clone 里显式clone()一次，再 set 回新对象。

@Override public Email clone() throws CloneNotSupportedException { // 先让虚拟机复制本对象的字段（此时 attachment 仍是共享的） Email copy = (Email) super.clone(); // 再把引用字段单独克隆一份，挂到副本上 copy.attachment = (Attachment) this.attachment.clone(); return copy; }

第二条是序列化：把整个对象写进字节流，再从字节流读出来，读出来的那棵树天然与原对象没有任何引用关系。课件采用的是第二条，理由很实在——对象层级一深，手工递归的代码量和出错概率都是指数级上升的，而序列化只需要一行writeObject。

序列化的代价也很明确：参与序列化的每一个类（包括引用链上的所有子对象）都必须实现Serializable，任何一个环节不支持，整条链路立刻断掉；transient修饰的字段不会被写进流里，读回来就是默认值；静态字段本来就不属于对象实例，不参与；性能比手工克隆差一个数量级。

注意：Serializable和Cloneable一样是标记接口，区别在于前者由序列化机制在运行时检查，检查失败抛的是NotSerializableException，通常要等到运行到那一行才暴露。

3.3 循环引用：手写深克隆会栈溢出，序列化却不会

这是深克隆里最容易被忽视的一个分水岭。假设 A 引用 B，B 又反过来引用 A，手写递归的clone()会陷入 A.clone → B.clone → A.clone 的无限循环，最后抛StackOverflowError。

序列化不会掉进这个坑，因为ObjectOutputStream内部维护了一张引用表（handle table）：同一个对象在一次序列化过程中只会被写一次，第二次遇到时写的只是一个引用编号。反序列化时按编号还原，读出来的对象图里 A 和 B 的互相引用关系被原样保留，而且仍然是同一对实例。

这也顺带解释了为什么序列化深克隆有时反而"更正确"：它复制的是对象图的结构，不是一棵被手工展开的树。对象图里有共享节点（两个字段指向同一个子对象）时，序列化后这种共享关系依然存在；手工递归如果每个字段都 clone 一次，共享关系就被悄悄拆成了两份，语义已经变了。

4. 邮件复制案例：浅克隆的翻车点与序列化深克隆的完整链路

4.1 浅克隆版 Email：一行 super.clone() 埋下的共享

课件的场景很贴合真实需求：邮件对象字段多（发送者、接收者、标题、正文、日期、附件），构造一次成本不低，现在要基于已有邮件快速产出一封新邮件，只改其中几个字段。

public class Attachment { public void download() { System.out.println("下载附件"); } } public class Email implements Cloneable { private String sender; private String receiver; private String subject; private String body; private String date; private Attachment attachment; // 引用类型字段 public Email(String sender, String receiver, String subject, String body, String date, Attachment attachment) { this.sender = sender; this.receiver = receiver; this.subject = subject; this.body = body; this.date = date; this.attachment = attachment; } @Override public Email clone() throws CloneNotSupportedException { // 浅拷贝：attachment 字段只是把地址抄了一份，两个 Email 共享同一个附件 return (Email) super.clone(); } public void display() { System.out.println("发送者: " + sender + "，接收者：" + receiver + "，标题：" + subject + "，内容：" + body + "，日期：" + date + "，附件：" + attachment); } }

客户类的写法就是课件里的那段：

public class Client { public static void main(String[] args) throws Exception { Attachment attachment = new Attachment(); Email original = new Email("aroma", "kira", "原型设计", "邮件复制", "2025", attachment); Email cloned = original.clone(); // 改普通字段：String 是不可变对象，重新赋值只影响副本 cloned.setBody("浅克隆 - 邮件复制"); // 危险操作：把副本的附件换掉，实际改的是共享变量的指向 Attachment another = new Attachment(); cloned.setAttachment(another); original.display(); cloned.display(); } }

String字段之所以看起来"安全"，是因为字符串不可变，对副本重新赋值只是让副本的字段指向另一个常量，原对象完全不受影响。真正的坑在attachment：如果代码没有走setAttachment换新对象，而是调用cloned.getAttachment().download()或修改附件内部状态，改动会立刻反映到原邮件上。这就是 shallow clone 最典型的翻车现场——验证时只改了 String 字段，测试全绿，上线后附件互相污染。

4.2 深克隆版 Email：序列化链路的每一步

深克隆版本把两个类都改成Serializable，克隆方法换成流操作：

import java.io.*; public class Attachment implements Serializable { public void download() { System.out.println("下载附件"); } } public class Email implements Serializable { private static final long serialVersionUID = 1L; // 版本号，避免序列化后类结构变化导致读取失败 private String sender; private String receiver; private String subject; private String body; private String date; private Attachment attachment; // 省略构造方法与 getter/setter public Email deepClone() throws IOException, ClassNotFoundException { // 1. 内存字节数组作为中转，避免落盘 ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos); // 2. 把 this 以及它引用到的整张对象图写进流里 oos.writeObject(this); oos.close(); // 3. 从字节数组读回，得到一个全新对象图 ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bis); Email copy = (Email) ois.readObject(); ois.close(); return copy; } }

几个参数与步骤的用意值得逐条拆开：

ByteArrayOutputStream是内存缓冲区，用它代替FileOutputStream就不需要真的写磁盘，深克隆全程在堆内完成，速度比落盘快得多，也不会留下临时文件。

ObjectOutputStream.writeObject(this)是整条链路的核心。它不仅写当前对象，还会沿着引用关系递归写出所有可达子对象。这也意味着附件类必须实现Serializable，否则执行到这一行直接抛NotSerializableException。

bos.toByteArray()把缓冲区里的字节取出来，交给ByteArrayInputStream。这一步是必须的——ByteArrayOutputStream本身不支持读，必须重新包一个输入流。

ois.readObject()会调用类的无参构造吗？对于实现了Serializable的类，反序列化不走构造器，而是由虚拟机直接创建实例再灌字段。这一点和clone()绕过构造器是同一个性质，带来的坑也一模一样。

4.3 两版对比：什么时候浅克隆就够了

选型的判断点不是"深克隆更安全所以一律用深的"，而是这个引用字段会不会在副本生命周期里被改动。附加一个现实约束：如果对象图里混进了第三方库的类，而它没有实现Serializable，序列化路线就直接死了，这时候只能回到手工递归，或者干脆用拷贝构造器重新造一个。

5. 排查：原型模式最容易踩的五个坑

5.1 共享与异常：两个第一次就会撞上的问题

坑一：改了克隆对象的字段，原对象跟着变

现象：拿到克隆对象后调用getAttachment().download()或者修改附件内部属性，原邮件的附件同步变了，日志里两条记录的附件 ID 一模一样。

原因：super.clone()只做字段级的赋值，引用字段复制的是地址，两个对象指向同一个 Attachment 实例。如果只验证了 String 这类不可变字段，问题不会暴露，测试看起来一切正常。

解决：判断该字段是否可写。可写就实现深克隆；不想改类结构就加拷贝构造器，把引用字段也 new 一份。验证方法很简单，在克隆后打印original.getAttachment() == cloned.getAttachment()，返回 true 就说明还在共享。

坑二：明明实现了 Cloneable，还是抛 CloneNotSupportedException

现象：类声明里写了implements Cloneable，运行到clone()那行依然抛异常。

原因：异常不一定来自"没实现接口"。如果继承链中间某一层重写了clone()却没有调用super.clone()，或者显式throw new CloneNotSupportedException()，链就断在那里了。另一种情况是调用方通过一个没暴露 clone 的父类型引用来调用，编译器直接拒绝，报的是另一个错。

解决：沿着继承链逐层检查每一处clone()是否都调用了super.clone()。断链的典型形态是某个中间类"顺手"重写了一遍 clone 又忘了转发。补上一行super.clone()，整条链就通了。

5.2 构造器与性能：不报错但结果不对的那类问题

坑三：序列化深克隆之后，transient 字段变成了 null

现象：原对象里有个transient修饰的字段（比如一个锁对象或者缓存句柄），构造时初始化过，克隆出来却是 null，后续调用直接空指针。

原因：transient的语义就是"不参与序列化"，ObjectOutputStream写的时候会跳过它，读回来自然只有默认值。这不是 bug，是设计约定，但很容易在改造旧类时被忽略。

解决：如果这个字段必须随对象复制，就别用序列化这条路线，改成手工深克隆或在反序列化后重新初始化。常见做法是实现readObject私有方法，在流读完之后手动把 transient 字段补上。

坑四：克隆出来的对象"存在但不生效"

现象：对象字段全对，打印正常，但业务上就是不发挥作用——比如它没有被注册进缓存、没出现在监控列表里、事件监听不到。

原因：clone()和反序列化都不执行构造器。如果构造器里做过登记性质的副作用（把 this 塞进静态集合、生成全局唯一编号、绑定资源），克隆对象完全没参与过这些流程。这是原型模式最隐蔽的一类故障，排查时看代码完全合理。

解决：把这类副作用从构造器里抽出来，放进一个显式的init()或工厂方法，克隆完成后手动调用。或者反过来，接受"克隆对象不走初始化"，在设计上就不要依赖构造器副作用。

坑五：深克隆比 new 还慢，甚至直接栈溢出

现象：压测时发现克隆路径反而成了瓶颈，或者大对象图克隆时抛StackOverflowError。

原因：序列化要写字节流，涉及反射和流对象创建，对象图越大开销越明显，小对象上确实可能不如直接 new。栈溢出则出现在手工递归版本里，对象图存在循环引用时递归没有出口。

解决：先用简单基准测一下两条路径的耗时，别凭感觉选。循环引用的场景放弃手工递归，改用序列化（流内部有引用表能处理环）；对象图特别大且只需复制一层的，考虑拷贝构造器，把复制范围控制在必要字段上。

6. 设计取舍：Cloneable 这个空接口值不值得用

把整条链路走完，会发现原型模式真正的争议点不在"深浅克隆怎么选"，而在Cloneable这套机制本身。

它的优点很清晰：绕开构造器，创建成本低；运行时可动态替换具体类型，客户端只依赖抽象原型；对"大量相似对象、只改少量字段"的场景几乎是零成本的解。课件里那个邮件复制就是典型例子，构造一封邮件要拼六个字段外加附件装配，克隆只要一行。

它的代价同样清晰。空接口把类型检查推到了运行期，编译通过不等于能跑；clone()绕过构造器，一切依赖构造器副作用的逻辑都会失效；默认的浅拷贝语义与"复制"这个词给人的直觉不符，第一次用几乎必踩；深克隆要么递归写到吐，要么全链路Serializable。这几条叠在一起，就是为什么很多团队在代码规范里直接禁用clone()，改用拷贝构造器或静态工厂。

我的看法是分场景。对象结构稳定、字段少、复制频繁（比如游戏里的子弹、报表里的行、消息队列里的模板消息），原型模式非常合适，深克隆用手写递归比序列化更可控。对象图深、含第三方类、还要处理循环引用，那Cloneable基本可以放弃，老老实实写序列化工具或者映射式的对象拷贝。

从那以后，我每次给一个类加clone()，都会先强制走一遍三件事：打印==确认引用字段是否共享、检查继承链上每一层有没有转发super.clone()、确认构造器里没有登记类副作用。这三步花不了五分钟，但能挡掉上面五个坑里的四个。这份课件把角色结构、内存示意和两版邮件复制代码放在一处，对着看比零散搜代码更容易把这条链路一次串起来，想深挖的话，值得存一份在手边。希望帮到你。

本文还有配套的精品资源，点击获取