一個單例還能寫出花來嗎?

艾小仙發表於2021-04-15

單例可以說是最簡單的一個設計模式了,單例模式要求只能建立一個物件例項。通常的寫法是宣告私有的建構函式,提供靜態方法獲取單例的物件例項。

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

回顧幾種實現方式

餓漢式

餓漢式的寫法通常靜態成員變數已經是初始化好的,優點是可以不加鎖就獲取到物件例項,執行緒安全,主要的缺點在於不是延載入,稍微存在記憶體的浪費,因為如果初始化的邏輯較為複雜,比如存在網路請求或者一些複雜的邏輯在內,就會產生記憶體的浪費。

懶漢式

懶漢式的寫法解決了餓漢式浪費記憶體的問題,在真正需要獲取例項物件的才去執行初始化。

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

但是這種實現方式在之前的JDK版本synchronized沒有鎖優化的情況每次獲取單例物件效能存在很大的問題,於是乎有了DCL的寫法。

雙重加鎖驗證DCL

於是為了解決懶漢式效能的問題,雙重加鎖驗證的寫法誕生了,先判斷一次空,真的為空再執行加鎖,然後再判斷一次。

這樣的話,只有在例項物件是空的情況才會去加鎖建立物件,效能問題得到了一定程度上的解決,也不會和餓漢一樣有記憶體浪費的問題。

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

讓我這裡複用一下我寫過的東西。

從CPU的角度來看,instance = new Instance()可以分為分為幾個步驟:

  1. 分配物件記憶體空間
  2. 執行構造方法,物件初始化
  3. instance指向分配的記憶體地址

實際上,由於指令重排的問題,2、3的步驟可能會發生重排序,那麼問題就發生了。

instance先被指向記憶體地址,然後再執行初始化,如果此時另外一個執行緒來訪問getInstance方法,就會拿到instance不是null,最後拿到的將是一個沒有被完全初始化的物件!

現在也有很多人說這個問題在高版本的JDK中已經解決了,但是我是沒發現有什麼直接證據,如果你知道,請你告訴我。

靜態內部類

這個通過JVM來保證建立單例物件的執行緒安全和唯一性,是比較好的辦法。

Singleton類載入的時候,SingletonHolder不會載入,只有在呼叫getInstance方法的時候才會執行初始化,這樣既起到了懶載入的作用,同時又使用到了JVM類載入機制,保證了單例物件初始化的執行緒安全。

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

列舉

通過列舉來實現單例是Effective Java作者 Josh Bloch 提倡的方式,也是單例模式的最佳實現方式。

為了看清楚列舉怎麼實現單例模式的,我們來編譯一下列舉生成的最終位元組碼。

執行javac Singleton.java生成class檔案,接著執行javap -p Singleton.class,得到如下內容:

為了看到更詳細的內容,我們執行 javap -c Singleton

通過最終生成的位元組碼,我們其實發現本質上列舉的初始化通過static程式碼塊來進行初始化。

考慮下類載入的幾個步驟,載入->驗證->準備->解析->初始化,最終初始化就是執行static程式碼塊,而static程式碼塊是絕對執行緒安全的,只能由JVM來排程,這樣保證了執行緒安全。

列舉的實現方式好處還不止於此,除了一目瞭然的實現簡單之外,還能防止其他幾種實現方式避免不了的幾個問題。

再說幾種方式的問題

反射破壞單例

除了列舉之外,其他的幾種方式都可以通過反射的方式達到破壞單例的目的,就隨便以一個實現方式來舉例,這裡最終的輸出結果是false

如果拿去嘗試反射建立列舉物件的話,則是會報錯,可以自己動手嘗試一下。

為什麼會報錯,可以直接看一下newInstance的原始碼,有一段特殊的關於列舉型別的判斷,下圖中我紅色標記的部分。

序列化

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

對上面的餓漢方法實現序列化,然後得到的結果是false,序列化前後物件發生了改變。

其實關鍵的部分在於ois.readObject方法,一路跟蹤最後找到一段程式碼如下:

所以很明顯我們發現了最終實際上這裡通過反射建立了一個新的物件,isInstantiable實際代表的應該是類或者屬性是序列化的,那麼久就返回true,我們這裡肯定是true,所以最終產生了一個新的物件。

列舉為啥可以防止這個問題?列舉的實現方式不太一樣而已,同樣跟蹤到列舉部分的實現邏輯。

下圖中紅框標註的部分就是列舉型別去實現反序列化的邏輯,最終只是通過valueOf方法查詢列舉,不存在新建一個物件的邏輯。

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

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

好了,打完收工。現在是北京時間4月15日凌晨1點整,困了,睡覺。

相關文章