[[417932]]

本文轉(zhuǎn)載自微信公眾號「程序新視界」，作者二師兄。轉(zhuǎn)載本文請聯(lián)系程序新視界公眾號。

在看Nacos的源代碼時，發(fā)現(xiàn)多處都使用了“雙重檢查鎖”的機制，算是非常好的實踐案例。這篇文章就著案例來分析一下雙重檢查鎖的使用以及優(yōu)勢所在，目的就是讓你的代碼格調(diào)更加高一個層次。

同時，基于單例模式，講解一下雙重檢查鎖的演變過程。

Nacos中的雙重檢查鎖

在Nacos的InstancesChangeNotifier類中，有這樣一個方法：

private final Map<String, ConcurrentHashSet<EventListener>> listenerMap = new ConcurrentHashMap<String, ConcurrentHashSet<EventListener>>(); 
 
private final Object lock = new Object(); 
 
public void registerListener(String groupName, String serviceName, String clusters, EventListener listener) { 
    String key = ServiceInfo.getKey(NamingUtils.getGroupedName(serviceName, groupName), clusters); 
    ConcurrentHashSet<EventListener> eventListeners = listenerMap.get(key); 
    if (eventListeners == null) { 
        synchronized (lock) { 
            eventListeners = listenerMap.get(key); 
            if (eventListeners == null) { 
                eventListeners = new ConcurrentHashSet<EventListener>(); 
                listenerMap.put(key, eventListeners); 
            } 
        } 
    } 
    eventListeners.add(listener); 
} 

該方法的主要功能就是對監(jiān)聽器事件進行注冊。其中注冊的事件都存在成員變量listenerMap當(dāng)中。listenerMap的數(shù)據(jù)結(jié)構(gòu)是key為String，value為ConcurrentHashSet的Map。也就是說，一個key對應(yīng)一個集合。

針對這種數(shù)據(jù)結(jié)構(gòu)，在多線程的情況下，Nacos處理流程如下：

• 通過key獲取value值;
• 判斷value是否為null;
• 如果value值不為null，則直接將值添加到Set當(dāng)中;
• 如果為null，就需要創(chuàng)建一個ConcurrentHashSet，在多線程時，有可能會創(chuàng)建多個，因此要使用鎖。
• 通過synchronized鎖定一個Object對象;
• 在鎖內(nèi)再獲取一次value值，如果依然是null，則進行創(chuàng)建。
• 進行后續(xù)操作。

上述過程，在鎖定前和鎖定之后，做了兩次判斷，因此稱作”雙重檢查鎖“。使用鎖的目的就是避免創(chuàng)建多個ConcurrentHashSet。

Nacos中的實例稍微復(fù)雜一下，下面以單例模式中的雙重檢查鎖的演變過程。

未加鎖的單例

這里直接演示單例模式的懶漢模式實現(xiàn)：

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

這是一個最簡單的單例模式，在單線程下運轉(zhuǎn)良好。但在多線程下會出現(xiàn)明顯的問題，可能會創(chuàng)建多個實例。

以兩個線程為例：

可以看到，當(dāng)兩個線程同時執(zhí)行時，是有可能會創(chuàng)建多個實例的，這很明顯不符合單例的要求。

加鎖單例

針對上述代碼的問題，很直觀的想到是進行加鎖處理，實現(xiàn)代碼如下：

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

與第一個示例唯一的區(qū)別是在方法上添加了synchronized關(guān)鍵字。這時，當(dāng)多個線程進入該方法時，需要先獲得鎖才能進行執(zhí)行。

通過在方法上添加synchronized關(guān)鍵字，看似完美的解決了多線程的問題，但卻帶了性能問題。

我們知道使用鎖會導(dǎo)致額外的性能開銷，對于上面的單例模式，只有第一次創(chuàng)建時需要鎖(防止創(chuàng)建多個實例)，但查詢時是不需要鎖的。

如果針對方法進行加鎖，每次查詢也要承擔(dān)加鎖的性能損耗。

雙重檢查鎖

針對上面的問題，就有了雙重檢查鎖，示例如下：

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

第一，將鎖的范圍縮小的方法內(nèi);

第二，鎖之前先判斷一下是不是null，如果不為null，說明已經(jīng)實例化了，直接返回，沒必要進行創(chuàng)建;

第三，如果為null，進行加鎖，然后再次判斷是否為null。為什么要再次判斷?因為一個線程判斷為null之后，另外一個線程可能已經(jīng)創(chuàng)建了對象，所以在鎖定之后，需要再次核實一下，真的為null，則進行對象創(chuàng)建。

改進之后，既保證了線程的安全性，又避免了鎖導(dǎo)致的性能損失。問題到此結(jié)束了嗎?并沒有，繼續(xù)往下看。

JVM的指令重排

在某些JVM當(dāng)中，編譯器為了性能問題，會進行指令重排。在上述代碼中new Singleton()并不是原子操作，有可能會被編譯器進行重排操作。

創(chuàng)建對象可抽象為三步：

memory = allocate();    //1：分配對象的內(nèi)存空間  
ctorInstance(memory);  //2：初始化對象  
instance = memory;     //3：設(shè)置instance指向剛分配的內(nèi)存地址 

上面操作中，操作2依賴于操作1，但操作3并不依賴于操作2。因此，JVM是可以進行指令重排優(yōu)化的，可能會出現(xiàn)如下的執(zhí)行順序：

memory = allocate();    //1：分配對象的內(nèi)存空間  
instance = memory;     //3：instance指向剛分配的內(nèi)存地址，此時對象還未初始化 
ctorInstance(memory);  //2：初始化對象 

指令重排之后，將操作3的賦值操作放在了前面，那就會出現(xiàn)一個問題：當(dāng)線程A執(zhí)行完步驟賦值操作，但還未執(zhí)行對象初始化。此時，線程B進來了，在第一層判斷時發(fā)現(xiàn)Instance已經(jīng)有值了(實際上還未初始化)，直接返回對應(yīng)的值。那么，程序在使用這個未初始化的值時，便會出現(xiàn)錯誤。

針對此問題，可在instance上添加volatile關(guān)鍵字，使得instance在讀、寫操作前后都會插入內(nèi)存屏障，避免重排序。

最終，單例模式實現(xiàn)如下：

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

至此，一個完善的單例模式實現(xiàn)了。此時，你是否有一個疑問，為什么Nacos中的雙重檢查鎖沒有使用volatile關(guān)鍵字呢?

答案很簡單：上面單例模式如果出現(xiàn)指令重排，會導(dǎo)致單例實例被使用。那么，再看Nacos的代碼，由于創(chuàng)建ConcurrentHashSet并不會影響到查詢，而真正影響查詢的是listenerMap.put方法，而ConcurrentHashSet本身是線程安全的。因此，也就不會出現(xiàn)線程安全問題，不用使用volatile關(guān)鍵字了。

小結(jié)

閱讀源碼最有意思的一個地方就是可以看到很多經(jīng)典知識的實踐，如果能夠深入思考，拓展一下，會獲得意想不到的收獲。

再回顧一下本文的重點：

• 閱讀Nacos源碼，發(fā)現(xiàn)雙重檢查鎖的使用;
• 未加鎖單例模式使用，會創(chuàng)建多個對象;
• 方法上加鎖，導(dǎo)致性能下降;
• 代碼內(nèi)局部加鎖，雙重判斷，既滿足線程安全，又滿足性能需求;
• 單例模式特例：創(chuàng)建對象分多步，會出現(xiàn)指令重排現(xiàn)象，采用volatile進行避免指令重排。