【總結】Effective java經歷之談，創立和銷毀對象

轉載請注明出處：http://blog.csdn.NET/supera_li/article/details/44940277

關於Effective Java 這本書，自己的一些總結性的考慮。篇幅能夠不依照目錄來，由於自己喜歡先看哪一章就直接閱讀了。不過能確定的是，每一章都會有總結。歡送大家拍磚與補充。

Effective java系列
1.Effective java經歷之談，創立和銷毀對象
2.Effective java經歷之談，泛型
3.Effective java經歷之談，類與接口
4.Effective java經歷之談，通用辦法
5.Effective java經歷之談，枚舉，注解，辦法，通用設計，異常
6.Effective java經歷之談，並發編程

1.  思索用靜態工廠的辦法替代結構器。優點：有名字，不用每次創立對象，前往任何子類型對象，簡約的代碼。缺陷：該類將不能被子類化（復合大於承繼，也是優點），不方便doc工具輸入文檔，普通商定的命名規則:

valueOf  轉換類型

getInstance 取得對象實例

newInstance 創立新的對象實例

getType 取得前往對象的類型

newType 置入前往對象的類型，在不同類中方便區別工廠辦法

2.   遇到多個結構器參數(4個以上)時要思索用構建器。堆疊結構器代碼冗長，前期不能無效的維護，javaBean形式的結構器在多線程下不平安，沒有到達類不可變性，緣由是暴顯露去了setter辦法。Builder形式的結構器是不錯的選擇。

       Class A{

  //屬性

   static class Bulid{

//屬性

Bulid(){//承受初始化參數 }

Bulid a(){ Return bulid; //添加參數前往Bulid發生調用鏈}

..

A bulid(){ return A(this);} //結構器對象初始化A對象前往

}

A(Bulid b){ //將b中參數傳遞給A參數域}

}

3.   用公有結構器或許枚舉類型強化Singleton屬性。關於公有結構器有2種方案，導出私有的靜態成員的實例與提供靜態工廠前往公有的靜態成員實例。但是並非平安的，采用AccessibleObject，經過反射技術可以調用公有的結構器，發生第二對象，處理方案是發生第二實例的時分拋出異常。使得Singleton序列化，(implementsSerializble)+(實例域transient)+(readResolve辦法前往實例)。單元素的枚舉類型是完成Singleton的最佳方案。

4.   經過公有結構器強化不可實例的才能。提供顯示的結構辦法比編譯器提供默許的好，特別是公有的結構器，並在公有的結構器中拋出AssertionError。由於這一技術的運用，使得該類無法被子類化。

5.   防止創立不用要的對象。思索的方向有，字符串類，static{}域，視圖view(Map中的set等)，自動裝箱拆箱，對象池object pool。

6.  消弭過時的對象援用。Stack.pop後，不運用的元素未置空惹起的內存洩露，磁盤交流，嚴重的狀況招致OOM異常。內存洩露另一個來源是緩存問題。假如key中不在堅持援用，那麼WeakHashMap自動肅清過時的key。假如隨著時間的增長，某些key能夠不必了，那麼采用LinkedHashMap。removeEldestEntry辦法將完成這一方案。第三個來源是監聽器和其他回調，采用堅持弱援用的辦法，即WeakHashMap的方案來處置。關於內存洩露的一個Heap分析工具Heap Profiler。

7.  防止運用終結辦法。Finalizer的辦法JVM並不一定執行，即便調用了System.gc。System.runFinalization。除非運用System.runFinalizersOnExit，Runtime.runFinalizersOnExit辦法(ThreadStop，不建議運用)。嘗試著運用try{}finally{}構造來顯示的調用終結辦法確保及時終止。假如子類掩蓋了超類的終結辦法，但是遺忘手工調用超類的終結辦法super.finalize，那麼超類的終結辦法將永遠也不會被調用。

假如將本章內容聯絡到實踐的編碼之中呢？我也停止的考慮，由於自己在類庫方面開發經歷很少，沒有通讀過jdk全部的源碼，所以有些建議不一定精確。

1.當你在創立類的時分，就該當想這個類將來要做什麼？是什麼類型？結構參數多嗎？適用經歷1,2,3,4

2.當你在編寫某段代碼的時分，你該當想到該對象能否可以反復應用？假如是集合類，那麼考慮，傳入的對象能否將來會不運用？假如覺得這段代碼或許辦法，以及觸及到該類在全局上隨著運轉會耗費較大的內存？那麼可以嘗試著運用5,6,7三個總結來處置這種問題。

畢竟下面都是一些辦法論，在理論進程中，需求自己有經歷的去判別如何做才是最優的（能夠是目前最優，亦或許將來效果很好），這些都是不同場景下發生的，並不一定會無效的去處理。