什么是線程安全

在進(jìn)行多線程編程的時(shí)候，當(dāng)我們編寫(xiě)出來(lái)的多線程的代碼運(yùn)行結(jié)果不符合我們的預(yù)期的時(shí)候，這時(shí)候就是 bug，這種 bug 是由于多線程的問(wèn)題而產(chǎn)生出來(lái)的 bug 我們稱(chēng)之為 線程安全問(wèn)題

當(dāng)我們編寫(xiě)出來(lái)的多線程代碼運(yùn)行之后的結(jié)果符合我們的預(yù)期結(jié)果的時(shí)候，說(shuō)明代碼沒(méi)有問(wèn)題，這時(shí)候就是 線程安全

線程安全問(wèn)題的產(chǎn)生與解決方案

線程安全問(wèn)題的產(chǎn)生主要有 五個(gè)原因

線程的調(diào)度是隨機(jī)的

這個(gè)原因是由操作系統(tǒng)產(chǎn)生的，CPU 是多核心的，在進(jìn)行線程的調(diào)度的時(shí)候并不是等到線程徹底執(zhí)行完才輪到下一個(gè)線程執(zhí)行，CPU 使用的是搶占式執(zhí)行，也就是說(shuō)，這個(gè)線程可能執(zhí)行到一半，就立馬被剝奪了 CPU 資源，開(kāi)始執(zhí)行下一個(gè)線程，然后執(zhí)行完一半，又將上一個(gè)線程調(diào)度回來(lái)，這是由隨機(jī)性的，程序員無(wú)法通過(guò)代碼應(yīng)用層得知。

這個(gè)問(wèn)題是無(wú)法改變的，這也就是為什么會(huì)產(chǎn)生線程安全問(wèn)題的最根本的原因。

多個(gè)線程對(duì)同一個(gè)變量進(jìn)行修改

在之前的文章中就已經(jīng)設(shè)計(jì)過(guò)這種情況的討論，如果修改的外部類(lèi)的成員變量，是會(huì)發(fā)生線程安全問(wèn)題的，如果修改的是局部變量，那就會(huì)觸發(fā) “變量捕獲的語(yǔ)法”，這時(shí)候是不建議進(jìn)行修改的。

解決方法也很簡(jiǎn)單，就是加鎖，通過(guò) synchronized 進(jìn)行加鎖。

public class Demo2 {
    private static int count = 0;
    public static void main(String[] args) throws InterruptedException {
        Object locker = new Object();
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                synchronized(locker) {
                    count++;
                }
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                synchronized(locker) {
                    count++;
                }
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println("count =" + count);
    }
}

線程的修改操作不是原子性的

這個(gè)問(wèn)題其實(shí)和第二個(gè)問(wèn)題是一樣的，為什么修改同一個(gè)變量可能會(huì)發(fā)生線程安全問(wèn)題，因?yàn)槲覀兊男薷闹噶畈⒉皇窃有缘?，也就說(shuō)，這個(gè)操作并不是 CPU 執(zhí)行一次指令就可以完成 count++ 的，count ++ 實(shí)質(zhì)是由三條指令實(shí)現(xiàn)的，首先 load count 這個(gè)數(shù)值，然后進(jìn)行 count +1 操作，最后將結(jié)果保存到內(nèi)存里。

為了使修改操作是原子性的，所以我們使用加鎖的方式來(lái)實(shí)現(xiàn)，也就是上面的代碼。

內(nèi)存可見(jiàn)性問(wèn)題

這個(gè)問(wèn)題是由于 JVM 優(yōu)化而導(dǎo)致的，

public class Test {
    private static int flag = 1;
    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            while(flag == 1) {
            }
            System.out.println("hello t1");
        });
        Thread t2 = new Thread(() -> {
            Scanner scan = new Scanner(System.in);
            System.out.println("請(qǐng)輸入falg 的數(shù)值");
            flag = scan.nextInt();
        });
        t1.start();
        t2.start();
    }
}

即使我們修改了 flag 數(shù)值，但是程序依舊沒(méi)有反應(yīng)，說(shuō)明在 t1 線程中讀取到的 flag 依舊還是 1

一個(gè)線程涉及到了讀操作，一個(gè)線程涉及到了修改操作，這可能會(huì)觸發(fā)線程安全問(wèn)題，也就是內(nèi)存可見(jiàn)性問(wèn)題，讀操作沒(méi)有讀到修改過(guò)的數(shù)值。

原因：JVM / 編譯器 其實(shí)是帶有優(yōu)化功能的，因?yàn)椴煌某绦騿T寫(xiě)出來(lái)的代碼不同，運(yùn)行效率也是不同，為了提高代碼的運(yùn)行效率，JVM / 編譯器 在不改變我們代碼的邏輯的情況下，會(huì)對(duì)我們寫(xiě)的代碼進(jìn)行優(yōu)化。雖然說(shuō)對(duì)我們代碼邏輯不會(huì)做出改變，但是在多線程編程下可能會(huì)發(fā)生誤判。

例如上面的代碼，t1 線程進(jìn)行讀 flag 操作，也就是寄存器會(huì)從內(nèi)存中讀取 flag ，但是這是一個(gè) while 循環(huán)，在一秒鐘之內(nèi)就會(huì)讀取很多次，雖然 t2 線程會(huì)對(duì) flag 進(jìn)行修改，但是 t2 線程在啟動(dòng)之前 flag 這個(gè)數(shù)值就被 t1 線程讀取了 幾千萬(wàn)次，所以編譯器 / JVM 會(huì)認(rèn)為 flag 是一個(gè)不會(huì)被修改的數(shù)值，即把這個(gè)讀內(nèi)存操作優(yōu)化為 讀寄存器操作，也就是把 flag 這個(gè)數(shù)值拷貝一份到寄存器里，這樣 CPU 就直接從寄存器讀 flag 數(shù)值而不用到 內(nèi)存中讀取了。

等到了 t2 線程開(kāi)始運(yùn)行的時(shí)候，我們進(jìn)行修改 flag 數(shù)值，內(nèi)存中 flag 即使被修改了，但是 t1 線程還是不知道flag 被修改了，因?yàn)榇藭r(shí)它是從寄存器讀取 flag 數(shù)值。

拓展一下，如果我們?cè)?t1 線程 加上 sleep 的話，這個(gè)內(nèi)存可見(jiàn)性問(wèn)題就消失了。

    private static int flag = 1;
    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            while(flag == 1) {
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
            System.out.println("hello t1");
        });
        Thread t2 = new Thread(() -> {
            Scanner scan = new Scanner(System.in);
            System.out.println("請(qǐng)輸入falg 的數(shù)值");
            flag = scan.nextInt();
        });
        t1.start();
        t2.start();
    }

即使是 sleep 1 ms 內(nèi)存可見(jiàn)性問(wèn)題也沒(méi)有發(fā)生，這是為什么？

因?yàn)樽x內(nèi)存操作可能就是幾 ns 的事情，優(yōu)化為 讀寄存器操作可以再快個(gè)幾 ns，但是代碼存在 sleep 1 ms ，這個(gè) 1ms 的存在，編譯器/ JVM 即使優(yōu)化這個(gè)讀操作也不能讓代碼的效率有一個(gè)質(zhì)的飛躍，所以干脆就不提升了。所以?xún)?nèi)存可見(jiàn)性問(wèn)題也就不存在了。

JVM / 編譯器的優(yōu)化是一個(gè)很復(fù)雜的事情，具體的細(xì)節(jié)大家可以參考深入理解Java虛擬機(jī) 這本書(shū)，在后續(xù)文章中也會(huì)提到 JVM 的部分內(nèi)容。

如何解決這個(gè)內(nèi)存可見(jiàn)性問(wèn)題？？？
使用 volatile 關(guān)鍵字

這個(gè)關(guān)鍵字的英文翻譯的易變的，說(shuō)明這個(gè)變量我是會(huì)進(jìn)行修改的，你不能進(jìn)行讀操作的優(yōu)化。

注意這個(gè)關(guān)鍵字只能修飾變量，不能修飾方法?。?！

修改后的代碼：

import java.util.Scanner;
public class Test {
    private static volatile int flag = 1;
    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            while(flag == 1) {
            }
            System.out.println("hello t1");
        });
        Thread t2 = new Thread(() -> {
            Scanner scan = new Scanner(System.in);
            System.out.println("請(qǐng)輸入falg 的數(shù)值");
            flag = scan.nextInt();
        });
        t1.start();
        t2.start();
    }
}

指令重排序問(wèn)題

這個(gè)問(wèn)題在下面的單例模式中的懶漢模式會(huì)提到~~

單例模式

單例模式是一種設(shè)計(jì)模式，也就是一個(gè)規(guī)范。

單例模式，顧名思義就是只允許一個(gè)對(duì)象的創(chuàng)建，也就是一個(gè)類(lèi)只能創(chuàng)建實(shí)例化一個(gè)對(duì)象，不能進(jìn)行多次實(shí)例化。這種設(shè)計(jì)模式的應(yīng)用場(chǎng)景還是很多的，例如：我們?cè)谶M(jìn)行服務(wù)器開(kāi)發(fā)的時(shí)候，我們需要一個(gè)對(duì)象來(lái)存放數(shù)據(jù)，這時(shí)候我們就會(huì)先寫(xiě)出類(lèi)，然后再去創(chuàng)建對(duì)象，但是如果這個(gè)對(duì)象包含的數(shù)據(jù)很大，假如有100G，那么創(chuàng)建多次之后，也就是有幾百G 的數(shù)據(jù)需要放在服務(wù)器上，并且這么多重復(fù)的數(shù)據(jù)也就只有一份是有用的，不僅僅是浪費(fèi)了服務(wù)器的內(nèi)存資源，還可能會(huì)導(dǎo)致服務(wù)器的崩潰，在這種情況下，我們通常使用單例模式來(lái)進(jìn)行約束，只允許一個(gè)對(duì)象的創(chuàng)建。

餓漢模式

餓漢模式 是程序已啟動(dòng)，隨著類(lèi)的加載，對(duì)象也隨之創(chuàng)建出來(lái)了，所以稱(chēng)之為 餓漢模式，說(shuō)明創(chuàng)建的很快。

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

從上面的代碼，我們就可以看到是要類(lèi)一加載，對(duì)象instance 也就創(chuàng)建出來(lái)了private static Singleton instance = new Singleton();

為什么說(shuō)我們不能進(jìn)行多次創(chuàng)建呢？
因?yàn)檫@個(gè)類(lèi)的構(gòu)造方法被我們用private 修飾了，在外面是不能進(jìn)行實(shí)例化的，這也是單例模式的點(diǎn)睛之筆。

我們來(lái)討論一下，這個(gè)餓漢模式 的代碼會(huì)不會(huì)出現(xiàn)線程安全問(wèn)題？
答案是不會(huì)的，線程只是從getInstance() 進(jìn)行讀操作，獲取 instance 這個(gè)對(duì)象，并沒(méi)有涉及到修改操作，自然沒(méi)有線程安全問(wèn)題的存在。

懶漢模式

懶漢模式 顧名思義就是 懶，等我們真正需要這個(gè)對(duì)象的時(shí)候，才會(huì)進(jìn)行實(shí)例化對(duì)象的操作。我們來(lái)看一下代碼：

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

當(dāng)我們真正需要用到這個(gè)對(duì)象的時(shí)候，才進(jìn)行實(shí)例化，這就是懶漢模式。

但是在多線程編程下，是可能會(huì)出現(xiàn)線程安全問(wèn)題，由于代碼涉及到寫(xiě)操作，也就是 實(shí)例化對(duì)象的操作，假設(shè)有兩個(gè)線程同時(shí)進(jìn)行對(duì)象的實(shí)例化，就會(huì)發(fā)生線程安全問(wèn)題，所以要加上鎖 synchronized .

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

但是每次進(jìn)行判斷的時(shí)候都需要進(jìn)行加鎖，這就導(dǎo)致效率低下，所以我們?cè)谕饷嬖偌右粚?if 判斷，減少加鎖的次數(shù)。

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

即使代碼被我們修改成這樣，還是會(huì)存在一個(gè)問(wèn)題，指令重排序的問(wèn)題。

我們?cè)趯?shí)例化一個(gè)對(duì)象有三條指令需要做：第一申請(qǐng)內(nèi)存空間，第二初始化對(duì)象，第三將內(nèi)存空間的首地址賦值給引用。

在編譯器/JVM 下可能會(huì)進(jìn)行優(yōu)化，將上面的三條指令優(yōu)化為先執(zhí)行1，再執(zhí)行3 ，最后執(zhí)行 2.

這可能會(huì)導(dǎo)致一個(gè)線程還沒(méi)初始化對(duì)象，另一個(gè)線程就直接拿到這個(gè)對(duì)象進(jìn)行使用了，但是這些使用操作，在后面的初始化完之后又被覆蓋掉了。這就是第五個(gè)引起線程安全問(wèn)題的原因 —— 指令重排序。

如何解決這個(gè)問(wèn)題？？？
使用 volatile 關(guān)鍵字

沒(méi)錯(cuò) volatile 關(guān)鍵字不僅僅能解決內(nèi)存可見(jiàn)性問(wèn)題，還能解決指令重排序問(wèn)題。

private static volatile SingletonLazy instance;

懶漢模式最終代碼

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

到此這篇關(guān)于Java 線程安全 與 volatile 與 單例模式的文章就介紹到這了,更多相關(guān)java 線程安全volatile與單例模式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論