一、考慮用靜態工廠方法代替構造器：
?? ?
?? ?? 構造器是創建一個對象實例最基本也最通用的方法，大部分開發者在使用某個class的時候，首先需要考慮的就是如何構造和初始化一個對象示例，而構造的方式首先考慮到的就是通過構造函數來完成，因此在看javadoc中的文檔時首先關注的函數也是構造器。然而在有些時候構造器并非我們唯一的選擇，通過反射也是可以輕松達到的。我們這里主要提到的方式是通過靜態類工廠的方式來創建class的實例，如：
1
public
static
Boolean valueOf(
boolean
b) {
2
return
b ? Boolean.TRUE : Boolean.FALSE;
3
}
? ? ? 靜態工廠方法和構造器不同有以下主要優勢：
? ? ? 1.?? ?有意義的名稱。
?? ?? 在框架設計中，針對某些工具類通常會考慮dummy對象或者空對象以辨別該對象是否已經被初始化，如我曾在我的C++基礎庫中實現了String類型，見如下代碼：
? ? ? 在上面的代碼中，提供了兩個靜態工廠方法empty和preallocate用于分別創建一個空對象和一個帶有指定分配空間的String對象。從使用方式來看，這些靜態方法確實提供了有意義的名稱，使用者很容易就可以判斷出它們的作用和應用場景，而不必在一組重載的構造器中去搜尋每一個構造函數及其參數列表，以找出適合當前場景的構造函數。從效率方面來講，由于提供了唯一的靜態空對象，當判讀對象實例是否為空時(isEmpty)，直接使用預制靜態空對象(emptyString)的地址與當前對象進行比較，如果是同一地址，即可確認當前實例為空對象了。對于preallocate函數，顧名思義，該函數預分配了指定大小的內存空間，后面在使用該String實例時，不必擔心賦值或追加的字符過多而導致頻繁的realloc等操作。???
?
? ? ? 2.?? ?不必在每次調用它們的時候創建一個新的對象。
? ? ? 還是基于上面的代碼實例，由于所有的空對象都共享同一個靜態空對象，這樣也節省了更多的內存開銷，如果是strEmpty2方式構造出的空對象，在執行比較等操作時會帶來更多的效率開銷。事實上，Java在String對象的實現中，使用了常量資源池也是基于了同樣的優化策略。該優勢同樣適用于單實例模式。?
?
? ? ? 3.?? ?可以返回原返回類型的任何子類型。
? ? ? 在Java Collections Framework的集合接口中，提供了大量的靜態方法返回集合接口類型的實現類型，如Collections.subList()、Collections.unmodifiableList()等。返回的接口是明確的，然而針對具體的實現類，函數的使用者并不也無需知曉。這樣不僅極大的減少了導出類的數量，而且在今后如果發現某個子類的實現效率較低或者發現更好的數據結構和算法來替換當前實現子類時，對于集合接口的使用者來說，不會帶來任何的影響。本書在例子中提到EnumSet是通過靜態工廠方法返回對象實例的，沒有提供任何構造函數，其內部在返回實現類時做了一個優化，即如果枚舉的數量小于64，該工廠方法將返回一個經過特殊優化的實現類實例(RegularEnumSet)，其內部使用long(64bits在Java中) 中的不同位來表示不同的枚舉值。如果枚舉的數量大于64，將使用long的數組作為底層支撐。然而這些內部實現類的優化對于使用者來說是透明的。
?
? ? ? 4.?? ?在創建參數化類型實例的時候，它們使代碼變得更加簡潔。
? ? ? Map<String,String> m = new HashMap<String,String>();
?? ?? 由于Java在構造函數的調用中無法進行類型的推演，因此也就無法通過構造器的參數類型來實例化指定類型參數的實例化對象。然而通過靜態工廠方法則可以利用參數類型推演的優勢，避免了類型參數在一次聲明中被多次重寫所帶來的煩憂，見如下代碼：
?? ?? public static <K,V> HashMap<K,V> newInstance() {
?? ?? ??? return new HashMap<K,V>();
? ? ? }
?? ?? Map<String,String> m = MyHashMap.newInstance();
???
?
二、遇到多個構造參數時要考慮用構建器(Builder模式)：
?? ?
? ? ? 如果一個class在構造初始化的時候存在非常多的參數，將會導致構造函數或者靜態工廠函數帶有大量的、類型相同的函數參數，特別是當一部分參數只是可選參數的時候，class的使用者不得不為這些可選參數也傳入缺省值，有的時候會發現使用者傳入的缺省值可能是有意義的，而并非class內部實現所認可的缺省值，比如某個整型可選參數，通常使用者會傳入0，然后class內部的實現恰恰認為0是一種重要的狀態，而該狀態并不是該調用者關心的，但是該狀態卻間接導致其他狀態的改變，因而帶來了一些潛在的狀態不一致問題。與此同時，過多的函數參數也給使用者的學習和使用帶來很多不必要的麻煩，我相信任何使用者都希望看到class的接口是簡單易用、函數功能清晰可見的。在Effective C++中針對接口的設計有這樣的一句話："接口要完滿而最小化"。針對該類問題通常會考慮的方法是將所有的參數歸結到一個JavaBean對象中，實例化這個Bean對象，然后再將實例化的結果傳給這個class的構造函數，這種方法仍然沒有避免缺省值的問題。該條目推薦了Builder模式來創建這個帶有很多可選參數的實例對象。
? ? ? 對于Builder方式，可選參數的缺省值問題也將不再困擾著所有的使用者。這種方式還帶來了一個間接的好處是，不可變對象的初始化以及參數合法性的驗證等工作在構造函數中原子性的完成了。
三、用私有構造器或者枚舉類型強化Singleton屬性：
? ? ? 對于單實例模式，相信很多開發者并不陌生，然而如何更好更安全的創建單實例對象還是需要一些推敲和斟酌的，在Java中主要的創建方式有以下三種，我們分別作出解釋和適當的比較。
?? ?? 1.?? ?將構造函數私有化，直接通過靜態公有的final域字段獲取單實例對象：
1
public
class
Elvis {
2
public
static
final
Elvis INSTANCE =
new
Elvis();
3
private
Elivs() { ... }
4
public
void
leaveTheBuilding() { ... }
5
}
? ? ? 這樣的方式主要優勢在于簡潔高效，使用者很快就能判定當前類為單實例類，在調用時直接操作Elivs.INSTANCE即可，由于沒有函數的調用，因此效率也非常高效。然而事物是具有一定的雙面性的，這種設計方式在一個方向上走的過于極端了，因此他的缺點也會是非常明顯的。如果今后Elvis的使用代碼被遷移到多線程的應用環境下了，系統希望能夠做到每個線程使用同一個Elvis實例，不同線程之間則使用不同的對象實例。那么這種創建方式將無法實現該需求，因此需要修改接口以及接口的調用者代碼，這樣就帶來了更高的修改成本。
?? ?? 2.?? ?通過公有域成員的方式返回單實例對象：
1
public
class
Elvis {
2
public
static
final
Elvis INSTANCE =
new
Elvis();
3
private
Elivs() { ... }
4
public
static
Elvis getInstance() {
return
INSTANCE; }
5
public
void
leaveTheBuilding() { ... }
6
}
?? ?? 這種方法很好的彌補了第一種方式的缺陷，如果今后需要適應多線程環境的對象創建邏輯，僅需要修改Elvis的getInstance()方法內部即可，對用調用者而言則是不變的，這樣便極大的縮小了影響的范圍。至于效率問題，現今的JVM針對該種函數都做了很好的內聯優化，因此不會產生因函數頻繁調用而帶來的開銷。
? ? ? 3.?? ?使用枚舉的方式(Java SE5):
1
public
enum
Elvis {
2
INSTANCE;
3
public
void
leaveTheBuilding() { ... }
4
}
? ? ? 就目前而言，這種方法在功能上和公有域方式相近，但是他更加簡潔更加清晰，擴展性更強也更加安全。
? ? ? 我在設計自己的表達式解析器時，曾將所有的操作符設計為enum中不同的枚舉元素，同時提供了帶有參數的構造函數，傳入他們的優先級、操作符名稱等信息。
四、通過私有構造器強化不可實例化的能力：
? ? ? 對于有些工具類如java.lang.Math、java.util.Arrays等，其中只是包含了靜態方法和靜態域字段，因此對這樣的class實例化就顯得沒有任何意義了。然而在實際的使用中，如果不加任何特殊的處理，這樣的classes是可以像其他classes一樣被實例化的。這里介紹了一種方式，既將缺省構造函數設置為private，這樣類的外部將無法實例化該類，與此同時，在這個私有的構造函數的實現中直接拋出異常，從而也避免了類的內部方法調用該構造函數。
1
public
class
UtilityClass {
2
//
Suppress default constructor for noninstantiability.
3
private
UtilityClass() {
4
throw
new
AssertionError();
5
}
6
}
? ? ? 這樣定義之后，該類將不會再被外部實例化了，否則會產生編譯錯誤。然而這樣的定義帶來的最直接的負面影響是該類將不能再被子類化。
?? ?
五、避免創建不必要的對象：
?? ?? 試比較以下兩行代碼在被多次反復執行時的效率差異：
?? ?? String s = new String("stringette");
?
?
? ? String s = "stringette";
? ? ? 由于String被實現為不可變對象，JVM底層將其實現為常量池，既所有值等于"stringette" 的String對象實例共享同一對象地址，而且還可以保證，對于所有在同一JVM中運行的代碼，只要他們包含相同的字符串字面常量，該對象就會被重用。
?? ?
? ? ? 我們繼續比較下面的例子，并測試他們在運行時的效率差異：
? ? ? Boolean b = Boolean.valueOf("true");
? ? ? Boolean b = new Boolean("true");
? ? ? 前者通過靜態工廠方法保證了每次返回的對象，如果他們都是true或false，那么他們將返回相同的對象。換句話說，valueOf將只會返回Boolean.TRUE或Boolean.FALSE兩個靜態域字段之一。而后面的Boolean構造方式，每次都會構造出一個新的Boolean實例對象。這樣在多次調用后，第一種靜態工廠方法將會避免大量不必要的Boolean對象被創建，從而提高了程序的運行效率，也降低了垃圾回收的負擔。?
?
?? ?? 繼續比較下面的代碼：
? ? ? 改進后的Person類只是在初始化的時候創建Calender、TimeZone和Date實例一次，而不是在每次調用isBabyBoomer方法時都創建一次他們。如果該方法會被頻繁調用，效率的提升將會極為顯著。
?? ?? 集合框架中的Map接口提供keySet方法，該方法每次都將返回底層原始Map對象鍵數據的視圖，而并不會為該操作創建一個Set對象并填充底層Map所有鍵的對象拷貝。因此當多次調用該方法并返回不同的Set對象實例時，事實上他們底層指向的將是同一段數據的引用。
? ? ? 在該條目中還提到了自動裝箱行為給程序運行帶來的性能沖擊，如果可以通過原始類型完成的操作應該盡量避免使用裝箱類型以及他們之間的交互使用。見下例：
?? ?? 本例中由于錯把long sum定義成Long sum，其效率降低了近10倍，這其中的主要原因便是該錯誤導致了2的31次方個臨時Long對象被創建了。
六、消除過期的對象引用：
? ? ? 盡管Java不像C/C++那樣需要手工管理內存資源，而是通過更為方便、更為智能的垃圾回收機制來幫助開發者清理過期的資源。即便如此，內存泄露問題仍然會發生在你的程序中，只是和C/C++相比，Java中內存泄露更加隱匿，更加難以發現，見如下代碼：
? ? ? 以上示例代碼，在正常的使用中不會產生任何邏輯問題，然而隨著程序運行時間不斷加長，內存泄露造成的副作用將會慢慢的顯現出來，如磁盤頁交換、OutOfMemoryError等。那么內存泄露隱藏在程序中的什么地方呢？當我們調用pop方法是，該方法將返回當前棧頂的elements，同時將該棧的活動區間(size)減一，然而此時被彈出的Object仍然保持至少兩處引用，一個是返回的對象，另一個則是該返回對象在elements數組中原有棧頂位置的引用。這樣即便外部對象在使用之后不再引用該Object，那么它仍然不會被垃圾收集器釋放，久而久之導致了更多類似對象的內存泄露。修改方式如下：
? ? ? 由于現有的Java垃圾收集器已經足夠只能和強大，因此沒有必要對所有不在需要的對象執行obj = null的顯示置空操作，這樣反而會給程序代碼的閱讀帶來不必要的麻煩，該條目只是推薦在以下3中情形下需要考慮資源手工處理問題：
? ? ? 1)?? ?類是自己管理內存，如例子中的Stack類。
? ? ? 2)?? ?使用對象緩存機制時，需要考慮被從緩存中換出的對象，或是長期不會被訪問到的對象。
? ? ? 3)?? ?事件監聽器和相關回調。用戶經常會在需要時顯示的注冊，然而卻經常會忘記在不用的時候注銷這些回調接口實現類。
?? ?
七、避免使用終結方法：
? ? ? 任何事情都存在其一定的雙面性或者多面性，對于C++的開發者，內存資源是需要手工分配和釋放的，而對于Java和C#這種資源托管的開發語言，更多的工作可以交給虛擬機的垃圾回收器來完成，由此C++程序得到了運行效率，卻失去了安全。在Java的實際開發中，并非所有的資源都是可以被垃圾回收器自動釋放的，如FileInputStream、Graphic2D等class中使用的底層操作系統資源句柄，并不會隨著對象實例被GC回收而被釋放，然而這些資源對于整個操作系統而言，都是非常重要的稀缺資源，更多的資源句柄泄露將會導致整個操作系統及其運行的各種服務程序的運行效率直線下降。那么如何保證系統資源不會被泄露了？在C++中，由于其資源完全交由開發者自行管理，因此在決定資源何時釋放的問題上有著很優雅的支持，C++中的析構函數可以說是完成這一工作的天然候選者。任何在棧上聲明的C++對象，當棧退出或者當前對象離開其作用域時，該對象實例的析構函數都會被自動調用，因此當函數中有任何異常(Exception)發生時，在棧被銷毀之前，所有棧對象的析構函數均會被自動調用。然而對于Java的開發者而言，從語言自身視角來看，Java本身并未提供析構函數這樣的機制，當然這也是和其資源被JVM托管有一定關系的。
?? ?? 在Java中完成這樣的工作主要是依靠try-finally機制來協助完成的。然而Java中還提供了另外一種被稱為finalizer的機制，使用者僅僅需要重載Object對象提供的finalize方法，這樣當JVM的在進行垃圾回收時，就可以自動調用該方法。但是由于對象何時被垃圾收集的不確定性，以及finalizer給GC帶來的性能上的影響，因此并不推薦使用者依靠該方法來達到關鍵資源釋放的目的。比如，有數千個圖形句柄都在等待被終結和回收，可惜的是執行終結方法的線程優先級要低于普通的工作者線程，這樣就會有大量的圖形句柄資源停留在finalizer的隊列中而不能被及時的釋放，最終導致了系統運行效率的下降，甚至還會引發JVM報出OutOfMemoryError的錯誤。
? ? ? Java的語言規范中并沒有保證該方法會被及時的執行，甚至都沒有保證一定會被執行。即便開發者在code中手工調用了System.gc和System.runFinalization這兩個方法，這僅僅是提高了finalizer被執行的幾率而已。還有一點需要注意的是，被重載的finalize()方法中如果拋出異常，其棧幀軌跡是不會被打印出來的。在Java中被推薦的資源釋放方法為，提供顯式的具有良好命名的接口方法，如FileInputStream.close()和Graphic2D.dispose()等。然后使用者在finally區塊中調用該方法，見如下代碼:
????? 那么在實際的開發中，利用finalizer又能給我們帶來什么樣的幫助呢？見下例：
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
