Java併發之AQS詳解

時間  2019-11-08
標籤 java 併發 aqs 詳解 欄目 Java 简体版
原文   原文鏈接

1、概述

談到併發，不得不談ReentrantLock；而談到ReentrantLock，不得不談AbstractQueuedSynchronized（AQS）！html

類如其名，抽象的隊列式的同步器，AQS定義了一套多線程訪問共享資源的同步器框架，許多同步類實現都依賴於它，如經常使用的ReentrantLock/Semaphore/CountDownLatch...。java

如下是本文的目錄大綱：node

  1. 概述
  2. 框架
  3. 源碼詳解
  4. 簡單應用

如有不正之處，請諒解和批評指正，不勝感激。編程

2、框架

它維護了一個volatile int state（表明共享資源）和一個FIFO線程等待隊列（多線程爭用資源被阻塞時會進入此隊列）。這裏volatile是核心關鍵詞，具體volatile的語義，在此不述。state的訪問方式有三種:安全

  • getState()
  • setState()
  • compareAndSetState()

AQS定義兩種資源共享方式：Exclusive（獨佔，只有一個線程能執行，如ReentrantLock）和Share（共享，多個線程可同時執行，如Semaphore/CountDownLatch）。多線程

不一樣的自定義同步器爭用共享資源的方式也不一樣。自定義同步器在實現時只須要實現共享資源state的獲取與釋放方式便可，至於具體線程等待隊列的維護（如獲取資源失敗入隊/喚醒出隊等），AQS已經在頂層實現好了。自定義同步器實現時主要實現如下幾種方法：併發

  • isHeldExclusively()：該線程是否正在獨佔資源。只有用到condition才須要去實現它。
  • tryAcquire(int)：獨佔方式。嘗試獲取資源，成功則返回true，失敗則返回false。
  • tryRelease(int)：獨佔方式。嘗試釋放資源，成功則返回true，失敗則返回false。
  • tryAcquireShared(int)：共享方式。嘗試獲取資源。負數表示失敗；0表示成功，但沒有剩餘可用資源；正數表示成功，且有剩餘資源。
  • tryReleaseShared(int)：共享方式。嘗試釋放資源，成功則返回true，失敗則返回false。

以ReentrantLock爲例，state初始化爲0，表示未鎖定狀態。A線程lock()時，會調用tryAcquire()獨佔該鎖並將state+1。此後，其餘線程再tryAcquire()時就會失敗，直到A線程unlock()到state=0（即釋放鎖）爲止，其它線程纔有機會獲取該鎖。固然，釋放鎖以前，A線程本身是能夠重複獲取此鎖的（state會累加），這就是可重入的概念。但要注意，獲取多少次就要釋放多麼次，這樣才能保證state是能回到零態的。框架

再以CountDownLatch以例，任務分爲N個子線程去執行，state也初始化爲N（注意N要與線程個數一致）。這N個子線程是並行執行的，每一個子線程執行完後countDown()一次，state會CAS減1。等到全部子線程都執行完後(即state=0)，會unpark()主調用線程，而後主調用線程就會從await()函數返回，繼續後餘動做。函數

通常來講，自定義同步器要麼是獨佔方法，要麼是共享方式，他們也只需實現tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一種便可。但AQS也支持自定義同步器同時實現獨佔和共享兩種方式，如ReentrantReadWriteLock。post

3、源碼詳解

本節開始講解AQS的源碼實現。依照acquire-release、acquireShared-releaseShared的次序來。

3.1 acquire(int)

此方法是獨佔模式下線程獲取共享資源的頂層入口。若是獲取到資源，線程直接返回，不然進入等待隊列，直到獲取到資源爲止，且整個過程忽略中斷的影響。這也正是lock()的語義，固然不只僅只限於lock()。獲取到資源後，線程就能夠去執行其臨界區代碼了。下面是acquire()的源碼：

public final void acquire(int arg) {
    if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
         selfInterrupt(); 
}

函數流程以下：

  1. tryAcquire()嘗試直接去獲取資源，若是成功則直接返回；
  2. addWaiter()將該線程加入等待隊列的尾部，並標記爲獨佔模式；
  3. acquireQueued()使線程在等待隊列中獲取資源，一直獲取到資源後才返回。若是在整個等待過程當中被中斷過，則返回true，不然返回false。
  4. 若是線程在等待過程當中被中斷過，它是不響應的。只是獲取資源後纔再進行自我中斷selfInterrupt()，將中斷補上。

這時單憑這4個抽象的函數來看流程還有點朦朧，沒關係，看完接下來的分析後，你就會明白了。就像《大話西遊》裏唐僧說的：等你明白了捨生取義的道理，你天然會回來和我唱這首歌的。

3.1.1 tryAcquire(int)

此方法嘗試去獲取獨佔資源。若是獲取成功，則直接返回true，不然直接返回false。這也正是tryLock()的語義，仍是那句話，固然不只僅只限於tryLock()。以下是tryAcquire()的源碼：

protected boolean tryAcquire(int arg) {
        throw new UnsupportedOperationException();
}

什麼？直接throw異常？說好的功能呢？好吧，還記得概述裏講的AQS只是一個框架，具體資源的獲取/釋放方式交由自定義同步器去實現嗎？就是這裏了！！！AQS這裏只定義了一個接口，具體資源的獲取交由自定義同步器去實現了（經過state的get/set/CAS）！！！至於能不能重入，能不能加塞，那就看具體的自定義同步器怎麼去設計了！！！固然，自定義同步器在進行資源訪問時要考慮線程安全的影響。

這裏之因此沒有定義成abstract，是由於獨佔模式下只用實現tryAcquire-tryRelease，而共享模式下只用實現tryAcquireShared-tryReleaseShared。若是都定義成abstract，那麼每一個模式也要去實現另外一模式下的接口。說到底，Doug Lea仍是站在我們開發者的角度，儘可能減小沒必要要的工做量。

3.1.2 addWaiter(Node)

此方法用於將當前線程加入到等待隊列的隊尾，並返回當前線程所在的結點。仍是上源碼吧：

private Node addWaiter(Node mode) {
    //以給定模式構造結點。mode有兩種：EXCLUSIVE（獨佔）和SHARED（共享）
    Node node = new Node(Thread.currentThread(), mode);
    
    //嘗試快速方式直接放到隊尾。
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    
    //上一步失敗則經過enq入隊。
    enq(node);
    return node;
}

 不用再說了，直接看註釋吧。

3.1.2.1 enq(Node)

此方法用於將node加入隊尾。源碼以下：

private Node enq(final Node node) {
    //CAS"自旋"，直到成功加入隊尾
    for (;;) {
        Node t = tail;
        if (t == null) { // 隊列爲空，建立一個空的標誌結點做爲head結點，並將tail也指向它。
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {//正常流程，放入隊尾
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

若是你看過AtomicInteger.getAndIncrement()函數源碼，那麼相信你一眼便看出這段代碼的精華。CAS自旋volatile變量，是一種很經典的用法。還不太瞭解的，本身去百度一下吧。

3.1.3 acquireQueued(Node, int)

OK，經過tryAcquire()和addWaiter()，該線程獲取資源失敗，已經被放入等待隊列尾部了。聰明的你馬上應該能想到該線程下一部該幹什麼了吧：進入等待狀態休息，直到其餘線程完全釋放資源後喚醒本身，本身再拿到資源，而後就能夠去幹本身想幹的事了。沒錯，就是這樣！是否是跟醫院排隊拿號有點類似~~acquireQueued()就是幹這件事：在等待隊列中排隊拿號（中間沒其它事幹能夠休息），直到拿到號後再返回。這個函數很是關鍵，仍是上源碼吧：

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;//標記是否成功拿到資源
    try {
        boolean interrupted = false;//標記等待過程當中是否被中斷過
        
        //又是一個「自旋」！
        for (;;) {
            final Node p = node.predecessor();//拿到前驅
            //若是前驅是head，即該結點已成老二，那麼便有資格去嘗試獲取資源（多是老大釋放完資源喚醒本身的，固然也可能被interrupt了）。
            if (p == head && tryAcquire(arg)) {
                setHead(node);//拿到資源後，將head指向該結點。因此head所指的標杆結點，就是當前獲取到資源的那個結點或null。
                p.next = null; // setHead中node.prev已置爲null，此處再將head.next置爲null，就是爲了方便GC回收之前的head結點。也就意味着以前拿完資源的結點出隊了！
                failed = false;
                return interrupted;//返回等待過程當中是否被中斷過
            }
            
            //若是本身能夠休息了，就進入waiting狀態，直到被unpark()
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;//若是等待過程當中被中斷過，哪怕只有那麼一次，就將interrupted標記爲true
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

到這裏了，咱們先不急着總結acquireQueued()的函數流程，先看看shouldParkAfterFailedAcquire()和parkAndCheckInterrupt()具體幹些什麼。

3.1.3.1 shouldParkAfterFailedAcquire(Node, Node)

此方法主要用於檢查狀態，看看本身是否真的能夠去休息了（進入waiting狀態，若是線程狀態轉換不熟，能夠參考本人上一篇寫的Thread詳解），萬一隊列前邊的線程都放棄了只是瞎站着，那也說不定，對吧！

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;//拿到前驅的狀態
    if (ws == Node.SIGNAL)
        //若是已經告訴前驅拿完號後通知本身一下，那就能夠安心休息了
        return true;
    if (ws > 0) {
        /*
         * 若是前驅放棄了，那就一直往前找，直到找到最近一個正常等待的狀態，並排在它的後邊。
         * 注意：那些放棄的結點，因爲被本身「加塞」到它們前邊，它們至關於造成一個無引用鏈，稍後就會被保安大叔趕走了(GC回收)！
         */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
         //若是前驅正常，那就把前驅的狀態設置成SIGNAL，告訴它拿完號後通知本身一下。有可能失敗，人家說不定剛剛釋放完呢！
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

整個流程中，若是前驅結點的狀態不是SIGNAL，那麼本身就不能安心去休息，須要去找個安心的休息點，同時能夠再嘗試下看有沒有機會輪到本身拿號。

3.1.3.2 parkAndCheckInterrupt()

若是線程找好安全休息點後，那就能夠安心去休息了。此方法就是讓線程去休息，真正進入等待狀態。

private final boolean parkAndCheckInterrupt() {
     LockSupport.park(this);//調用park()使線程進入waiting狀態
     return Thread.interrupted();//若是被喚醒，查看本身是否是被中斷的。
}

park()會讓當前線程進入waiting狀態。在此狀態下，有兩種途徑能夠喚醒該線程：1）被unpark()；2）被interrupt()。（再說一句，若是線程狀態轉換不熟，能夠參考本人寫的Thread詳解）。須要注意的是，Thread.interrupted()會清除當前線程的中斷標記位。 

3.1.3.3 小結

OK，看了shouldParkAfterFailedAcquire()和parkAndCheckInterrupt()，如今讓咱們再回到acquireQueued()，總結下該函數的具體流程：

  1. 結點進入隊尾後，檢查狀態，找到安全休息點；
  2. 調用park()進入waiting狀態，等待unpark()或interrupt()喚醒本身；
  3. 被喚醒後，看本身是否是有資格能拿到號。若是拿到，head指向當前結點，並返回從入隊到拿到號的整個過程當中是否被中斷過；若是沒拿到，繼續流程1。

 

3.1.4 小結

acquireQueued()分析完以後，咱們接下來再回到acquire()！再貼上它的源碼吧：

public final void acquire(int arg) {
     if (!tryAcquire(arg) &&
         acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
         selfInterrupt();
}

再來總結下它的流程吧：

  1. 調用自定義同步器的tryAcquire()嘗試直接去獲取資源，若是成功則直接返回；
  2. 沒成功，則addWaiter()將該線程加入等待隊列的尾部，並標記爲獨佔模式；
  3. acquireQueued()使線程在等待隊列中休息，有機會時（輪到本身，會被unpark()）會去嘗試獲取資源。獲取到資源後才返回。若是在整個等待過程當中被中斷過，則返回true，不然返回false。
  4. 若是線程在等待過程當中被中斷過，它是不響應的。只是獲取資源後纔再進行自我中斷selfInterrupt()，將中斷補上。

因爲此函數是重中之重，我再用流程圖總結一下：

至此，acquire()的流程終於算是告一段落了。這也就是ReentrantLock.lock()的流程，不信你去看其lock()源碼吧，整個函數就是一條acquire(1)！！！

 

3.2 release(int)

上一小節已經把acquire()說完了，這一小節就來說講它的反操做release()吧。此方法是獨佔模式下線程釋放共享資源的頂層入口。它會釋放指定量的資源，若是完全釋放了（即state=0）,它會喚醒等待隊列裏的其餘線程來獲取資源。這也正是unlock()的語義，固然不只僅只限於unlock()。下面是release()的源碼：

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;//找到頭結點
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);//喚醒等待隊列裏的下一個線程
        return true;
    }
    return false;
} 

邏輯並不複雜。它調用tryRelease()來釋放資源。有一點須要注意的是，它是根據tryRelease()的返回值來判斷該線程是否已經完成釋放掉資源了！因此自定義同步器在設計tryRelease()的時候要明確這一點！！

3.2.1 tryRelease(int)

此方法嘗試去釋放指定量的資源。下面是tryRelease()的源碼：

protected boolean tryRelease(int arg) {
     throw new UnsupportedOperationException();
}

跟tryAcquire()同樣，這個方法是須要獨佔模式的自定義同步器去實現的。正常來講，tryRelease()都會成功的，由於這是獨佔模式，該線程來釋放資源，那麼它確定已經拿到獨佔資源了，直接減掉相應量的資源便可(state-=arg)，也不須要考慮線程安全的問題。但要注意它的返回值，上面已經提到了，release()是根據tryRelease()的返回值來判斷該線程是否已經完成釋放掉資源了！因此自義定同步器在實現時，若是已經完全釋放資源(state=0)，要返回true，不然返回false。

3.2.2 unparkSuccessor(Node)

此方法用於喚醒等待隊列中下一個線程。下面是源碼：

private void unparkSuccessor(Node node) {
    //這裏，node通常爲當前線程所在的結點。
    int ws = node.waitStatus;
    if (ws < 0)//置零當前線程所在的結點狀態，容許失敗。
        compareAndSetWaitStatus(node, ws, 0);

    Node s = node.next;//找到下一個須要喚醒的結點s
    if (s == null || s.waitStatus > 0) {//若是爲空或已取消
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)//從這裏能夠看出，<=0的結點，都是還有效的結點。
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);//喚醒
}

這個函數並不複雜。一句話歸納：用unpark()喚醒等待隊列中最前邊的那個未放棄線程，這裏咱們也用s來表示吧。此時，再和acquireQueued()聯繫起來，s被喚醒後，進入if (p == head && tryAcquire(arg))的判斷（即便p!=head也不要緊，它會再進入shouldParkAfterFailedAcquire()尋找一個安全點。這裏既然s已是等待隊列中最前邊的那個未放棄線程了，那麼經過shouldParkAfterFailedAcquire()的調整，s也必然會跑到head的next結點，下一次自旋p==head就成立啦），而後s把本身設置成head標杆結點，表示本身已經獲取到資源了，acquire()也返回了！！And then, DO what you WANT!

3.2.3 小結

release()是獨佔模式下線程釋放共享資源的頂層入口。它會釋放指定量的資源，若是完全釋放了（即state=0）,它會喚醒等待隊列裏的其餘線程來獲取資源。

3.3 acquireShared(int)

此方法是共享模式下線程獲取共享資源的頂層入口。它會獲取指定量的資源，獲取成功則直接返回，獲取失敗則進入等待隊列，直到獲取到資源爲止，整個過程忽略中斷。下面是acquireShared()的源碼：

public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
         doAcquireShared(arg);
}

這裏tryAcquireShared()依然須要自定義同步器去實現。可是AQS已經把其返回值的語義定義好了：負值表明獲取失敗；0表明獲取成功，但沒有剩餘資源；正數表示獲取成功，還有剩餘資源，其餘線程還能夠去獲取。因此這裏acquireShared()的流程就是：

  1. tryAcquireShared()嘗試獲取資源，成功則直接返回；
  2. 失敗則經過doAcquireShared()進入等待隊列，直到獲取到資源爲止才返回。

3.3.1 doAcquireShared(int)

此方法用於將當前線程加入等待隊列尾部休息，直到其餘線程釋放資源喚醒本身，本身成功拿到相應量的資源後才返回。下面是doAcquireShared()的源碼：

private void doAcquireShared(int arg) {
    final Node node = addWaiter(Node.SHARED);//加入隊列尾部
    boolean failed = true;//是否成功標誌
    try {
        boolean interrupted = false;//等待過程當中是否被中斷過的標誌
        for (;;) {
            final Node p = node.predecessor();//前驅
            if (p == head) {//若是到head的下一個，由於head是拿到資源的線程，此時node被喚醒，極可能是head用完資源來喚醒本身的
                int r = tryAcquireShared(arg);//嘗試獲取資源
                if (r >= 0) {//成功
                    setHeadAndPropagate(node, r);//將head指向本身，還有剩餘資源能夠再喚醒以後的線程
                    p.next = null; // help GC
                    if (interrupted)//若是等待過程當中被打斷過，此時將中斷補上。
                        selfInterrupt();
                    failed = false;
                    return;
                }
            }
            
            //判斷狀態，尋找安全點，進入waiting狀態，等着被unpark()或interrupt()
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

有木有以爲跟acquireQueued()很類似？對，其實流程並無太大區別。只不過這裏將補中斷的selfInterrupt()放到doAcquireShared()裏了，而獨佔模式是放到acquireQueued()以外，其實都同樣，不知道Doug Lea是怎麼想的。

跟獨佔模式比，還有一點須要注意的是，這裏只有線程是head.next時（「老二」），纔會去嘗試獲取資源，有剩餘的話還會喚醒以後的隊友。那麼問題就來了，假如老大用完後釋放了5個資源，而老二須要6個，老三須要1個，老四須要2個。由於老大先喚醒老二，老二一看資源不夠本身用繼續park()，也更不會去喚醒老三和老四了。獨佔模式，同一時刻只有一個線程去執行，這樣作何嘗不可；但共享模式下，多個線程是能夠同時執行的，如今由於老二的資源需求量大，而把後面量小的老三和老四也都卡住了。

 

3.3.1.1 setHeadAndPropagate(Node, int)

private void setHeadAndPropagate(Node node, int propagate) {
    Node h = head; 
    setHead(node);//head指向本身
     //若是還有剩餘量，繼續喚醒下一個鄰居線程
    if (propagate > 0 || h == null || h.waitStatus < 0) {
        Node s = node.next;
        if (s == null || s.isShared())
            doReleaseShared();
    }
}

此方法在setHead()的基礎上多了一步，就是本身甦醒的同時，若是條件符合（好比還有剩餘資源），還會去喚醒後繼結點，畢竟是共享模式！

doReleaseShared()咱們留着下一小節的releaseShared()裏來說。

 

3.3.2 小結

OK，至此，acquireShared()也要告一段落了。讓咱們再梳理一下它的流程：

  1. tryAcquireShared()嘗試獲取資源，成功則直接返回；
  2. 失敗則經過doAcquireShared()進入等待隊列park()，直到被unpark()/interrupt()併成功獲取到資源才返回。整個等待過程也是忽略中斷的。

　　其實跟acquire()的流程大同小異，只不過多了個本身拿到資源後，還會去喚醒後繼隊友的操做（這纔是共享嘛）。

3.4 releaseShared()

上一小節已經把acquireShared()說完了，這一小節就來說講它的反操做releaseShared()吧。此方法是共享模式下線程釋放共享資源的頂層入口。它會釋放指定量的資源，若是完全釋放了（即state=0）,它會喚醒等待隊列裏的其餘線程來獲取資源。下面是releaseShared()的源碼：

public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {//嘗試釋放資源
        doReleaseShared();//喚醒後繼結點
        return true;
    }
    return false;
}

此方法的流程也比較簡單，一句話：釋放掉資源後，喚醒後繼。跟獨佔模式下的release()類似，但有一點稍微須要注意：獨佔模式下的tryRelease()在徹底釋放掉資源（state=0）後，纔會返回true去喚醒其餘線程，這主要是基於可重入的考量；而共享模式下的releaseShared()則沒有這種要求，一是共享的實質--多線程可併發執行；二是共享模式基本也不會重入吧（至少我還沒見過），因此自定義同步器能夠根據須要決定返回值。

3.4.1 doReleaseShared()

此方法主要用於喚醒後繼。下面是它的源碼：

private void doReleaseShared() {
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;
                unparkSuccessor(h);//喚醒後繼
            }
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;
        }
        if (h == head)// head發生變化
            break;
    }
}

3.5 小結

本節咱們詳解了獨佔和共享兩種模式下獲取-釋放資源(acquire-release、acquireShared-releaseShared)的源碼，相信你們都有必定認識了。值得注意的是，acquire()和acquireSahred()兩種方法下，線程在等待隊列中都是忽略中斷的。AQS也支持響應中斷的，acquireInterruptibly()/acquireSharedInterruptibly()便是，這裏相應的源碼跟acquire()和acquireSahred()差很少，這裏就再也不詳解了。

4、簡單應用

經過前邊幾個章節的學習，相信你們已經基本理解AQS的原理了。這裏再將「框架」一節中的一段話複製過來：

不一樣的自定義同步器爭用共享資源的方式也不一樣。自定義同步器在實現時只須要實現共享資源state的獲取與釋放方式便可，至於具體線程等待隊列的維護（如獲取資源失敗入隊/喚醒出隊等），AQS已經在頂層實現好了。自定義同步器實現時主要實現如下幾種方法：

  • isHeldExclusively()：該線程是否正在獨佔資源。只有用到condition才須要去實現它。
  • tryAcquire(int)：獨佔方式。嘗試獲取資源，成功則返回true，失敗則返回false。
  • tryRelease(int)：獨佔方式。嘗試釋放資源，成功則返回true，失敗則返回false。
  • tryAcquireShared(int)：共享方式。嘗試獲取資源。負數表示失敗；0表示成功，但沒有剩餘可用資源；正數表示成功，且有剩餘資源。
  • tryReleaseShared(int)：共享方式。嘗試釋放資源，成功則返回true，失敗則返回false。

　　OK，下面咱們就以AQS源碼裏的Mutex爲例，講一下AQS的簡單應用。

4.1 Mutex（互斥鎖）

Mutex是一個不可重入的互斥鎖實現。鎖資源（AQS裏的state）只有兩種狀態：0表示未鎖定，1表示鎖定。下邊是Mutex的核心源碼：

class Mutex implements Lock, java.io.Serializable {
    // 自定義同步器
    private static class Sync extends AbstractQueuedSynchronizer {
        // 判斷是否鎖定狀態
        protected boolean isHeldExclusively() {
            return getState() == 1;
        }

        // 嘗試獲取資源，當即返回。成功則返回true，不然false。
        public boolean tryAcquire(int acquires) {
            assert acquires == 1; // 這裏限定只能爲1個量
            if (compareAndSetState(0, 1)) {//state爲0才設置爲1，不可重入！
                setExclusiveOwnerThread(Thread.currentThread());//設置爲當前線程獨佔資源
                return true;
            }
            return false;
        }

        // 嘗試釋放資源，當即返回。成功則爲true，不然false。
        protected boolean tryRelease(int releases) {
            assert releases == 1; // 限定爲1個量
            if (getState() == 0)//既然來釋放，那確定就是已佔有狀態了。只是爲了保險，多層判斷！
                throw new IllegalMonitorStateException();
            setExclusiveOwnerThread(null);
            setState(0);//釋放資源，放棄佔有狀態
            return true;
        }
    }

    // 真正同步類的實現都依賴繼承於AQS的自定義同步器！
    private final Sync sync = new Sync();

    //lock<-->acquire。二者語義同樣：獲取資源，即使等待，直到成功才返回。
    public void lock() {
        sync.acquire(1);
    }

    //tryLock<-->tryAcquire。二者語義同樣：嘗試獲取資源，要求當即返回。成功則爲true，失敗則爲false。
    public boolean tryLock() {
        return sync.tryAcquire(1);
    }

    //unlock<-->release。二者語文同樣：釋放資源。
    public void unlock() {
        sync.release(1);
    }

    //鎖是否佔有狀態
    public boolean isLocked() {
        return sync.isHeldExclusively();
    }
}

同步類在實現時通常都將自定義同步器（sync）定義爲內部類，供本身使用；而同步類本身（Mutex）則實現某個接口，對外服務。固然，接口的實現要直接依賴sync，它們在語義上也存在某種對應關係！！而sync只用實現資源state的獲取-釋放方式tryAcquire-tryRelelase，至於線程的排隊、等待、喚醒等，上層的AQS都已經實現好了，咱們不用關心。

除了Mutex，ReentrantLock/CountDownLatch/Semphore這些同步類的實現方式都差很少，不一樣的地方就在獲取-釋放資源的方式tryAcquire-tryRelelase。掌握了這點，AQS的核心便被攻破了！

OK，至此，整個AQS的講解也要落下帷幕了。但願本文可以對學習Java併發編程的同窗有所借鑑，中間寫的有不對的地方，也歡迎討論和指正~

 

原文連接：http://www.cnblogs.com/waterystone/p/4920797.html

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程