Java解決執行緒安全問題

背景

原文地址：https://duktig.cn/archives/36/

1. 執行緒安全問題

1.1 什么是執行緒安全？

執行緒安全：多個執行緒不管以何種方式訪問某個類，并且在主調代碼中不需要進行同步，都能表現正確的行為，

“執行緒安全”不是指執行緒的安全，而是指記憶體的安全，為什么如此說呢？這和作業系統有關，

目前主流作業系統都是多任務的，即多個行程同時運行，為了保證安全，每個行程只能訪問分配給自己的記憶體空間，而不能訪問別的行程的，這是由作業系統保障的，但是行程中的多個執行緒共享行程的堆記憶體，這就是造成問題的潛在原因，

假設某個執行緒把資料處理到一半，覺得很累，就去休息了一會，回來準備接著處理，卻發現資料已經被修改了，不是自己離開時的樣子了，可能被其它執行緒修改了，

比如把你住的小區看作一個行程，小區里的道路/綠化等就屬于公共區域，你拿1萬塊錢往地上一扔，就回家睡覺去了，睡醒后你打算去把它撿回來，發現錢已經不見了，可能被別人拿走了，因為公共區域人來人往，你放的東西在沒有看管措施時，一定是不安全的，記憶體中的情況亦然如此，

所以執行緒安全指的是，在堆記憶體中的資料由于可以被任何執行緒訪問到，在沒有限制的情況下存在被意外修改的風險，

即堆記憶體空間在沒有保護機制的情況下，對多執行緒來說是不安全的地方，因為你放進去的資料，可能被別的執行緒“破壞”，

1.2 產生的原因

1. 多個執行緒執行的不確定性引起執行結果的不穩定，
2. 多個執行緒對資料的共享，會造成操作的不完整性，會破壞資料，

當多條陳述句在操作同一個執行緒共享資料時，一個執行緒對多條陳述句只執行了一部分，還沒有執行完，另一個執行緒參與進來執行，導致共享資料的錯誤，

1.3 實體（買票超賣問題）

/**
 * 例子：創建三個視窗賣票，總票數為100張.使用繼承Thread類的方式
 *
 * 存在執行緒的安全問題，待解決，
 */
class Window extends Thread{

    private static int ticket = 100;
    @Override
    public void run() {

        while(true){
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            if(ticket > 0){
                System.out.println(getName() + "：賣票，票號為：" + ticket);
                ticket--;
            }else{
                break;
            }
        }

    }
}

public class WindowTest {
    public static void main(String[] args) {
        Window t1 = new Window();
        Window t2 = new Window();
        Window t3 = new Window();

        t1.setName("視窗1");
        t2.setName("視窗2");
        t3.setName("視窗3");

        t1.start();
        t2.start();
        t3.start();

    }
}

結果

出現了共享資料錯誤

視窗2：賣票，票號為：100
視窗1：賣票，票號為：100
視窗3：賣票，票號為：98
視窗3：賣票，票號為：97
視窗2：賣票，票號為：97
視窗1：賣票，票號為：95
視窗1：賣票，票號為：94
視窗2：賣票，票號為：93
視窗3：賣票，票號為：92
視窗3：賣票，票號為：91
......
視窗1：賣票，票號為：10
視窗3：賣票，票號為：10
視窗2：賣票，票號為：10
視窗2：賣票，票號為：7
視窗3：賣票，票號為：7
視窗1：賣票，票號為：5
視窗3：賣票，票號為：4
視窗2：賣票，票號為：4
視窗1：賣票，票號為：2
視窗2：賣票，票號為：1
視窗3：賣票，票號為：1

分析

1. 問題：三條執行緒同時共享ticket的票，賣票程序中，出現了重票、錯票 -->出現了執行緒的安全問題，導致資料錯誤，
2. 原因：當某個執行緒操作車票的程序中，尚未操作完成時，其他執行緒參與進來，也操作車票，
3. 解決：當一個執行緒a在操作ticket的時候，其他執行緒不能參與進來，直到執行緒a操作完ticket時，其他執行緒才可以開始操作ticket，這種情況即使執行緒a出現了阻塞，也不能被改變，

1.4 如何確定是否存在執行緒安全問題？

• 明確哪些代碼是多執行緒運行的代碼
• 明確多個執行緒是否有共享資料
• 明確多執行緒運行代碼中是否有多條陳述句操作共享資料

2. 如何解決執行緒安全問題？

如何解決執行緒安全問題？解決的程序其實就是一個取舍的程序，不同的方案有不同的側重點，

2.1 不可變（Immutable）

不可變的物件一定是執行緒安全的，不需要采取任何的執行緒安全措施，只要一個不可變的物件被正確的構建出來，在多執行緒的狀態下也不允許修改，那么一定不會發生不一致的狀態，

形象比喻：只能看，不能摸，自然不會存在執行緒安全問題，

在多執行緒的環境下，應盡量是物件成為不可變的狀態，來滿足執行緒安全，這基本也是最小的開銷方式來保證執行緒安全，

不可變類的意思是創建該類的實體后，該實體的實體變數是不可改變的，

不可變的型別：

• String
• 列舉型別
• 基本資料型別的包裝類以及BigInteger 和 BigDecimal 等大資料型別
• final關鍵字修飾的基本資料型別

注：final修飾的參考資料型別不可變，但其成員變數的類可能會發生改變，

2.2 變數私有化

要保證執行緒安全，并不是一定就要進行同步，如果一個方法本來就不涉及共享資料，那它自然就無須任何同步措施去保證正確性，

2.2.1 堆疊封閉（主要為區域變數）

多個執行緒訪問同一個方法的區域變數時，不會出現執行緒安全問題，因為區域變數存盤在虛擬機堆疊中，屬于執行緒私有的，

形象比喻：私有的東西就不該讓別人知道，

如果一些資料只有某個執行緒會使用，其它執行緒不能操作也不需要操作，這些資料就可以放入執行緒的堆疊記憶體中，較為常見的就是區域變數，

double avgScore(double[] scores) {
    double sum = 0;
    for (double score : scores) {
        sum += score;
    }
    int count = scores.length;
    double avg = sum / count;
    return avg;
}

這里的變數sum，count，avg都是區域變數，它們都會被分配在執行緒堆疊記憶體中，

假如現在A執行緒來執行這個方法，這些變數會在A的堆疊記憶體分配，與此同時，B執行緒也來執行這個方法，這些變數也會在B的堆疊記憶體中分配，

也就是說這些區域變數會在每個執行緒的堆疊記憶體中都分配一份，由于執行緒的堆疊記憶體只能自己訪問，所以堆疊記憶體中的變數只屬于自己，其它執行緒根本就不知道，也就不存在執行緒安全問題，

問題：

不可能所有的變數都只宣告成區域變數，而只供某個執行緒使用，去解決執行緒安全問題，如果想要宣告成員變數，還想要保證執行緒安全怎么辦？

可以使用ThreadLocal，使每個執行緒都私有化一份這個變數的本地副本，互相不受影響，

2.2.2 執行緒本地存盤（Thread Local Storage）

如果一段代碼中所需要的資料必須與其他代碼共享，那就看看這些共享資料的代碼是否能保證在同一個執行緒中執行，如果能保證，我們就可以把共享資料的可見范圍限制在同一個執行緒之內，這樣，無須同步也能保證執行緒之間不出現資料爭用的問題，

可以使用java.lang.ThreadLocal類來實作執行緒本地存盤功能，

通俗來說：要讓公共區域堆記憶體中的資料對于每個執行緒都是安全的，那就每個執行緒都拷貝它一份，每個執行緒只處理自己的這一份拷貝而不去影響別的執行緒的，這不就安全了嘛，

形象比喻：大家不要搶，人人有份，

符合這種特點的應用并不少見，大部分使用消費佇列的架構模式（如“生產者-消費者”模式）都會將產品的消費程序盡量在一個執行緒中消費完，其中最重要的一個應用實體就是經典 Web 互動模型中的“一個請求對應一個服務器執行緒”（Thread-per-Request）的處理方式，這種處理方式的廣泛應用使得很多 Web 服務端應用都可以使用執行緒本地存盤來解決執行緒安全問題，

為了理解 ThreadLocal，先看以下代碼：

public class ThreadLocalExample1 {
    public static void main(String[] args) {
        ThreadLocal threadLocal1 = new ThreadLocal();
        ThreadLocal threadLocal2 = new ThreadLocal();
        Thread thread1 = new Thread(() -> {
            threadLocal1.set(1);
            threadLocal2.set(1);
        });
        Thread thread2 = new Thread(() -> {
            threadLocal1.set(2);
            threadLocal2.set(2);
        });
        thread1.start();
        thread2.start();
    }
}

它所對應的底層結構圖為:

ThreadLocal實體記憶體結構

每個 Thread 都有一個 ThreadLocal.ThreadLocalMap 物件，

/* ThreadLocal values pertaining to this thread. This map is maintained
 * by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;

當呼叫一個 ThreadLocal 的 set(T value) 方法時，先得到當前執行緒的 ThreadLocalMap 物件，然后將 ThreadLocal->value 鍵值對插入到該 Map 中，

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

get() 方法類似，

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

ThreadLocal 從理論上講并不是用來解決多執行緒并發問題的，因為根本不存在多執行緒競爭，ThreadLocal就是，把一個資料復制N份，每個執行緒認領一份，各玩各的，互不影響，

在一些場景 (尤其是使用執行緒池) 下，由于 ThreadLocal.ThreadLocalMap 的底層資料結構導致 ThreadLocal 有記憶體泄漏的情況，應該盡可能在每次使用 ThreadLocal 后手動呼叫 remove()，以避免出現 ThreadLocal 經典的記憶體泄漏甚至是造成自身業務混亂的風險，

2.3 互斥同步

前面給出的一些方案，有點“理想化”了，現實中的情況其實是非常混亂嘈雜的，沒有規則的，

形象比喻：沒有規則，那就先入為主，

例子：

比如在中午高峰期你去飯店吃飯，進門后發現只剩一個空桌子了，你心想先去點餐吧，回來就坐這里吧，當你點完餐回來后，發現已經被別人捷足先登了，

因為桌子是屬于公共區域的物品，任何人都可以坐，那就只能誰先搶到誰坐，雖然你在人群中曾多看了它一眼，但它并不會記住你容顏，

解決方法就不用我說了吧，讓一個人在那兒看著座位，其它人去點餐，這樣當別人再來的時候，你就可以理直氣壯的說，“不好意思，這個座位，我，已經占了”，

相信聰明的你已經猜到了我要說的東西了，沒錯，就是互斥鎖 ，

如果公共區域（堆記憶體）的資料，要被多個執行緒操作時，為了確保資料的安全（或一致）性，需要在資料旁邊放一把鎖，要想操作資料，先獲取鎖再說吧，

假設一個執行緒來到資料跟前一看，發現鎖是空閑的，沒有人持有，于是它就拿到了這把鎖，然后開始操作資料，

這時，又來了一個執行緒，發現鎖被別人持有著，按照規定，它不能操作資料，因為它無法得到這把鎖，當然，它可以選擇等待，或放棄，轉而去干別的，

因為第一個執行緒持有鎖，可以大膽干事而不用擔心其他執行緒的影響，

對于互斥同步鎖，可以使用synchronized 和 ReentrantLock，

class ClassAssistant {

    double totalScore = 60;
    final Lock lock = new Lock();

    void addScore(double score) {
        lock.obtain();
        totalScore += score;
        lock.release();
    }

    void subScore(double score) {
        lock.obtain();
        totalScore -= score;
        lock.release();
    }
}

假定一個班級的初始分數是60分，這個班級抽出10名學生來同時參加10個不同的答題節目，每個學生答對一次為班級加上5分，答錯一次減去5分，因為10個學生一起進行，所以這一定是一個并發情形，

因此加分和減分這兩個方法被并發的呼叫，它們共同操作總分數，為了保證資料的一致性，需要在每次操作前先獲取鎖，操作完成后再釋放鎖，

問題：

互斥阻塞會有執行緒阻塞和喚醒所帶來的性能問題，

2.4 非阻塞同步

互斥同步屬于一種悲觀的并發策略，總是認為只要不去做正確的同步措施，那就肯定會出現問題，無論共享資料是否真的會出現競爭，它都要進行加鎖（這里討論的是概念模型，實際上虛擬機會優化掉很大一部分不必要的加鎖）、用戶態核心態轉換、維護鎖計數器和檢查是否有被阻塞的執行緒需要喚醒等操作，

隨著硬體指令集的發展，我們可以使用基于沖突檢測的樂觀并發策略：先進行操作，如果沒有其它執行緒爭用共享資料，那操作就成功了，否則采取補償措施（不斷地重試，直到成功為止），這種樂觀的并發策略的許多實作都不需要將執行緒阻塞，因此這種同步操作稱為非阻塞同步，

形象比喻：相信世界充滿愛，即使被傷害，

由于無鎖操作中沒有鎖的存在，因此不可能出現死鎖的情況，也就是說樂觀鎖天生免疫死鎖 ，

樂觀鎖多用于“讀多寫少“的環境，避免頻繁加鎖影響性能；而悲觀鎖多用于”寫多讀少“的環境，避免頻繁失敗和重試影響性能，

2.4.1 CAS

例子解釋：

例子，假如你往地上仍1萬塊錢，是不是一定會丟呢？這要看情況了，如果是在人來人往的都市，可以說肯定會丟的，如果你跑到無人區扔地上，可以說肯定不會丟，

可以看到，都是把東西無保護的放到公共區域里，結果卻相差很大，這說明安全問題還和公共區域的環境狀況有關系，

比如我把資料放到公共區域的堆記憶體中，但是始終都只會有1個執行緒，也就是單執行緒模型，那這資料肯定是安全的，

再者說，2個執行緒操作同一個資料和200個執行緒操作同一個資料，這個資料的安全概率是完全不一樣的，肯定執行緒越多資料不安全的概率越大，執行緒越少資料不安全的概率越小，取個極限情況，那就是只有1個執行緒，那不安全概率就是0，也就是安全的，

因為鎖的獲取和釋放是要花費一定代價的，如果在執行緒數目特別少的時候，可能可能就不會有別的執行緒來操作資料，此時你還要獲取鎖和釋放鎖，可以說是一種浪費，

針對這種“地廣人稀”的情況，專門提出了一種方法，叫CAS，就是在并發很小的情況下，資料被意外修改的概率很低，但是又存在這種可能性，此時就用CAS，

CAS的全稱是：比較并交換（Compare And Swap），在CAS中，有這樣三個值：

• V：要更新的變數(var)——記憶體地址
• E：預期值(expected)——舊值
• N：新值(new)

比較并交換的程序如下：

判斷V是否等于E，如果等于，將V的值設定為N；如果不等，說明已經有其它執行緒更新了V，則當前執行緒放棄更新，什么都不做，

我們以一個簡單的例子來解釋這個程序：

1. 如果有一個多個執行緒共享的變數i原本等于5，我現在在執行緒A中，想把它設定為新的值6;
2. 我們使用CAS來做這個事情；
3. 首先我們用i去與5對比，發現它等于5，說明沒有被其它執行緒改過，那我就把它設定為新的值6，此次CAS成功，i的值被設定成了6；
4. 如果不等于5，說明i被其它執行緒改過了（比如現在i的值為2），那么我就什么也不做，此次CAS失敗，i的值仍然為2，

在這個例子中，i就是V，5就是E，6就是N，

那有沒有可能我在判斷了i為5之后，正準備更新它的新值的時候，被其它執行緒更改了i的值呢？

不會的，因為CAS是一種原子操作，它是一種系統原語，是一條CPU的原子指令，從CPU層面保證它的原子性，

CAS是一種原子操作，在Java中，有一個Unsafe類，它在sun.misc包中，它里面是一些native方法，其中就有幾個關于CAS的，他們都是public native的，

當多個執行緒同時使用CAS操作一個變數時，只有一個會勝出，并成功更新，其余均會失敗，但失敗的執行緒并不會被掛起，僅是被告知失敗，并且允許再次嘗試，當然也允許失敗的執行緒放棄操作，

ABA問題？(貍貓換太子)

因為CAS需要在操作值的時候，檢查值有沒有發生變化，如果沒有發生變化則更新，但是如果一個值原來是A，變成了B，又變成了A，那么使用CAS進行檢查時會發現它的值沒有發生變化，但是實際上卻變化了，那 CAS 操作就會誤認為它從來沒有被改變過，

ABA問題的解決思路就是使用版本號，在變數前面追加上版本號，每次變數更新的時候把版本號加1，那么A→B→A就會變成1A→2B→3A，

Java 1.5開始，JDK的Atomic包里提供了一個類AtomicStampedReference來解決ABA問題，這個類的compareAndSet方法的作用是首先檢查當前參考是否等于預期參考，并且檢查當前標志是否等于預期標志，如果全部相等，則以原子方式將該參考和該標志的值設定為給定的更新值，

2.4.2 Atomic（原子操作）

Unsafe類支持CAS的方法，那Java具體是如何使用這幾個方法來實作原子操作的呢？

JDK提供了一些用于原子操作的類，在java.util.concurrent.atomic包下面，在JDK 8中，有如下17個類：

從名字就可以看得出來這些類大概的用途：

• 原子更新基本型別
• 原子更新陣列
• 原子更新參考
• 原子更新欄位（屬性）

3. 總結和分析

“堆疊封閉”：找個只有自己知道的地方藏起來，當然安全了，

“ThreadLocal”：每人復制1份，各玩各的，互不影響，當然也安全了，

“不可變”：更狠了，直接規定，只能讀取，禁止修改，當然也安全了，

互斥同步和非阻塞同步，分別對應悲觀鎖和樂觀鎖的策略，

參考

• CS-Notes——Java并發
• 如果你這樣回答“什么是執行緒安全”，面試官都會對你刮目相看
• Java面向物件進階篇（包裝類，不可變類）