cloneable這個接口設計得十分奇葩，不符合正常人的使用習慣，然而用這個接口的人很多也很有必要，所以還是有必要了解一下這套扭曲的機制。以下內容來自于對effective java ed 2. item 11的整理。
cloneable接口
首先，cloneable接口中并沒有方法。它的存在意義一是讓程序員注明當前對象可以clone，二是改變父類object類中clone方法的行為：如果某個類實現了cloneable，那么它的父類object的clone方法可以調用，否則會拋出clonenotsupportedexception。(奇葩吧)
也就是說，如果我們要告訴用戶，這個類是可以clone的，并且在我們的實現中需要調用super.clone，那么我們就必須實現cloneable。
（然而，即使某個類實現了cloneable，也不一定保證它就有clone方法，這是這個接口設計的奇葩之處之一，設計者可能是反社會吧）
我們的clone方法
需要重寫clone方法的情況分為兩類。
1：需要實現cloneable接口。
2：只需要重寫clone方法。
其中，第一種情況比較普遍。第二種可以看作為了討論的完整性對第一種進行的補充。
需要實現cloneable接口
考慮到clone方法是直接給用戶用的，建議做到以下幾點：
將限制符改為public；
將它的返回類型設置成子類類型（可以這么做是因為java允許covariant return type）；
接住clonenotsupportedexception并不再拋出（既然已經實現了cloneable接口，就不會拋出這個異常，不然用戶又要在
那里try-catch半天）。
|
1
2
3
4
5
6
7
8
|
@overridepublic phonenumber clone() throws ... { try { return (phonenumber) super.clone(); } catch(clonenotsupportedexception e) { throw new assertionerror(); // can't happen }} |
注意，這里給出的是clone方法的大體寫法，包括函數簽名等，先讓你有一個大略的方向。當我們按照以上三條搭好clone方法的框框后，具體如何去實現克隆的過程，下一節會舉例詳述。
注：如果當前類是final的，可以直接使用構造器來構造對象。（如果不是final的，那么可能還會有子類，子類再調用super.clone的時候就只能返回父類類型對象，就不太合適了，所以只有final類適合用構造器）
只需要重寫clone方法
這個類可能是繼承鏈上的一個中間類。此時該clone方法最好模擬object.clone的行為，即：
限制符為protected；
不實現cloneable；
拋出clonenotsupportedexception。
不同情景下的clone方法實現
首先，應熟悉object.clone的行為（因為在我們自己的類中經常會調用super.clone，最終調用object.clone）：淺拷貝。即：先創建一個新對象，然后將它的所有域初始化為待拷貝對象的域的對應值。
另外，所有數組都會實現cloneable接口，t[].clone的返回類型也為t[]，行為與object類似。（這是一個好用的feature，實現淺拷貝時會經常用到）
官方文檔對clone的實現建議是：先調用super.clone創建對象；如果對象的域都是基本類型，則一切搞定；否則，如果對象是可變對象，則要將組成對象的"deep structure"的對象全部復制，然后將復制品的域引用指向這些復制后的對象。
上一節給出的phonenumber的clone屬于前者（對象域為電話號碼、區號等，為基本類型short），所以調用super.clone再加一個cast就可以搞定。
注意這個藍色的deep structure，指明了clone方法實現的精髓。以下舉兩個例子，讀者可細細品味。
案例一：stack
|
1
2
3
4
5
6
7
8
9
|
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數組獨立克隆：
|
1
2
3
4
5
6
7
8
9
|
@override public stack clone() { try { stack result = (stack) super.clone(); result.elements = elements.clone(); return result; } catch (clonenotsupportedexception e) { throw new assertionerror(); }} |
兩種方法的區別如下：（渣圖……）
第一種方法對應左圖，由于克隆后的對象的elements指向原對象中的數組，當原對象增刪元素時，克隆后的對象的backing array也跟著自動變化。第二種方法對應右圖，克隆后對象的數組和原對象的數組是互相獨立的，當原對象增刪元素時，克隆后的對象可以不受影響，因為它還保持原有的那些引用。雖然兩種都是淺拷貝，但只有第二種符合不變性。而且第二種是容器類的一種常用做法，如arraylist的copy constructor。
案例二：hashtable
在stack的基礎上再復雜一點，我們研究一個hashtable:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
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的克隆方法，是否會有效呢？
|
1
2
3
4
5
6
7
8
9
|
@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對象頭尾相接的鏈表。克隆后entry元素們還指向同樣的對象，此時如果原table增刪了元素，其實質是它將某些entry指向了新entry或指向null；由于克隆后的table與克隆前的table共享一套entry對象，所以它的內部結構發生了同樣的改變，但它并不知道自己發生了改變，這樣就出現了奇怪的現象，比如說克隆后的table的size明明沒變，卻憑空多出/消失了一些元素。
|
1
2
3
4
5
6
7
|
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做深拷貝。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
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.
|
1
2
3
4
5
6
7
|
//iteratively copy the linked list headed by this entryentry 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方法不應調用克隆后對象的nonfinal方法。若該類的子類重寫了這個nonfinal方法，該方法有可能在子類創建完畢之前去調用它的一些方法/數據，可能會引起數據損壞。
如果類中有一個指向可變對象的final域，則以上的clone實現機制無法work，因為對象創建好以后無法再給final域assign一個值。
不可變類不應該支持clone，因為clone后的對象跟原對象沒有區別。
其實一種比較好的方法是copy constructor或copy factory。它們沒有cloneable的那些奇葩性，不拋異常，而且可以搞定final域。
|
1
2
|
public yum(yum yum); //copy constructorpublic static yum newinstance(yum yum); //copy factory |
一個更好的好處是，interface-based copy constructor或copy factory (稱為conversion constructors / conversion factories)可以允許用戶選擇與原對象不同類的克隆對象。如
|
1
2
|
hashset s = ...;new treeset(s); //將hashset轉換成treeset |
總結
以上所述是小編給大家介紹的java中clone的寫法，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對服務器之家網站的支持！
原文鏈接：https://www.cnblogs.com/mozi-song/p/9373210.html
