不存储首个对象深拷贝的前提下能否判定后续对象与其相等？

一、是否可以不用存储x的深拷贝实现需求 #

存在可以满足绝大多数场景业务逻辑的实现方案，但不存在100%理论严谨、通用所有对象类型的零副本等价方案。
可行的实现方案包括：

• 加密摘要方案：在FooClass实例中存储首次传入对象的全状态加密哈希值（比如SHA-256），不需要存储完整对象。后续调用foo时重新计算当前传入对象的加密哈希，和存储的哈希值对比即可。这种方案的碰撞概率极低，工程应用中完全可以等价于深拷贝后的equals对比效果。
• 普通哈希方案：存储对象重写后的hashCode，开销更低，但32位哈希的碰撞概率较高，只能用于对准确性要求不高的场景。
• 版本戳方案：如果处理的是带内置修改版本标记的业务对象，可以直接存储首次对象的版本号，后续对比版本号即可，这种方案只适用于特定业务场景，不通用。
• 不可变对象直接存引用：如果传入的是String、Integer这类不可变类型，不需要深拷贝，直接存储引用即可，对比时直接调用equals就符合需求。

所有不存深拷贝的方案都存在理论上的非绝对严谨性：哈希方案存在概率性碰撞的可能，版本戳方案依赖业务层的约定，都不能完全100%等价于深拷贝后equals对比的严谨性，只是在绝大多数场景下可以满足需求。

二、时间开销和深拷贝方案的差异 #

所有无深拷贝方案的综合开销都显著低于深拷贝方案，具体差异如下：

• 深拷贝的开销：时间和内存开销都是O(n)，n为对象图的总节点数。需要遍历整个对象图为每个节点申请新内存、复制属性，还要额外处理循环引用、不可序列化属性等异常场景，常数项极高，大对象场景下会占用大量内存。
• 哈希类方案的开销：时间开销同样为O(n)，但常数项远低于深拷贝，因为只需要遍历对象图读取属性做哈希计算，不需要申请额外内存存储副本。内存开销固定为哈希值的大小（比如SHA-256仅占32字节），和原对象大小无关，大对象场景下内存优势极其明显。如果对象内置了预计算的hashCode，时间开销可以降到O(1)。
• 版本戳方案的开销：时间和内存开销都是O(1)，和原对象大小无关，比深拷贝方案低几个数量级。

如果对象存在循环引用、不可序列化属性，深拷贝可能直接失败，而哈希类方案只需要增加已访问节点标记即可正常运行，稳定性更高。

内容的提问来源于stack exchange，提问作者user10264746