Java中对象克隆的行为

Question

我正在学习Java，因为我需要它作为我大学课程的必修课。我有C++背景，所以理解OOP背后的逻辑并不是特别困难。但这两种语言之间有几个不同之处，其中一个我无法理解的是Java中存在的对象克隆特性。这个问题让我想起了C++的复制构造函数，但其含义是不同的。

在Java语言中，没有析构函数，内存由垃圾收集器管理，因此不存在您在C++中遇到的堆内存问题。这个问题仅限于共享变量。

现在，仔细阅读，我发现对象克隆(与复制构造函数不同)不是OOP语言应该提供的特性，因为它创建了跳过构造阶段的对象的另一个实例。此外，clone()无法正确操作final字段，并跳过初始化块。克隆背后的相同逻辑是“错误的”，因为" Cloneable“就像一个空接口，只是为了在Object.clone()中进行类型检查，以便在对象的类型不可克隆时引发异常。

所有的克隆机制似乎都依赖于Object.clone()方法，它可以正确地分配内存。支持clone()的类层次结构中的每个子类型都应该调用"super.clone()“，直到对象1被调用来分配所有必要的字段。但是，如果实现Cloneable接口的子类型扩展了一个没有这样做的超类型，会发生什么呢？我从"Arnold，Gosling，Holmes“中学习，对clone的定义行为之一是：”允许子类支持clone，但不公开支持它。这样的类不实现Cloneable，但如果clone的默认实现不正确，该类将提供一个受保护的克隆实现，正确地克隆它的字段“。这样，通过调用super.clone()，最终我们将遇到超类的protected clone()方法，但这种方法不能依赖于Object.clone()，因为超类本身并不实现Cloneable。使用new运算符将是一个错误，因为将创建一个超类的实例，其中包含一些缺少的字段。

那么，在一个不可克隆的类中支持clone() (使用一个受保护的方法)真的有用吗？如何解决具有不可克隆超类型的可克隆子类型的问题？

Answer 1

但是，如果实现Cloneable接口的子类型扩展了一个没有这样做的超类型，会发生什么呢？

如果它只是implements Cloneable而不实际覆盖clone() (是的，这也是可能的！)，那么没有什么坏处。

如果它覆盖了clone()并返回了一个不是从super.clone()中检索到的实例，那么它就破坏了它的所有子类。这是clone()公认的陷阱之一(在Effective中有介绍)。

如何解决具有不可克隆超类型的可克隆子类型的问题？

如上所述，只要不可克隆的超类型不覆盖clone()，这就不是问题(是的，这是另一种可能性！)或者确实覆盖它，但以一种顺从的方式。

Answer 2

如何解决可克隆的子类型和不可克隆的超级类型的问题？

实际上，这不是问题。想想Object类:这是一种不可克隆的类型，可用作任何Cloneable类型的超类型。您可以创建任何类型T的克隆子类型。唯一重要的是:为该类型T(及其超级类型)正确实现的“Cloneable”操作。对于类Object，这将返回原始对象的字段方式的浅表副本，具有与原始对象相同的类。

即，不是子类的超类线程中的每个类型都必须实现Cloneable。

...在一个不可克隆的类中支持clone() (使用一个受保护的方法)真的有用吗？

是。例如，请参阅(不可克隆的)类Object中clone()的默认实现。