前言

作為開發(fā)者，單例這個就再也熟悉不過了，但是作為多種單例實現(xiàn)模式，我個人覺得雙重校驗鎖是非常不多的實現(xiàn)，我們簡單來分析一下其原理。

正文

先來說一下Java版本的，后面會涉及Kotlin中的代碼我們再做比對。

代碼實現(xiàn)

Java代碼實現(xiàn)如下：

//雙重校驗鎖單例
public class SingleInstance {
    //必須volatile修飾 見分析1
    private volatile static SingleInstance instance;
    //私有化構(gòu)造函數(shù)
    private SingleInstance() {
    }
 
    public static SingleInstance getInstance() {
        //第一個判空 見分析2
        if (instance == null) {
            synchronized (SingleInstance.class) {
                //第二個判空 見分析3
                if (instance == null) {
                    //新建實例
                    instance = new SingleInstance();
                }
            }
        }
        return instance;
    }
}

首先這里synchronized關(guān)鍵字沒有修飾整個getInstance函數(shù)，因為這個函數(shù)可能使用地方很多，這樣就會造成其他線程阻塞，不太好，所以這里只同步了一段代碼。

分析2：為什么在進入同步代碼塊時需要進行進行判空，假如有線程A和線程B，這時線程A先判斷instance為null，所以它進入了同步代碼塊，創(chuàng)建了對象，然后線程B再進來時，它就不必再進入同步代碼快了，可以直接返回，也其實也就是懶加載，可以加快執(zhí)行速度。

分析3：為什么在同步代碼塊中還要再進行一次判斷呢，假如有線程A和線程B，它倆A先調(diào)用方法，B緊接著調(diào)用，這時A、B在分析2出的判空都是空，所以A進入同步代碼塊，B進行等待，當(dāng)A進入同步代碼塊中創(chuàng)建了對象后，A線程釋放了鎖，這時B再進入，如果這時不加分析3的判空，B又會創(chuàng)建一個實例，這明顯不符合規(guī)矩。

分析1：那既然加了2層判斷，那為什么還要加個volatile關(guān)鍵字呢，這里知識點就有點多了。

因為新建實例的代碼：

instance = new SingleInstance();

它不是一個原子操作，這個簡單的賦值可以分為3步：

1、給SingleInstance分配內(nèi)存

2、調(diào)用SingleInstance的構(gòu)造方法

3、把instance指向分配的內(nèi)存空間

這是正常邏輯的3個步驟，也只有按1 2 3執(zhí)行后，這個instance才不是null。

但是Java內(nèi)存模型允許這個進行指令重排序，也就是這3步可能是123也可能是132，所以這里就有問題了。

假如線程A和線程B，線程A已經(jīng)跑到分析3處的代碼，這時這條指令執(zhí)行是132，剛把步驟3執(zhí)行完，這時線程B跑到了分析1處的代碼，會發(fā)現(xiàn)instance不為null了，這時線程B就直接返回了，從而導(dǎo)致錯誤。

既然知道了原因，那volatile關(guān)鍵字就是解決這個的，它可以禁止指令重新排序，而且保證所有線程看到這個變量是一致的，也就是不會從緩存中讀取(這個特性后面有機會再說)，所以在創(chuàng)建instance實例時，它的步驟都是123，就不會出錯了。

總結(jié)

到此這篇關(guān)于Java雙重校驗鎖單例原理的文章就介紹到這了,更多相關(guān)Java校驗鎖單例內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論