前言

作為開(kāi)發(fā)者，單例這個(gè)就再也熟悉不過(guò)了，但是作為多種單例實(shí)現(xiàn)模式，我個(gè)人覺(jué)得雙重校驗(yàn)鎖是非常不多的實(shí)現(xiàn)，我們簡(jiǎn)單來(lái)分析一下其原理。

正文

先來(lái)說(shuō)一下Java版本的，后面會(huì)涉及Kotlin中的代碼我們?cè)僮霰葘?duì)。

代碼實(shí)現(xiàn)

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

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

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

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

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

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

因?yàn)樾陆▽?shí)例的代碼：

instance = new SingleInstance();

它不是一個(gè)原子操作，這個(gè)簡(jiǎn)單的賦值可以分為3步：

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

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

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

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

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

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

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

總結(jié)

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