[[393262]]

 單例可以說是最簡單的一個設計模式了，單例模式要求只能創(chuàng)建一個對象實例。通常的寫法是聲明私有的構(gòu)造函數(shù)，提供靜態(tài)方法獲取單例的對象實例。

常見的單例寫法就是餓漢式、懶漢式、雙重加鎖驗證、靜態(tài)內(nèi)部類和枚舉的方式，寫法可能大家都知道，不過針對不同的寫法還是有可以繼續(xù)深挖一下的地方，讓我們從最簡單的幾種寫法開始回顧單例，不想看前面的話直接往后翻好了。

回顧幾種實現(xiàn)方式

餓漢式

餓漢式的寫法通常靜態(tài)成員變量已經(jīng)是初始化好的，優(yōu)點是可以不加鎖就獲取到對象實例，線程安全，主要的缺點在于不是延加載，稍微存在內(nèi)存的浪費，因為如果初始化的邏輯較為復雜，比如存在網(wǎng)絡請求或者一些復雜的邏輯在內(nèi)，就會產(chǎn)生內(nèi)存的浪費。

懶漢式

懶漢式的寫法解決了餓漢式浪費內(nèi)存的問題，在真正需要獲取實例對象的才去執(zhí)行初始化。

通常一般來說可能會有兩種方式，第一種就是不加鎖的寫法，很顯然這樣是肯定不行的，正常的方式一般都是通過同步鎖的方式加鎖獲取實例對象。

但是這種實現(xiàn)方式在之前的JDK版本synchronized沒有鎖優(yōu)化的情況每次獲取單例對象性能存在很大的問題，于是乎有了DCL的寫法。

雙重加鎖驗證DCL

于是為了解決懶漢式性能的問題，雙重加鎖驗證的寫法誕生了，先判斷一次空，真的為空再執(zhí)行加鎖，然后再判斷一次。

這樣的話，只有在實例對象是空的情況才會去加鎖創(chuàng)建對象，性能問題得到了一定程度上的解決，也不會和餓漢一樣有內(nèi)存浪費的問題。

但是，這個寫法也存在問題，就是會拿到未初始化完全的對象，我之前的一篇文章中也提到這個方式的問題，具體請看一次群聊引發(fā)的血案。

讓我這里復用一下我寫過的東西。

1. 從CPU的角度來看，instance = new Instance()可以分為分為幾個步驟：
2. 分配對象內(nèi)存空間
3. 執(zhí)行構(gòu)造方法，對象初始化

instance指向分配的內(nèi)存地址

實際上，由于指令重排的問題，2、3的步驟可能會發(fā)生重排序，那么問題就發(fā)生了。

instance先被指向內(nèi)存地址，然后再執(zhí)行初始化，如果此時另外一個線程來訪問getInstance方法，就會拿到instance不是null，最后拿到的將是一個沒有被完全初始化的對象!

現(xiàn)在也有很多人說這個問題在高版本的JDK中已經(jīng)解決了，但是我是沒發(fā)現(xiàn)有什么直接證據(jù)，如果你知道，請你告訴我。

靜態(tài)內(nèi)部類

這個通過JVM來保證創(chuàng)建單例對象的線程安全和唯一性，是比較好的辦法。

Singleton類加載的時候，SingletonHolder不會加載，只有在調(diào)用getInstance方法的時候才會執(zhí)行初始化，這樣既起到了懶加載的作用，同時又使用到了JVM類加載機制，保證了單例對象初始化的線程安全。

這種方式也是目前比較推薦的一種方式。

枚舉

通過枚舉來實現(xiàn)單例是Effective Java作者 Josh Bloch 提倡的方式，也是單例模式的最佳實現(xiàn)方式。

為了看清楚枚舉怎么實現(xiàn)單例模式的，我們來編譯一下枚舉生成的最終字節(jié)碼。

執(zhí)行javac Singleton.java生成class文件，接著執(zhí)行javap -p Singleton.class，得到如下內(nèi)容：

為了看到更詳細的內(nèi)容，我們執(zhí)行 javap -c Singleton。

通過最終生成的字節(jié)碼，我們其實發(fā)現(xiàn)本質(zhì)上枚舉的初始化通過static代碼塊來進行初始化。

考慮下類加載的幾個步驟，加載->驗證->準備->解析->初始化，最終初始化就是執(zhí)行static代碼塊，而static代碼塊是絕對線程安全的，只能由JVM來調(diào)度，這樣保證了線程安全。

枚舉的實現(xiàn)方式好處還不止于此，除了一目了然的實現(xiàn)簡單之外，還能防止其他幾種實現(xiàn)方式避免不了的幾個問題。

再說幾種方式的問題

反射破壞單例

除了枚舉之外，其他的幾種方式都可以通過反射的方式達到破壞單例的目的，就隨便以一個實現(xiàn)方式來舉例，這里最終的輸出結(jié)果是false。

如果拿去嘗試反射創(chuàng)建枚舉對象的話，則是會報錯，可以自己動手嘗試一下。

為什么會報錯，可以直接看一下newInstance的源碼，有一段特殊的關(guān)于枚舉類型的判斷，下圖中我紅色標記的部分。

序列化

除了眾所周知的使用反射來破壞單例之外，還有另外一種能破壞單例的方式就是序列化。

對上面的餓漢方法實現(xiàn)序列化，然后得到的結(jié)果是false，序列化前后對象發(fā)生了改變。

其實關(guān)鍵的部分在于ois.readObject方法，一路跟蹤最后找到一段代碼如下：

所以很明顯我們發(fā)現(xiàn)了最終實際上這里通過反射創(chuàng)建了一個新的對象，isInstantiable實際代表的應該是類或者屬性是序列化的，那么久就返回true，我們這里肯定是true，所以最終產(chǎn)生了一個新的對象。

枚舉為啥可以防止這個問題?枚舉的實現(xiàn)方式不太一樣而已，同樣跟蹤到枚舉部分的實現(xiàn)邏輯。

下圖中紅框標注的部分就是枚舉類型去實現(xiàn)反序列化的邏輯，最終只是通過valueOf方法查找枚舉，不存在新建一個對象的邏輯。

那么，怎么防止其他方式序列化對單例的破壞?再往下看看源碼，紅框標注的意思只要有readResolve方法就可以解決問題了。

實際上，最終解決方案也很簡單，單例類加上方法即可。

好了，打完收工。現(xiàn)在是北京時間4月15日凌晨1點整，困了，睡覺。