執行緒安全之單例模式

面試的時候，常常會被問到這樣一個問題：請您寫出一個單例模式（Singleton Pattern）。好吧，寫就寫，這還不容易。順手寫一個：

飢餓模式

這種寫法就是所謂的飢餓模式，每個物件在沒有使用之前就已經初始化了。這就可能帶來潛在的效能問題：如果這個物件很大呢？沒有使用這個物件之前，就把它載入到了記憶體中去是一種巨大的浪費。針對這種情況，我們可以對以上的程式碼進行改進，使用一種新的設計思想——

延遲載入（Lazy-load Singleton）

。

懶漢模式

這種寫法就是所謂的懶漢模式。它使用了延遲載入來保證物件在沒有使用之前，是不會進行初始化的。但是，通常這個時候面試官又會提問新的問題來刁難一下。他會問：這種寫法執行緒安全嗎？回答必然是：不安全。這是因為在多個執行緒可能同時執行到第九行，判斷singObj為null，於是同時進行了初始化。所以，這是面臨的問題是如何使得這個程式碼執行緒安全？很簡單，在那個方法前面加一個Synchronized就OK了。

Synchronized保證執行緒安全

寫到這裡，面試官可能仍然會狡猾的看了你一眼，繼續刁難到：這個寫法有沒有什麼效能問題呢？答案肯定是有的！

同步的代價必然會一定程度的使程式的併發度降低

。那麼有沒有什麼方法，一方面是執行緒安全的，有可以有很高的併發度呢？我們觀察到，執行緒不安全的原因其實是在初始化物件的時候，所以，可以想辦法把同步的粒度降低，只在初始化物件的時候進行同步。這裡有必要提出一種新的設計思想——

雙重檢查鎖（Double-Checked Lock）。

雙重檢查鎖

這種寫法使得只有在載入新的物件進行同步，在載入完了之後，其他執行緒在第九行就可以判斷跳過鎖的的代價直接到第15行程式碼了。做到很好的併發度。

至此，上面的寫法一方面實現了Lazy-Load，另一個方面也做到了併發度很好的執行緒安全，一切看上很完美。這是，面試官可能會對你的回答滿意的點點頭。但是，你此時提出說，其實這種寫法還是有問題的！！問題在哪裡？假設執行緒A執行到了第9行，它判斷物件為空，於是執行緒A執行到第12行去初始化這個物件，但初始化是需要耗費時間的，但是這個物件的地址其實已經存在了。此時執行緒B也執行到了第九行，它判斷不為空，於是直接跳到15行得到了這個物件。但是，這個物件還

沒有被完整的初始化！

得到一個沒有初始化完全的物件有什麼用！！關於這個Double-Checked Lock的討論有很多，目前公認這是一個Anti-Pattern，不推薦使用！所以當你的面試官聽到你的這番答覆，他會不會被Hold住呢？

那麼有沒有什麼更好的寫法呢？有！這裡又要提出一種新的模式——

Initialization on Demand Holder.

這種方法使用內部類來做到延遲載入物件，在初始化這個內部類的時候，JLS（Java Language Sepcification）會保證這個類的執行緒安全。這種寫法最大的美在於，完全使用了Java虛擬機器的機制進行同步保證，沒有一個同步的關鍵字。