【死磕Java併發】—–Java記憶體模型之從JMM角度分析DCL-知識星球

DCL，即Double Check Lock，即雙重檢查鎖定。其實DCL很多人在單例樣式中用過，LZ面試人的時候也要他們寫過，但是有很多人都會寫錯。他們為什麼會寫錯呢？其錯誤根源在哪裡？有什麼解決方案？下麵就隨LZ一起來分析

問題分析

我們先看單例樣式裡面的懶漢式：

public class Singleton {
    private static Singleton singleton;    
    private Singleton(){}    
    public static Singleton getInstance(){        
        if(singleton == null){
            singleton = new Singleton();
        }        return singleton;
    }
}

我們都知道這種寫法是錯誤的，因為它無法保證執行緒的安全性。最佳化如下：

public class Singleton {
    private static Singleton singleton;    private Singleton(){}    public static synchronized Singleton getInstance(){        if(singleton == null){
            singleton = new Singleton();
        }        return singleton;
    }
}

最佳化非常簡單，就是在getInstance方法上面做了同步，但是synchronized就會導致這個方法比較低效，導致程式效能下降，那麼怎麼解決呢？聰明的人們想到了雙重檢查 DCL：

public class Singleton {
    private static Singleton singleton;    
    private Singleton(){}    
    public static Singleton getInstance(){        
    if(singleton == null){           // 1
            synchronized (Singleton.class){                 // 2
                if(singleton == null){                      // 3
                    singleton = new Singleton();            // 4
                }
            }
        }        return singleton;
    }
}

就如上面所示，這個程式碼看起來很完美，理由如下：

如果檢查第一個singleton不為null,則不需要執行下麵的加鎖動作，極大提高了程式的效能；
如果第一個singleton為null,即使有多個執行緒同一時間判斷，但是由於synchronized的存在，只會有一個執行緒能夠建立物件；
當第一個獲取鎖的執行緒建立完成後singleton物件後，其他的在第二次判斷singleton一定不會為null，則直接傳回已經建立好的singleton物件；

透過上面的分析，DCL看起確實是非常完美，但是可以明確地告訴你，這個錯誤的。上面的邏輯確實是沒有問題，分析也對，但是就是有問題，那麼問題出在哪裡呢？在回答這個問題之前，我們先來複習一下建立物件過程，實體化一個物件要分為三個步驟：

分配記憶體空間
初始化物件
將記憶體空間的地址賦值給對應的取用

但是由於重排序的緣故，步驟2、3可能會發生重排序，其過程如下：

分配記憶體空間
將記憶體空間的地址賦值給對應的取用
初始化物件

如果2、3發生了重排序就會導致第二個判斷會出錯，singleton != null，但是它其實僅僅只是一個地址而已，此時物件還沒有被初始化，所以return的singleton物件是一個沒有被初始化的物件，如下：

按照上面圖例所示，執行緒B訪問的是一個沒有被初始化的singleton物件。

透過上面的闡述，我們可以判斷DCL的錯誤根源在於步驟4：

singleton = new Singleton();

知道問題根源所在，那麼怎麼解決呢？有兩個解決辦法：

不允許初始化階段步驟2 、3發生重排序。
允許初始化階段步驟2 、3發生重排序，但是不允許其他執行緒“看到”這個重排序。

解決方案

解決方案依據上面兩個解決辦法即可。

基於volatile解決方案

對於上面的DCL其實只需要做一點點修改即可：將變數singleton生命為volatile即可：

public class Singleton {
    //透過volatile關鍵字來確保安全
    private volatile static Singleton singleton;    
    private Singleton(){}    
        public static Singleton getInstance(){        
            if(singleton == null){            
                synchronized (Singleton.class){                if(singleton == null){
                    singleton = new Singleton();
                }
            }
        }        return singleton;
    }
}

當singleton宣告為volatile後，步驟2、步驟3就不會被重排序了，也就可以解決上面那問題了。

基於類初始化的解決方案

該解決方案的根本就在於：利用classloder的機制來保證初始化instance時只有一個執行緒。JVM在類初始化階段會獲取一個鎖，這個鎖可以同步多個執行緒對同一個類的初始化。

public class Singleton {
    private static class SingletonHolder{
        public static Singleton singleton = new Singleton();
    }    
    public static Singleton getInstance(){        
        return SingletonHolder.singleton;
    }
}

這種解決方案的實質是：執行步驟2和步驟3重排序，但是不允許其他執行緒看見。

Java語言規定，對於每一個類或者介面C,都有一個唯一的初始化鎖LC與之相對應。從C到LC的對映，由JVM的具體實現去自由實現。JVM在類初始化階段期間會獲取這個初始化鎖，並且每一個執行緒至少獲取一次鎖來確保這個類已經被初始化過了。

參考資料

方騰飛：《Java併發程式設計的藝術》

END

【死磕Java併發】—–Java記憶體模型之從JMM角度分析DCL

問題分析

解決方案

基於volatile解決方案

基於類初始化的解決方案

參考資料

相關推薦

熱門標籤

熱門文章

分享創造快樂