测试原型继承性能需对比相同结构下new与clone的耗时差异，分浅克隆（super.clone()，引用共享）和深克隆（序列化或手动实现），并结合业务场景如配置初始化、游戏对象池、报表生成做端到端压测。
测试原型继承模式的性能，关键不是测“继承关系是否成立”，而是验证克隆动作本身在对象创建阶段带来的实际开销差异。重点看两点：克隆比 new 快多少，以及浅克隆和深克隆的耗时差距有多大。
明确对比基线：new vs clone
必须在同一对象结构下，用相同初始化逻辑分别走构造函数创建和克隆创建，再统计耗时。不能拿一个空对象的 new 去比一个带 10 层嵌套的 clone —— 这样没意义。
- 准备一个典型具体原型类（比如含 String、Date、List
、自定义子对象等） - 先 new 1000 次，记录总耗时（含构造、属性赋值、集合初始化等全部操作）
- 再以该实例为原型，clone 1000 次，同样记录总耗时
- 重复 5 轮取平均值，排除 JIT 预热干扰
区分浅克隆与深克隆的实测路径
浅克隆通常快一个数量级，但容易掩盖引用共享问题；深克隆稳定但成本高。测试时要分开跑，并检查结果一致性：
- 浅克隆：直接 super.clone()，之后 assert 克隆体与原对象的引用类型字段 ==（内存地址相同）
- 深克隆（序列化方式）：用 ByteArrayOutputStream + ObjectOutputStream 流式克隆，注意类必须实现 Serializable，且 transient 字段不会被复制
- 深克隆（手动方式）：对每个引用字段显式调用其 clone() 或 new 构造，适合可控结构，但易漏字段
关注真实瓶颈点
性能短板往往不在 clone() 方法本身，而在配套操作上：
- 如果用了序列化深克隆，I/O 流创建、字节数组分配、反序列化解析都会拉高耗时 —— 建议用 JMH 做微基准测试，隔离 GC 影响
- 若原型对象里有懒加载字段或代理对象（如 Hibernate 的 LazyCollection），clone 可能触发意外初始化，导致耗时突增
- 多线程并发 clone 时，注意 Date、SimpleDateFormat 等非线程安全对象是否被共享修改
加一层业务场景压测
脱离使用场景的毫秒级差异意义有限。建议结合典型用途做端到端验证：
- 配置对象克隆：启动时加载一份全局 Config，然后 100 个模块各 clone 一次并微调 logLevel，测整体初始化时间
- 游戏对象池：预热 50 个 Sheep 原型，再每帧 clone 20 个用于渲染，观察 FPS 是否稳定
- 报表模板生成：克隆带样式、页眉页脚的 Report 原型 1000 次，填入不同数据后导出 PDF，测吞吐量
