難以理解的AQS（下）

在上一篇博客，簡單的說下了AQS的基本概念，核心源碼解析，但是還有一部分內容沒有涉及到，就是AQS對條件變量的支持，這篇博客將着重介紹這方面的內容。

條件變量

基本應用

我們先通過模擬一個消費者/生產者模型來看下條件變量的基本應用：

當有數據的時候，生產者停止生產數據，通知消費者消費數據；
當沒有數據的時候，消費者停止消費數據，通知生產者生產數據；

public class CommonResource {
    private boolean isHaveData = false;

    Lock lock = new ReentrantLock();

    Condition producer_con = lock.newCondition();
    Condition consumer_con = lock.newCondition();

    public void product() {
        lock.lock();
        try {
            while (isHaveData) {
                try {
                    System.out.println("還有數據，等待消費數據");
                    producer_con.await();
                } catch (InterruptedException e) {
                }
            }
            System.out.println("生產者生產數據了");
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            isHaveData = true;
            consumer_con.signal();
        } finally {
            lock.unlock();
        }
    }

    public void consume() {
        lock.lock();
        try {
            while (!isHaveData) {
                try {
                    System.out.println("沒有數據了，等待生產者消費數據");
                    consumer_con.await();
                } catch (InterruptedException e) {
                }
            }
            System.out.println("消費者消費數據");
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            isHaveData = false;
            producer_con.signal();
        } finally {
            lock.unlock();
        }
    }
}

public class Main {
    public static void main(String[] args) {
        CommonResource resource = new CommonResource();
        new Thread(() -> {
            while (true) {
                resource.product();
            }
        }).start();

        new Thread(() -> {
            while (true) {
                resource.consume();
            }
        }).start();
    }
}

運行結果：

這就是條件變量的應用，第一反應是不是和object中的wait/nofity很像，wait/nofity是配合synchronized工作的，而條件變量的await/signal是配合使用AQS實現的鎖
來完成工作的，當然也要看用AQS實現的鎖是否支持了條件變量。synchronized只能與一個共享變量進行工作，而AQS實現的鎖支持多個條件變量。

我們試着分析下上面的代碼：

首先創建了兩個條件變量，一個條件變量用來阻塞/喚醒消費者線程，一個條件變量用來阻塞/喚醒生產者線程。

生產者，首先獲取了獨佔鎖，判斷是否有數據：

如果有數據，則調用條件變量producer_con的await方法，阻塞當前線程，當消費者線程再次調用該條件變量producer_con的signal方法，就會喚醒該線程。
如果沒有數據，則生產數據，並且調用條件變量consumer_con的signal方法，喚醒因爲調用consumer_con的await方法而被阻塞的消費者線程。

最終釋放鎖。

消費者，首先獲取了獨佔鎖，判斷是否有數據：

如果沒有數據，則調用條件變量consumer_con的await方法，阻塞當前線程，當生產者線程再次調用該條件變量consumer_con的signal方法，就會喚醒該線程。
如果有數據，則消費數據，並且調用條件變量producer_con的signal方法，喚醒因爲調用producer_con的await方法而被阻塞的生產者線程。

最終釋放鎖。

這裏有兩點需要特別注意：

釋放鎖，一般應該放在finally裏面，以防中間出現異常，鎖沒有被釋放。
判斷是否有數據，其實用if在絕大部分情況也可以，但是用while更好一些，可以防止虛假喚醒。

爲了加深對條件變量的理解，我們再來看一個例子，兩個線程交替打印奇偶數：

public class Test {
    private int num = 0;
    private Lock lock = new ReentrantLock();
    Condition condition = lock.newCondition();
    public void add() {
        while(num<100) {
            try {
                lock.lock();
                System.out.println(Thread.currentThread().getName() + ":" + num++);
                condition.signal();
                condition.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                lock.unlock();
            }
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Test test=new Test();
        new Thread(() -> {
            test.add();
        }).start();

        new Thread(() -> {
            test.add();
        }).start();
    }
}

運行結果：

翻閱網上的大多數案例是分兩個線程方法交替打印，同時開兩個條件變量，其中一個條件變量負責阻塞/喚醒打印奇數的線程，一個變量負責阻塞/喚醒打印偶數的線程，但是個人覺得沒什麼必要，兩個線程共用一個線程方法，共用一個條件變量也可以。不知道各位看官是什麼想的？

源碼解析

當我們點開lock.newCondition，發現它有好幾個實現類：

我們選擇ReentrantLock的實現類，實際上其他實現類也是相同的，只是爲了和上面案例中的對應起來，所以先選擇ReentrantLock的實現類：

   public Condition newCondition() {
        return sync.newCondition();
    }

繼續往下點：

        final ConditionObject newCondition() {
            return new ConditionObject();
        }

可以看到，當我們調用lock.newnewCondition，最終會new出一個ConditionObject對象，而ConditionObject類是AbstractQueuedSynchronizer的內部類，我們先看下ConditionObject的UML圖：

其中firstWaiter保存的是該條件變量下條件隊列的首節點，lastWaiter保存的是該條件變量下條件隊列的尾節點。這裏只保存了條件隊列的首節點和尾節點，中間的節點保存在哪裏呢？讓我們點開await方法:

        public final void await() throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
            Node node = addConditionWaiter();
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            while (!isOnSyncQueue(node)) {
                LockSupport.park(this);
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null) // clean up if cancelled
                unlinkCancelledWaiters();
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }

在這裏，我們就搞清楚三個問題即可：

完整的條件隊列保存在哪裏，以什麼方式保存？
await方法，是如何釋放鎖的？
await方法，是如何阻塞線程的？

第一個問題在addConditionWaiter方法可以得到答案：

        private Node addConditionWaiter() {
            Node t = lastWaiter;
            // If lastWaiter is cancelled, clean out.
            if (t != null && t.waitStatus != Node.CONDITION) {
                unlinkCancelledWaiters();
                t = lastWaiter;
            }
            Node node = new Node(Thread.currentThread(), Node.CONDITION);
            if (t == null)
                firstWaiter = node;
            else
                t.nextWaiter = node;
            lastWaiter = node;
            return node;
        }

首先是判斷條件隊列中的尾節點是否被取消了，如果被取消了，執行unlinkCancelledWaiters方法。我們這裏肯定沒有被取消，事實上，如果是第一次調用await方法，lastWaiter是爲空的，所以肯定不會進入第一個if。隨後，新建一個Node，這個Node類就是上一篇博客中大量介紹過的，也是AbstractQueuedSynchronizer的內部類，也就是新建了一個Node節點，其中保存了當前線程和Node的類型，這裏Node的類型是CONDITION，如果t==null，則說明新建的Node是第一個節點，所以賦值給firstWaiter ，否則將尾節點的nextWaiter設置爲新Node，形成一個單向鏈表，這個nextWaiter在哪裏呢，它是通過node點出來的，也就是它也屬於node類的一個字段：

這說明了一個比較重要的問題：
AQS的阻塞隊列是以雙向的鏈表的形式保存的，是通過prev和next建立起關係的，但是AQS中的條件隊列是以單向鏈表的形式保存的，是通過nextWaiter建立起關係的，也就是AQS的阻塞隊列和AQS中的條件隊列並非同一個隊列。

其實，AQS中的條件隊列也是一個阻塞隊列，只是爲了方便，所以在本篇博客中出現的AQS中的條件隊列特指在被條件變量await的，而阻塞隊列特指FIFO雙向鏈表隊列。

第一個問題解決了，我們再來看第二個問題，第二個問題答案在await的第二個方法：

    final int fullyRelease(Node node) {
        boolean failed = true;
        try {
            int savedState = getState();
            if (release(savedState)) {
                failed = false;
                return savedState;
            } else {
                throw new IllegalMonitorStateException();
            }
        } finally {
            if (failed)
                node.waitStatus = Node.CANCELLED;
        }
    }

首先調用getState方法，這個state是什麼，不知大家是否還有印象，對於ReentrantLock來說，state就是重入次數，隨後調用release方法，傳入state。也就是不管重入了多少次，這裏是一次性把鎖完全釋放掉。

    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方法，這個方法正是需要被重寫的。

當完成了前兩個方法的調用後，就會進行一個判斷isOnSyncQueue，一般來說會進入這個if，park這個線程，等待喚醒，這就解決了第三個問題。

下面我們再來看看signal方法，同樣的，我們需要解決幾個問題：

AQS的條件隊列和阻塞隊列既然不是同一個隊列，那麼是不是被await的線程永遠不會進入阻塞隊列？
signal方法是如何喚醒線程的？

        public final void signal() {
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            Node first = firstWaiter;
            if (first != null)
                doSignal(first);
        }

重點在於doSignal中的transferForSignal方法：

    final boolean transferForSignal(Node node) {
        /*
         * If cannot change waitStatus, the node has been cancelled.
         */
        if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
            return false;

        /*
         * Splice onto queue and try to set waitStatus of predecessor to
         * indicate that thread is (probably) waiting. If cancelled or
         * attempt to set waitStatus fails, wake up to resync (in which
         * case the waitStatus can be transiently and harmlessly wrong).
         */
        Node p = enq(node);
        int ws = p.waitStatus;
        if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
            LockSupport.unpark(node.thread);
        return true;

在這個方法中，我們可以會調用enq方法，把條件隊列的線程放入阻塞隊列中，然後調用unpark方法，喚醒線程。

本篇博客到這裏也結束了。

經過上下兩篇博客，相信大家對AQS一定有了一個比較淺顯的理解。聰明的你，可以看出來，其實這兩篇博客有很多內容都沒有講透，甚至有點模棱兩可，只是“蜻蜓點水”，所以這也符合了我的標題：難以理解的AQS。的確，AQS要深入研究的話，不比線程池簡單多少。看，我又再給自己找理由了。希望經過今後的沉澱，我可以把這兩篇博客重寫下，然後換個標題“徹底理解AQS”，嘿嘿。

難以理解的AQS（下）

條件變量

基本應用

源碼解析

號稱能打敗MLP的KAN到底行不行？數學核心原理全面解析

同事使用 insert into select 遷移數據，開開心心上線，上線後被公司開除！

DeepFilterNet復現

大白話布隆過濾器

劍指Spring源碼（三）俯瞰Spring的Bean的生命週期（大衆版）

ThreadLocal源碼解析，內存泄露以及傳遞性

併發編程基礎（下）

併發編程基礎（上）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結