java clone學習總結

由於Java中的所有東西都是控制代碼，而且由於每個對象都是在記憶體堆中建立的——只有不再需要的時候，才會當作垃圾收集掉，所以對象的操作方式發生了變化，特別是在傳遞和返回對象的時候。舉個例子來說，在C和C++中，如果想在一個方法裡初始化一些儲存空間，可能需要請求使用者將那片儲存地區的地址傳遞進入方法。否則就必須考慮由誰負責清除那片地區。因此，這些方法的介面和對它們的理解就顯得要複雜一些。但在Java中，根本不必關心由誰負責清除，也不必關心在需要一個對象的時候它是否仍然存在。因為系統會為我們照料一切。我們的程式可在需要的時候建立一個對象。而且更進一步地，根本不必擔心那個對象的傳輸機制的細節：只需簡單地傳遞控制代碼即可。有些時候，這種簡化非常有價值，但另一些時候卻顯得有些多餘。
可從兩個方面認識這一機制的缺點：
(1) 肯定要為額外的記憶體管理付出效率上的損失（儘管損失不大），而且對於運行所需的時間，總是存在一絲不確定的因素（因為在記憶體不夠時，垃圾收集器可能會被強制採取行動）。對大多數應用來說，優點顯得比缺點重要，而且部分對時間要求非常苛刻的段落可以用native方法寫成（參見附錄A）。
(2) 別名處理：有時會不慎獲得指向同一個對象的兩個控制代碼。只有在這兩個控制代碼都假定指向一個“明確”的對象時，才有可能產生問題。對這個問題，必須加以足夠的重視。而且應該儘可能地“複製”一個對象，以防止另一個控制代碼被不希望的改動影響。除此以外，可考慮建立“不可變”對象，使它的操作能返回同種類型或不同種類型的一個新對象，從而提高程式的執行效率。但千萬不要改變原始對象，使對那個對象別名的其他任何方面都感覺不出變化。

有些人認為Java的複製是一個笨拙的傢伙，所以他們實現了自己的複製方案（注釋⑤），永遠杜絕調用Object.clone()方法，從而消除了實現Cloneable和捕獲CloneNotSupportException違例的需要。這一做法是合理的，而且由於clone()在Java標準庫中很少得以支援，所以這顯然也是一種“安全”的方法。只要不調用Object.clone()，就不必實現Cloneable或者捕獲違例，所以那看起來也是能夠接受的。

⑤：Doug Lea特別重視這個問題，並把這個方法推薦給了我，他說只需為每個類都建立一個名為duplicate()的函數即可。

Java中一個有趣的關鍵字是byvalue（按值），它屬於那些“保留但未實現”的關鍵字之一。在理解了別名和複製問題以後，大家可以想象byvalue最終有一天會在Java中用於實現一種自動化的本機複本。這樣做可以解決更多複雜的複製問題，並使這種情況下的編寫的代碼變得更加簡單和健壯。