java單例模式的討論

原文地址 點擊打開鏈接

關於單例模式的文章，其實網上早就已經氾濫了。但一個小小的單例，裏面卻是有着許多的變化。網上的文章大多也是提到了其中的一個或幾個點，很少有比較全面且脈絡清晰的文章，於是，我便萌生了寫這篇文章的念頭。企圖把這個單例說透，說深入。但願我不會做的太差。

　　首先來看一個典型的實現：

1 
10 public class SingletonOne {
11 
12 
13 private static SingletonOne instance = null;
14 
15 
18 private SingletonOne() {
19 
20 }
21 
22 
27 public static SingletonOne getInstance() {
28 if (instance == null) { // 1
29 instance = new SingletonOne(); // 2
30 }
31 return instance;
32 }
33 
34 }

　　註釋中已經有簡單的分析了。接下來分析一下關於“非線程安全”的部分。

　　1、當線程A進入到第28行（#1）時，檢查instance是否爲空，此時是空的。
　　2、此時，線程B也進入到28行（#1）。切換到線程B執行。同樣檢查instance爲空，於是往下執行29行（#2），創建了一個實例。接着返回了。
　　3、在切換回線程A，由於之前檢查到instance爲空。所以也會執行29行（#2）創建實例。返回。
　　4、至此，已經有兩個實例被創建了，這不是我們所希望的。 

 怎麼解決線程安全問題？

　　方法一：同步方法。即在getInstance()方法上加上synchronized關鍵字。這時單例變成了　　

使用同步方法的單例

1 
4 package com.something.singleton;
5 
6 
18 public class SingletonTwo {
19 
20 
21 private static SingletonTwo instance = null;
22 
23 
26 private SingletonTwo() {
27 
28 }
29 
30 
36 public static synchronized SingletonTwo getInstance() {
37 if (instance == null) { // 1
38 instance = new SingletonTwo(); // 2
39 }
40 return instance;
41 }
42 
43 }

 

　　加上synchronized後確實實現了線程的互斥訪問getInstance()方法。從而保證了線程安全。但是這樣就完美了麼？我們看。其實在典型實現裏，會導致問題的只是當instance還沒有被實例化的時候，多個線程訪問#1的代碼纔會導致問題。而當instance已經實例化完成後。每次調用getInstance()，其實都是直接返回的。即使是多個線程訪問，也不會出問題。但給方法加上synchronized後。所有getInstance()的調用都要同步了。其實我們只是在第一次調用的時候要同步。而同步需要消耗性能。這就是問題。

　　方法二：雙重檢查加鎖Double-checked locking。
　　其實經過分析發現，我們只要保證 instance = new SingletonOne(); 是線程互斥訪問的就可以保證線程安全了。那把同步方法加以改造，只用synchronized塊包裹這一句。就得到了下面的代碼：

1 public static SingletonThree getInstance() {
2 if (instance == null) { // 1
3 synchronized (SingletonThree.class) {
4 instance = new SingletonThree(); // 2
5 }
6 }
7 return instance;
8 }

 

　　這個方法可行麼？分析一下發現是不行的！
　　1、線程A和線程B同時進入//1的位置。這時instance是爲空的。
　　2、線程A進入synchronized塊，創建實例，線程B等待。
　　3、線程A返回，線程B繼續進入synchronized塊，創建實例。。。
　　4、這時已經有兩個實例創建了。 

　　爲了解決這個問題。我們需要在//2的之前，再加上一次檢查instance是否被實例化。（雙重檢查加鎖）接下來，代碼變成了這樣：

1 public static SingletonThree getInstance() {
2 if (instance == null) { // 1
3 synchronized (SingletonThree.class) {
4 if (instance == null) { 
5 instance = new SingletonThree(); // 2
6 }
7 }
8 }
9 return instance;
10 }

 

　　這樣，當線程A返回，線程B進入synchronized塊後，會先檢查一下instance實例是否被創建，這時實例已經被線程A創建過了。所以線程B不會再創建實例，而是直接返回。貌似！到此爲止，這個問題已經被我們完美的解決了。遺憾的是，事實完全不是這樣！這個方法在單核和 多核的cpu下都不能保證很好的工作。導致這個方法失敗的原因是當前java平臺的內存模型。java平臺內存模型中有一個叫“無序寫”（out-of-order writes）的機制。正是這個機制導致了雙重檢查加鎖方法的失效。這個問題的關鍵在上面代碼上的第5行：instance = new SingletonThree(); 這行其實做了兩個事情：1、調用構造方法，創建了一個實例。2、把這個實例賦值給instance這個實例變量。可問題就是，這兩步jvm是不保證順序的。也就是說。可能在調用構造方法之前，instance已經被設置爲非空了。下面我們看一下出問題的過程：
　　1、線程A進入getInstance()方法。
　　2、因爲此時instance爲空，所以線程A進入synchronized塊。
　　3、線程A執行 instance = new SingletonThree(); 把實例變量instance設置成了非空。（注意，實在調用構造方法之前。）
　　4、線程A退出，線程B進入。
　　5、線程B檢查instance是否爲空，此時不爲空（第三步的時候被線程A設置成了非空）。線程B返回instance的引用。（問題出現了，這時instance的引用並不是SingletonThree的實例，因爲沒有調用構造方法。） 
　　6、線程B退出，線程A進入。
　　7、線程A繼續調用構造方法，完成instance的初始化，再返回。 

　　好吧，繼續努力，解決由“無序寫”帶來的問題。

1 public static SingletonThree getInstance() {
2 if (instance == null) { 
3 synchronized (SingletonThree.class) { // 1
4 SingletonThree temp = instance; // 2
5 if (temp == null) {
6 synchronized (SingletonThree.class) { // 3
7 temp = new SingletonThree(); // 4
8 }
9 instance = temp; // 5
10 }
11 }
12 }
13 return instance;
14 }

 

　　解釋一下執行步驟。
　　1、線程A進入getInstance()方法。
　　2、因爲instance是空的 ，所以線程A進入位置//1的第一個synchronized塊。
　　3、線程A執行位置//2的代碼，把instance賦值給本地變量temp。instance爲空，所以temp也爲空。 
　　4、因爲temp爲空，所以線程A進入位置//3的第二個synchronized塊。
　　5、線程A執行位置//4的代碼，把temp設置成非空，但還沒有調用構造方法！（“無序寫”問題） 
　　6、線程A阻塞，線程B進入getInstance()方法。
　　7、因爲instance爲空，所以線程B試圖進入第一個synchronized塊。但由於線程A已經在裏面了。所以無法進入。線程B阻塞。
　　8、線程A激活，繼續執行位置//4的代碼。調用構造方法。生成實例。
　　9、將temp的實例引用賦值給instance。退出兩個synchronized塊。返回實例。
　　10、線程B激活，進入第一個synchronized塊。
　　11、線程B執行位置//2的代碼，把instance實例賦值給temp本地變量。
　　12、線程B判斷本地變量temp不爲空，所以跳過if塊。返回instance實例。

　　好吧，問題終於解決了，線程安全了。但是我們的代碼由最初的3行代碼變成了現在的一大坨~。於是又有了下面的方法。

　　方法三：預先初始化static變量。

1 
11 public class SingletonFour {
12 
13 
14 private static SingletonFour instance = new SingletonFour();
15 
16 
19 private SingletonFour() {
20 
21 }
22 
23 
28 public static SingletonFour getInstance() {
29 return instance;
30 }
31 
32 }

　　看到這個方法，世界又變得清淨了。由於java的機制，static的成員變量只在類加載的時候初始化一次，且類加載是線程安全的。所以這個方法實現的單例是線程安全的。但是這個方法卻犧牲了Lazy的特性。單例類加載的時候就實例化了。如註釋所述：非懶加載，如果構造的單例很大，構造完又遲遲不使用，會導致資源浪費。

　　那到底有沒有完美的辦法？懶加載，線程安全，代碼簡單。

　　方法四：使用內部類。

 

1 
12 public class SingletonFive {
13 
14 
17 private static class SingletonHolder{
18 
19 private static SingletonFive instance = new SingletonFive();
20 }
21 
22 
25 private SingletonFive() {
26 
27 }
28 
29 
34 public static SingletonFive getInstance() {
35 return SingletonHolder.instance;
36 }
37 
38 }

　　解釋一下，因爲java機制規定，內部類SingletonHolder只有在getInstance()方法第一次調用的時候纔會被加載（實現了lazy），而且其加載過程是線程安全的（實現線程安全）。內部類加載的時候實例化一次instance。

 

　　最後，總結一下：
　　1、如果單例對象不大，允許非懶加載，可以使用方法三。
　　2、如果需要懶加載，且允許一部分性能損耗，可以使用方法一。（官方說目前高版本的synchronized已經比較快了）
　　3、如果需要懶加載，且不怕麻煩，可以使用方法二。
　　4、如果需要懶加載，沒有且！推薦使用方法四。