面試必備之深刻理解自旋鎖

時間 2019-12-04

原文原文鏈接

分享一個我本身總結的Java學習的系統知識點以及面試問題，目前已經開源，會一直完善下去，歡迎建議和指導歡迎Star： https://github.com/Snailclimb/Java-Guidephp

本文出自：
http://blog.onlycatch.com/post/自旋鎖
我對原文作了一點補充與修改，我以爲這篇文章寫的很是很是好。深刻學習，不光能夠深刻掌握自旋鎖，可能提升本身的編程思想。原文做者對於自旋鎖的思考很棒，爲他點個贊。html

在個人上一篇文章：《面試必備之樂觀鎖與悲觀鎖》已經爲你們對比了樂觀鎖與悲觀鎖。咱們知道CAS算法是樂觀鎖的一種實現方式，CAS算法中又涉及到自旋鎖，因此這裏給你們講一下什麼是自旋鎖。java

簡單回顧一下CAS算法

CAS算法 即compare and swap（比較與交換），是一種有名的無鎖算法。無鎖編程，即不使用鎖的狀況下實現多線程之間的變量同步，也就是在沒有線程被阻塞的狀況下實現變量的同步，因此也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三個操做數node

須要讀寫的內存值 V
進行比較的值 A
擬寫入的新值 B

當且僅當 V 的值等於 A時，CAS經過原子方式用新值B來更新V的值，不然不會執行任何操做（比較和替換是一個原子操做）。通常狀況下是一個<font color="red">自旋操做</font>，即不斷的重試。git

什麼是自旋鎖？

<font color="red">自旋鎖（spinlock）</font>：是指當一個線程在獲取鎖的時候，若是鎖已經被其它線程獲取，那麼該線程將循環等待，而後不斷的判斷鎖是否可以被成功獲取，直到獲取到鎖纔會退出循環。 github

獲取鎖的線程一直處於活躍狀態，可是並無執行任何有效的任務，使用這種鎖會形成busy-waiting。面試

它是爲實現保護共享資源而提出一種鎖機制。其實，自旋鎖與互斥鎖比較相似，它們都是爲了解決對某項資源的互斥使用。不管是互斥鎖，仍是自旋鎖，在任什麼時候刻，最多隻能有一個保持者，也就說，在任什麼時候刻最多隻能有一個執行單元得到鎖。可是二者在調度機制上略有不一樣。對於互斥鎖，若是資源已經被佔用，資源申請者只能進入睡眠狀態。可是自旋鎖不會引發調用者睡眠，若是自旋鎖已經被別的執行單元保持，調用者就一直循環在那裏看是否該自旋鎖的保持者已經釋放了鎖，"自旋"一詞就是所以而得名。算法

Java如何實現自旋鎖？

下面是個簡單的例子：編程

public class SpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    public void lock() {
        Thread current = Thread.currentThread();
        // 利用CAS
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread current = Thread.currentThread();
        cas.compareAndSet(current, null);
    }
}

lock（)方法利用的CAS，當第一個線程A獲取鎖的時候，可以成功獲取到，不會進入while循環，若是此時線程A沒有釋放鎖，另外一個線程B又來獲取鎖，此時因爲不知足CAS，因此就會進入while循環，不斷判斷是否知足CAS，直到A線程調用unlock方法釋放了該鎖。緩存

自旋鎖存在的問題

若是某個線程持有鎖的時間過長，就會致使其它等待獲取鎖的線程進入循環等待，消耗CPU。使用不當會形成CPU使用率極高。
上面Java實現的自旋鎖不是公平的，即沒法知足等待時間最長的線程優先獲取鎖。不公平的鎖就會存在「線程飢餓」問題。

自旋鎖的優勢

自旋鎖不會使線程狀態發生切換，一直處於用戶態，即線程一直都是active的；不會使線程進入阻塞狀態，減小了沒必要要的上下文切換，執行速度快
非自旋鎖在獲取不到鎖的時候會進入阻塞狀態，從而進入內核態，當獲取到鎖的時候須要從內核態恢復，須要線程上下文切換。（線程被阻塞後便進入內核（Linux）調度狀態，這個會致使系統在用戶態與內核態之間來回切換，嚴重影響鎖的性能）

可重入的自旋鎖和不可重入的自旋鎖

文章開始的時候的那段代碼，仔細分析一下就能夠看出，它是不支持重入的，即當一個線程第一次已經獲取到了該鎖，在鎖釋放以前又一次從新獲取該鎖，第二次就不能成功獲取到。因爲不知足CAS，因此第二次獲取會進入while循環等待，而若是是可重入鎖，第二次也是應該可以成功獲取到的。

並且，即便第二次可以成功獲取，那麼當第一次釋放鎖的時候，第二次獲取到的鎖也會被釋放，而這是不合理的。

爲了實現可重入鎖，咱們須要引入一個計數器，用來記錄獲取鎖的線程數。

public class ReentrantSpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    private int count;
    public void lock() {
        Thread current = Thread.currentThread();
        if (current == cas.get()) { // 若是當前線程已經獲取到了鎖，線程數增長一，而後返回
            count++;
            return;
        }
        // 若是沒獲取到鎖，則經過CAS自旋
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread cur = Thread.currentThread();
        if (cur == cas.get()) {
            if (count > 0) {// 若是大於0，表示當前線程屢次獲取了該鎖，釋放鎖經過count減一來模擬
                count--;
            } else {// 若是count==0，能夠將鎖釋放，這樣就能保證獲取鎖的次數與釋放鎖的次數是一致的了。
                cas.compareAndSet(cur, null);
            }
        }
    }
}

自旋鎖的其餘變種

1. TicketLock

TicketLock主要解決的是公平性的問題。

思路：每當有線程獲取鎖的時候，就給該線程分配一個遞增的id，咱們稱之爲排隊號，同時，鎖對應一個服務號，每當有線程釋放鎖，服務號就會遞增，此時若是服務號與某個線程排隊號一致，那麼該線程就得到鎖，因爲排隊號是遞增的，因此就保證了最早請求獲取鎖的線程能夠最早獲取到鎖，就實現了公平性。

能夠想象成銀行辦理業務排隊，排隊的每個顧客都表明一個須要請求鎖的線程，而銀行服務窗口表示鎖，每當有窗口服務完成就把本身的服務號加一，此時在排隊的全部顧客中，只有本身的排隊號與服務號一致的才能夠獲得服務。

實現代碼：

public class TicketLock {
    /**
     * 服務號
     */
    private AtomicInteger serviceNum = new AtomicInteger();
    /**
     * 排隊號
     */
    private AtomicInteger ticketNum = new AtomicInteger();
    /**
     * lock:獲取鎖，若是獲取成功，返回當前線程的排隊號，獲取排隊號用於釋放鎖. <br/>
     *
     * @return
     */
    public int lock() {
        int currentTicketNum = ticketNum.incrementAndGet();
        while (currentTicketNum != serviceNum.get()) {
            // Do nothing
        }
        return currentTicketNum;
    }
    /**
     * unlock:釋放鎖，傳入當前持有鎖的線程的排隊號 <br/>
     *
     * @param ticketnum
     */
    public void unlock(int ticketnum) {
        serviceNum.compareAndSet(ticketnum, ticketnum + 1);
    }
}

上面的實現方式是，線程獲取鎖以後，將它的排隊號返回，等該線程釋放鎖的時候，須要將該排隊號傳入。但這樣是有風險的，由於這個排隊號是能夠被修改的，一旦排隊號被不當心修改了，那麼鎖將不能被正確釋放。一種更好的實現方式以下：

public class TicketLockV2 {
    /**
     * 服務號
     */
    private AtomicInteger serviceNum = new AtomicInteger();
    /**
     * 排隊號
     */
    private AtomicInteger ticketNum = new AtomicInteger();
    /**
     * 新增一個ThreadLocal，用於存儲每一個線程的排隊號
     */
    private ThreadLocal<Integer> ticketNumHolder = new ThreadLocal<Integer>();
    public void lock() {
        int currentTicketNum = ticketNum.incrementAndGet();
        // 獲取鎖的時候，將當前線程的排隊號保存起來
        ticketNumHolder.set(currentTicketNum);
        while (currentTicketNum != serviceNum.get()) {
            // Do nothing
        }
    }
    public void unlock() {
        // 釋放鎖，從ThreadLocal中獲取當前線程的排隊號
        Integer currentTickNum = ticketNumHolder.get();
        serviceNum.compareAndSet(currentTickNum, currentTickNum + 1);
    }
}

上面的實現方式是將每一個線程的排隊號放到了ThreadLocal中。

TicketLock存在的問題:

多處理器系統上，每一個進程/線程佔用的處理器都在讀寫同一個變量serviceNum ，每次讀寫操做都必須在多個處理器緩存之間進行緩存同步，這會致使繁重的系統總線和內存的流量，大大下降系統總體的性能。

下面介紹的MCSLock和CLHLock就是解決這個問題的。

2. CLHLock

CLH鎖是一種基於鏈表的可擴展、高性能、公平的自旋鎖，申請線程只在本地變量上自旋，它不斷輪詢前驅的狀態，若是發現前驅釋放了鎖就結束自旋，得到鎖。

實現代碼以下：

import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
/**
 * CLH的發明人是：Craig，Landin and Hagersten。
 * 代碼來源：http://ifeve.com/java_lock_see2/
 */
public class CLHLock {
    /**
     * 定義一個節點，默認的lock狀態爲true
     */
    public static class CLHNode {
        private volatile boolean isLocked = true;
    }
    /**
     * 尾部節點,只用一個節點便可
     */
    private volatile CLHNode tail;
    private static final ThreadLocal<CLHNode> LOCAL = new ThreadLocal<CLHNode>();
    private static final AtomicReferenceFieldUpdater<CLHLock, CLHNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(CLHLock.class, CLHNode.class,
            "tail");
    public void lock() {
        // 新建節點並將節點與當前線程保存起來
        CLHNode node = new CLHNode();
        LOCAL.set(node);
        // 將新建的節點設置爲尾部節點，並返回舊的節點（原子操做），這裏舊的節點實際上就是當前節點的前驅節點
        CLHNode preNode = UPDATER.getAndSet(this, node);
        if (preNode != null) {
            // 前驅節點不爲null表示當鎖被其餘線程佔用，經過不斷輪詢判斷前驅節點的鎖標誌位等待前驅節點釋放鎖
            while (preNode.isLocked) {
            }
            preNode = null;
            LOCAL.set(node);
        }
        // 若是不存在前驅節點，表示該鎖沒有被其餘線程佔用，則當前線程得到鎖
    }
    public void unlock() {
        // 獲取當前線程對應的節點
        CLHNode node = LOCAL.get();
        // 若是tail節點等於node，則將tail節點更新爲null，同時將node的lock狀態職位false，表示當前線程釋放了鎖
        if (!UPDATER.compareAndSet(this, node, null)) {
            node.isLocked = false;
        }
        node = null;
    }
}

3. MCSLock

MCSLock則是對本地變量的節點進行循環。

/**
 * MCS:發明人名字John Mellor-Crummey和Michael Scott
 * 代碼來源：http://ifeve.com/java_lock_see2/
 */
public class MCSLock {
    /**
     * 節點，記錄當前節點的鎖狀態以及後驅節點
     */
    public static class MCSNode {
        volatile MCSNode next;
        volatile boolean isLocked = true;
    }
    private static final ThreadLocal<MCSNode> NODE = new ThreadLocal<MCSNode>();
    // 隊列
    @SuppressWarnings("unused")
    private volatile MCSNode queue;
    // queue更新器
    private static final AtomicReferenceFieldUpdater<MCSLock, MCSNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(MCSLock.class, MCSNode.class,
            "queue");
    public void lock() {
        // 建立節點並保存到ThreadLocal中
        MCSNode currentNode = new MCSNode();
        NODE.set(currentNode);
        // 將queue設置爲當前節點，而且返回以前的節點
        MCSNode preNode = UPDATER.getAndSet(this, currentNode);
        if (preNode != null) {
            // 若是以前節點不爲null，表示鎖已經被其餘線程持有
            preNode.next = currentNode;
            // 循環判斷，直到當前節點的鎖標誌位爲false
            while (currentNode.isLocked) {
            }
        }
    }
    public void unlock() {
        MCSNode currentNode = NODE.get();
        // next爲null表示沒有正在等待獲取鎖的線程
        if (currentNode.next == null) {
            // 更新狀態並設置queue爲null
            if (UPDATER.compareAndSet(this, currentNode, null)) {
                // 若是成功了，表示queue==currentNode,即當前節點後面沒有節點了
                return;
            } else {
                // 若是不成功，表示queue!=currentNode,即當前節點後面多了一個節點，表示有線程在等待
                // 若是當前節點的後續節點爲null，則須要等待其不爲null（參考加鎖方法）
                while (currentNode.next == null) {
                }
            }
        } else {
            // 若是不爲null，表示有線程在等待獲取鎖，此時將等待線程對應的節點鎖狀態更新爲false，同時將當前線程的後繼節點設爲null
            currentNode.next.isLocked = false;
            currentNode.next = null;
        }
    }
}

4. CLHLock 和 MCSLock

都是基於鏈表，不一樣的是CLHLock是基於隱式鏈表，沒有真正的後續節點屬性，MCSLock是顯示鏈表，有一個指向後續節點的屬性。
將獲取鎖的線程狀態藉助節點(node)保存,每一個線程都有一份獨立的節點，這樣就解決了TicketLock多處理器緩存同步的問題。

自旋鎖與互斥鎖

自旋鎖與互斥鎖都是爲了實現保護資源共享的機制。
不管是自旋鎖仍是互斥鎖，在任意時刻，都最多隻能有一個保持者。
獲取互斥鎖的線程，若是鎖已經被佔用，則該線程將進入睡眠狀態；獲取自旋鎖的線程則不會睡眠，而是一直循環等待鎖釋放。

總結：

自旋鎖：線程獲取鎖的時候，若是鎖被其餘線程持有，則當前線程將循環等待，直到獲取到鎖。
自旋鎖等待期間，線程的狀態不會改變，線程一直是用戶態而且是活動的(active)。
自旋鎖若是持有鎖的時間太長，則會致使其它等待獲取鎖的線程耗盡CPU。
自旋鎖自己沒法保證公平性，同時也沒法保證可重入性。
基於自旋鎖，能夠實現具有公平性和可重入性質的鎖。
TicketLock:採用相似銀行排號叫好的方式實現自旋鎖的公平性，可是因爲不停的讀取serviceNum，每次讀寫操做都必須在多個處理器緩存之間進行緩存同步，這會致使繁重的系統總線和內存的流量，大大下降系統總體的性能。
CLHLock和MCSLock經過鏈表的方式避免了減小了處理器緩存同步，極大的提升了性能，區別在於CLHLock是經過輪詢其前驅節點的狀態，而MCS則是查看當前節點的鎖狀態。
CLHLock在NUMA架構下使用會存在問題。在沒有cache的NUMA系統架構中，因爲CLHLock是在當前節點的前一個節點上自旋,NUMA架構中處理器訪問本地內存的速度高於經過網絡訪問其餘節點的內存，因此CLHLock在NUMA架構上不是最優的自旋鎖。