Cloneable這個接口設計得十分奇葩，不符合正常人的使用習慣，然而用這個接口的人很多也很有必要，所以還是有必要了解一下這套扭曲的機制。以下內(nèi)容來自于對Effective Java ed 2. item 11的整理。

 Cloneable接口

首先，Cloneable接口中并沒有方法。它的存在意義一是讓程序員注明當前對象可以clone，二是改變父類Object類中clone方法的行為：如果某個類實現(xiàn)了Cloneable，那么它的父類Object的clone方法可以調(diào)用，否則會拋出CloneNotSupportedException。(奇葩吧)

也就是說，如果我們要告訴用戶，這個類是可以clone的，并且在我們的實現(xiàn)中需要調(diào)用super.clone，那么我們就必須實現(xiàn)Cloneable。

（然而，即使某個類實現(xiàn)了Cloneable，也不一定保證它就有clone方法，這是這個接口設計的奇葩之處之一，設計者可能是反社會吧） 

我們的clone方法

需要重寫clone方法的情況分為兩類。

　　　　1：需要實現(xiàn)Cloneable接口。

　　　　2：只需要重寫clone方法。

其中，第一種情況比較普遍。第二種可以看作為了討論的完整性對第一種進行的補充。

需要實現(xiàn)Cloneable接口

考慮到clone方法是直接給用戶用的，建議做到以下幾點：

將限制符改為public；

將它的返回類型設置成子類類型（可以這么做是因為java允許covariant return type）；

接住CloneNotSupportedException并不再拋出（既然已經(jīng)實現(xiàn)了Cloneable接口，就不會拋出這個異常，不然用戶又要在

那里try-catch半天）。

@Override
public PhoneNumber clone() throws ... {
  try {
   return (PhoneNumber) super.clone();
  } catch(CloneNotSupportedException e) {
   throw new AssertionError(); // Can't happen
  }
}

注意，這里給出的是clone方法的大體寫法，包括函數(shù)簽名等，先讓你有一個大略的方向。當我們按照以上三條搭好clone方法的框框后，具體如何去實現(xiàn)克隆的過程，下一節(jié)會舉例詳述。

注：如果當前類是final的，可以直接使用構造器來構造對象。（如果不是final的，那么可能還會有子類，子類再調(diào)用super.clone的時候就只能返回父類類型對象，就不太合適了，所以只有final類適合用構造器）

只需要重寫clone方法

這個類可能是繼承鏈上的一個中間類。此時該clone方法最好模擬Object.clone的行為，即：

限制符為protected；

不實現(xiàn)Cloneable；

拋出CloneNotSupportedException。

不同情景下的clone方法實現(xiàn)

首先，應熟悉Object.clone的行為（因為在我們自己的類中經(jīng)常會調(diào)用super.clone，最終調(diào)用Object.clone）：淺拷貝。即：先創(chuàng)建一個新對象，然后將它的所有域初始化為待拷貝對象的域的對應值。

另外，所有數(shù)組都會實現(xiàn)Cloneable接口，T[].clone的返回類型也為T[]，行為與Object類似。（這是一個好用的feature，實現(xiàn)淺拷貝時會經(jīng)常用到）

官方文檔對clone的實現(xiàn)建議是：先調(diào)用super.clone創(chuàng)建對象；如果對象的域都是基本類型，則一切搞定；否則，如果對象是可變對象，則要將組成對象的"deep structure"的對象全部復制，然后將復制品的域引用指向這些復制后的對象。 

上一節(jié)給出的PhoneNumber的clone屬于前者（對象域為電話號碼、區(qū)號等，為基本類型short），所以調(diào)用super.clone再加一個cast就可以搞定。

注意這個藍色的deep structure，指明了clone方法實現(xiàn)的精髓。以下舉兩個例子，讀者可細細品味。

案例一：Stack

public class Stack {
 private Object[] elements;
 private int size = 0;
 private static final int DEFAULT_INITIAL_CAPACITY = 16;
 public Stack() {...}
 public void push(Object e) {...}
 public Object pop() {...}
 private void ensureCapacity() {...} //omitted for simplicity
}

如果在Stack的clone方法中，也簡單地返回super.clone，會有一個嚴重的后果，就是在原對象中如果增刪了元素，在復制對象中的size不變，但是實際上元素被增刪了，違反了復制對象的invariant。

解決辦法是將elements數(shù)組獨立克隆：

@Override public Stack clone() {
 try {
  Stack result = (Stack) super.clone();
  result.elements = elements.clone();
  return result;
 } catch (CloneNotSupportedException e) {
  throw new AssertionError();
 }
}

兩種方法的區(qū)別如下：（渣圖……）

第一種方法對應左圖，由于克隆后的對象的elements指向原對象中的數(shù)組，當原對象增刪元素時，克隆后的對象的backing array也跟著自動變化。第二種方法對應右圖，克隆后對象的數(shù)組和原對象的數(shù)組是互相獨立的，當原對象增刪元素時，克隆后的對象可以不受影響，因為它還保持原有的那些引用。雖然兩種都是淺拷貝，但只有第二種符合不變性。而且第二種是容器類的一種常用做法，如ArrayList的copy constructor。

案例二：HashTable

在Stack的基礎上再復雜一點，我們研究一個HashTable:

public class HashTable implements Cloneable {
  private Entry[] buckets = ...;
  private static class Entry {
   final Object key;
   Object value;
   Entry next;
   Entry(Object key, Object value, Entry next) {
     this.key = key;
     this.value = value;
     this.next = next;
   }
  }
  ... // Remainder omitted
}

如果我們照搬Stack的克隆方法，是否會有效呢？

@Override public HashTable clone() {
  try {
   HashTable result = (HashTable) super.clone();
   result.buckets = buckets.clone();
   return result;
  } catch (CloneNotSupportedException e) {
   throw new AssertionError();
  }
}

克隆后的HashTable有自己的array了，看起來好像沒什么問題了。然而，HashTable使用的是Entry對象頭尾相接的鏈表?？寺『驟ntry元素們還指向同樣的對象，此時如果原table增刪了元素，其實質(zhì)是它將某些Entry指向了新Entry或指向null；由于克隆后的table與克隆前的table共享一套Entry對象，所以它的內(nèi)部結構發(fā)生了同樣的改變，但它并不知道自己發(fā)生了改變，這樣就出現(xiàn)了奇怪的現(xiàn)象，比如說克隆后的table的size明明沒變，卻憑空多出/消失了一些元素。

HashTable original = new HashTable();
original.put(x, y);
HashTable cloned = original.clone();
original.remove(x); //cloned gets removed by one element too, but does not know of it!!
if(cloned.size() > 0){
  doSomething(); //Danger! It's actually empty!!  
}

如圖：

解決方法是將其中value的容器Entry做深拷貝。

public class HashTable implements Cloneable {
  private Entry[] buckets = ...;
  private static class Entry {
   final Object key;
   Object value;
   Entry next;
   Entry(Object key, Object value, Entry next) {
   this.key = key;
   this.value = value;
   this.next = next;
   // Recursively copy the linked list headed by this Entry
   Entry deepCopy() {
     return new Entry(key, value, next == null ? null : next.deepCopy());
   }  
 }
  @Override public HashTable clone() {
   try {
     HashTable result = (HashTable) super.clone();
     result.buckets = new Entry[buckets.length];
     for (int i = 0; i < buckets.length; i++)
      if (buckets[i] != null)
       result.buckets[i] = buckets[i].deepCopy();
     return result;
   } catch (CloneNotSupportedException e) {
     throw new AssertionError();
   }
  }
  ... // Remainder omitted
}

注：value指向的Object仍然沒變，所以這種方法只是在一定程度上做深拷貝。由于HashTable直接操作的是Entry，將Entry這一層深拷貝即可。

由于上述deepCopy()方法容易引起stack overflow，作者建議使用iteration代替recursion.

//Iteratively copy the linked list headed by this Entry
Entry deepCopy() {
  Entry result = new Entry(key, value, next);
  for (Entry p = result; p.next != null; p = p.next)
   p.next = new Entry(p.next.key, p.next.value, p.next.next);
  return result;
}

其他碎碎念

（非final類的）clone方法不應調(diào)用克隆后對象的nonfinal方法。若該類的子類重寫了這個nonfinal方法，該方法有可能在子類創(chuàng)建完畢之前去調(diào)用它的一些方法/數(shù)據(jù)，可能會引起數(shù)據(jù)損壞。

如果類中有一個指向可變對象的final域，則以上的clone實現(xiàn)機制無法work，因為對象創(chuàng)建好以后無法再給final域assign一個值。

不可變類不應該支持clone，因為clone后的對象跟原對象沒有區(qū)別。
其實一種比較好的方法是copy constructor或copy factory。它們沒有Cloneable的那些奇葩性，不拋異常，而且可以搞定final域。

public Yum(Yum yum); //copy constructor
public static Yum newInstance(Yum yum); //copy factory

一個更好的好處是，interface-based copy constructor或copy factory (稱為conversion constructors / conversion factories)可以允許用戶選擇與原對象不同類的克隆對象。如

HashSet s = ...;
new TreeSet(s); //將HashSet轉換成TreeSet

總結

 以上所述是小編給大家介紹的Java中clone的寫法，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

最新評論