Condition的await()和signal()流程

介绍

Condition是j.u.c包下提供的一个接口。

可以翻译成 条件对象，其作用是线程先等待，当外部满足某一条件时，在通过条件对象唤醒等待的线程。ArrayBlockingQueue就是通过Condition实现的。

先看一下Condition接口提供了哪些方法：

/**
 *  条件对象
 */
public interface Condition {

    /**
     * 让线程进入等待，如果其他线程调用同一Condition对象的notify/notifyAll，那么等待的线程可能被唤醒
     */
    void await() throws InterruptedException;

    /**
     * 不抛出中断异常的await方法
     */
    void awaitUninterruptibly();

    /**
     * 带超时的await
     */
    long awaitNanos(long nanosTimeout) throws InterruptedException;

    /**
     * 带超时的await（可指定时间单位）
     */
    boolean await(long time, TimeUnit unit) throws InterruptedException;

    /**
     * 带超时的await（指定截止时间）
     */
    boolean awaitUntil(Date deadline) throws InterruptedException;

    /**
     * 唤醒等待的线程
     */
    void signal();

    /**
     * 唤醒所有线程
     */
    void signalAll();
}

Condition接口主要提供了两类方法——让线程等待的方法（await()等）和唤醒线程的方法（signal()）。

AQS内部提供了Condition接口的实现——ConditionalObject。它内部的字段如下：

    private static final long serialVersionUID = 1173984872572414699L;
    //该ConditionObject维护的等待队列的头节点
    private transient Node firstWaiter;
    //该ConditionObject维护的等待队列的尾节点
    private transient Node lastWaiter;

非常简单，从上面的字段我们大概可以猜到Condition内部也维护了一个队列。

上篇文章中，我们已经分析锁实现的远离就是通过节点构成队列：让队列中除头节点外的其他线程都被Park，当头节点释放锁时，头节点唤醒下一个节点（Unpark线程），同时更新头节点。

举一反三，我们推测Condition唤醒功能的原理也是通过维护队列的节点。

接下来就通过分析源码，（主要是await()和signal()方法），验证我们的猜测。

---

Condtion对象的获取

Condition对象的获取主要是通过Lock.newCondition()方法。

一个Lock对象可以返回多个Condition对象。

在对Condition进行等待或者唤醒前，都需要先持有Condition关联Lock对象，否则会抛出IllegalMonitorStateException异常。

---

Condition.await()过程

public final void await() throws InterruptedException {
            //如果线程已经被标记为中断，则抛出异常
            if (Thread.interrupted())
                throw new InterruptedException();
            //将线程添加进等待队列
            //注意等待队列和AQS维护的阻塞队列是两个不同的队列
            //正常流程当线程能调用await()，说明线程此时拥有锁，此时AQS的阻塞队列中，线程应该在head节点
            Node node = addConditionWaiter();

            //释放掉锁（如果释放失败，NODE的waitStatus被更新为CANCELLED）
            //同时因为释放掉了锁，该线程在阻塞队列中的节点也已经被移除
            int savedState = fullyRelease(node);

            //这里会将线程挂起，除非线程节点被移到AQS的阻塞队列或是线程被外部中断
            int interruptMode = 0;
            while (!isOnSyncQueue(node)) {
                LockSupport.park(this);
                //检查是否是由于被中断而唤醒，如果是，则跳出循环
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            //在阻塞队列中尝试获取锁
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            //节点已经在阻塞队列中，与Condition的等待队列联系断开
            //对于SIGNAL唤醒的线程而言，SIGNAL时除了将节点移到阻塞队列，同时也清空了node.nextWaiter
            //而对于中断唤醒的线程而言，只是将节点移到阻塞队列，并没有清空node.nextWaiter（因为此时线程不持有，操作等待线程并非线程安全）
            if (node.nextWaiter != null) // clean up if cancelled
                unlinkCancelledWaiters();
            //根据interruptMode 决定是否需要抛出异常
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }

await()方法主要可以分为以下几个过程：

1）线程将自己包装成节点，并添加到Condition的阻塞队列中

2）线程主动释放掉锁

3）线程进入自循环等待（主动通过LockSupport.park()），醒来时，检查自己是否已经被移动至Lock的阻塞队列

4）线程在阻塞队列中等待，直到获取锁（线程在等待时可能又会被LockSupport.park()挂起）

5）线程获取锁，检查自己在等待过程中(await()过程)是否有被中断

6）如果有需要，则清理节点与等待队列之间的联系

7）根据中断状态确定是否需要抛出异常，以便让await()的调用者可以响应线程的中断状态

从上面的流程，我们可以清楚的了解到以上步骤1和2，以及步骤5，6，7是持有锁的，步骤3和4并没有持有锁。了解这一点很重要，因为涉及某些方法是否需要以CAS来保证线程安全。

了解了大体流程，接下来就逐步分析各个步骤。

步骤1.线程包装成节点，添加进Condition的等待队列

这一步骤主要是addConditionWaiter()过程

    private Node addConditionWaiter() {
            Node t = lastWaiter;

            // 找出该ConditionObject的等待队列中 真正未被取消的最后一个节点，并更新为lastWaiter
            if (t != null && t.waitStatus != Node.CONDITION) {
                unlinkCancelledWaiters();
                t = lastWaiter;
            }

            //将该线程包装成Node
            Node node = new Node(Thread.currentThread(), Node.CONDITION);
            //如果此时ConditionObject队列为空，初始化链表且头节点为node
            if (t == null)
                firstWaiter = node;
            else //否则将node添加队尾
                t.nextWaiter = node;
            //更新链表尾节点为node
            lastWaiter = node;
            return node;
        }

主要找出等待队列的最后一个节点，将线程包装成Node，添加到队列的队尾。

这里要注意的一点是此时Node的waitStatus为CONDITION。节点的waitStatus对判断等待是否被取消很重要，在等待队列中等待的节点状态应该为CONDITION，如果状态不为CONDITION，说明线程已经取消了等待（如果waitStatus为0说明被唤醒或中断）。

步骤2.线程释放锁

释放锁的步骤比较简单。主要通过fullRelease()更新AQS的state为0并且将AQS的拥有者置为null，同时唤醒阻塞队列中的后继节点。

final int fullyRelease(Node node) {
        boolean failed = true;
        try {
            //获取锁被持有的此时
            int savedState = getState();
            //让锁直接释放被持有的次数
            if (release(savedState)) {
                failed = false;
                return savedState;
            } else {
                throw new IllegalMonitorStateException();
            }
        } finally {
            //如果释放失败了，则将节点标记为CANCELLED
            if (failed)
                node.waitStatus = Node.CANCELLED;
        }
    }

步骤3.线程挂起，进入循环等待

这一步比较关键，线程等待的动作都发生在这一步。

    int interruptMode = 0;
    while (!isOnSyncQueue(node)) {
            LockSupport.park(this);
            //检查是否是由于被中断而唤醒，如果是，则跳出循环
            if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                break;
    }

线程执行到这，会被LockSupport.park()挂起。

如果此时线程被唤醒，线程会检查是否是因为中断，如果发生中断，还需要确定中断是否发生在SIGNAL前（如果发生在SIGNAL前，之后线程需要抛出异常，让外部响应）。

如果线程不是因为中断而唤醒，线程需要确认节点是否已经被移动至AQS的等待队列。如果没有被移动，则继续被挂起（防止假唤醒）。

checkInterruptWhileWaiting()就是用来检测线程在等待的时候是否被中断。

/**
         * 检查线程在WAITING状态期间，是否有被中断
         * 如果没有返回0；如果是在SIGNAL之前被中断，返回 THROW_IE；如果在SIGNAL之后被中断，则返回REINTERRUPT
         */
        private int checkInterruptWhileWaiting(Node node) {
            return Thread.interrupted() ?
                (transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
                0;
        }

如果线程被中断，还需要通过transferAferCancelledWait判断中断是否发生在SIGNAL之前。

final boolean transferAfterCancelledWait(Node node) {
        //CAS操作，期待值是CONDITION，说明此时唤醒是被取消（中断），因为如果是SIGNAL，那么waitingStatus不会CONDITION，而是0（可以见SIGNAL流程）
        if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
            //即使是取消的，也需要移到AQS的阻塞队列
            enq(node);
            return true;
        }

        //说明线程先收到了SIGNAL信号
        //此时要等SIGNAL信号处理完成
        while (!isOnSyncQueue(node))
            Thread.yield();
        return false;
    }

前文说了Node节点的waitStatus是一个很重要的状态，从它可以推断出线程节点发生了什么操作。

上述方法先用CAS尝试将更新节点的waitStatus为0，期待值为CONDITION。

如果尝试成功，说明此时节点未被操作过（SIGNAL信号），线程是中断唤醒的，此时需要通过enq()将节点添加AQS阻塞队列,因为此时没有锁，所以enq()方法以CAS重试的方式保证线程安全。

如果尝试失败，说明线程收到了SIGNAL信号，节点将由负责SIGNAL的线程移动至阻塞队列。这里为了避免线程返回过早，在判断出线程还未移动至阻塞队列的情况下，会通过Thread.yeild()让出CPU时间。

步骤4.线程在阻塞队列中重新等待锁

这一步主要是通过acquireQueue()方法。该方法已经在上一篇文章中介绍过了，这里不过多介绍。

需要注意的一点是，即使线程在等待时被中断，仍然需要在AQS的阻塞队列中等待获取锁。因为外部没有办法在线程获取锁之前发现中断状态，而且即使线程抛出了中断异常，此时线程也是持有锁的，外部需要显式的释放。

步骤5.检查并设置中断状态

这一步很简单，主要就是通过步骤3中的checkInterruptWhilewaiting()方法返回值：0表示未中断，-1表示中断发生在SIGNAl之前，1表示中断发生在SIGNAL之后。

步骤6.清理节点与等待队列的联系

这里有两种情况，如果线程是因为SIGNAL唤醒的，在唤醒时调用signal()的线程已经清理了被唤醒节点与等待队列的关系。 因为那时唤醒线程持有锁，操作是安全的。

但是如果对于中断被唤醒的线程，唤醒时是不持有锁的，不能保证线程安全的清理唤醒节点与等待队列的关系。因此就将等待清理工作放在了获取锁之后。

//此方法并不保证线程安全，因此调用此方法时，必须要在获取锁的情况下调用
        //此方法的目的是为了整理Condition的等待队列，将非CONDITION状态的节点从等待队列中移除
        private void unlinkCancelledWaiters() {
            Node t = firstWaiter;
            Node trail = null;
            while (t != null) {
                Node next = t.nextWaiter;
                if (t.waitStatus != Node.CONDITION) {
                    t.nextWaiter = null;
                    if (trail == null)
                        firstWaiter = next;
                    else
                        trail.nextWaiter = next;
                    if (next == null)
                        lastWaiter = trail;
                }
                else
                    trail = t;
                t = next;
            }
        }

步骤7.确定中断状态，并决定是否抛出异常

这一步也很简单，就是根据interruptMode来确定是否抛出异常，如果interruptMode值为THROW_IE，说明线程被唤醒前先被中断，此时需要抛出InterruptedException。

---

Condition.signal()过程

signal()过程比起await()要简单很多。既然await()过程是将节点添加到等待队列，那么signal()作为await()的逆过程，就是将节点从等待队列重新移动到AQS阻塞队列。

        /**
         * 唤醒等待节点
         * 主要的流程就是将节点从Condition的等待队列移到AQS的阻塞队列中，让其重新等待锁的获取
         */
        public final void signal() {
            //先验证唤醒者是否是锁的持有者
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            //唤醒等待队列的第一个节点
            Node first = firstWaiter;
            if (first != null)
                doSignal(first);
        }

为保证安全，先确定唤醒线程是否为锁的持有者。

之后找出等待队列中的头节点，将其唤醒。

        /**
         * 唤醒操作（此时占有锁，为线程安全），
         * 找出等待队列中第一个真正要被唤醒的节点，移动到阻塞队列，
         */
        private void doSignal(Node first) {
            do {
                //找出第一个需要唤醒的节点
                if ( (firstWaiter = first.nextWaiter) == null)
                    lastWaiter = null;
                //断开和之后等待队列的联系，并更新等待队列的头节点
                first.nextWaiter = null;
            } while (!transferForSignal(first) &&
                     (first = firstWaiter) != null); //等待队列的头节点移动失败 且 等待队列中还有其他节点，则继续尝试其他节点
        }

因为头节点可能已经被取消，所以这里会一直在等待队列中从前往后找一个节点，开始唤醒。直到一个节点唤醒成功或者等待队列中没有节点需要唤醒。

上文也说了唤醒过程其实就是节点的移动过程。

    /**
     * 将节点从Condition的等待队列移动到AQS的阻塞队列（该方法只会在signal相关的方法中被调用）
     */
    final boolean transferForSignal(Node node) {
        //CAS操作更新节点的waitStatus，期待值为CONDITION
        //操作成功，说明没有其他线程在操作这个节点
        if (!compareAndSetWaitStatus(node, Node.CONDITION, 0)) //CAS操作失败，说明节点已经被中断操作过，waitStatus已经变成了0
            return false;

        //这里说明CAS操作成功
        //应该是线程安全的
        //将节点添加到阻塞队列的队尾
        Node p = enq(node);
        //判断此时阻塞队列是否有前继节点等待，有就Park线程，等待前继节点唤醒
        int ws = p.waitStatus;
        if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
            LockSupport.unpark(node.thread);
        return true;
    }

transferForSignal()操作其实就是先通过CAS操作确定等待队列中的节点还未被取消。如果CAS操作成功，则将其添加到阻塞队列，如果此时阻塞队列还需要等待锁，则让await()的线程继续被挂起。将给线程唤醒的任务(此时已经是获取锁的任务，不再是之前的await()任务)交给阻塞队列中的前继节点。

await()以及signal()过程的流程图

跟着流程图在走一遍，可以帮助巩固上述的知识点。

总结

再借上篇文章重口味的比方梳理下这个流程。

当你排队进了WC的包厢，想要方便时，你觉得太脏了，于是你在包厢内留了张纸条，希望有人能在厕所包厢干净了在叫你过来上厕所(调用Condition的await （）)，随后主动让出了包厢的使用权（释放锁）。后面在排队等着方便的人便进去了。

你离开后，到另一个地方边玩手机边等（移动到Condition的阻塞队列，并被Park），期间，也有一些人同样觉得厕所太脏，跑了出来，在外面等，并排在了你的后面。

过了一段时间，有人把打电话给你说厕所已经变干净了，可以去用了，你就重新回到厕所那排起了队伍，等待轮到你用厕所（acquireQueue）。因为那个人仅通知了你，没有通知其他因为嫌弃厕所脏，而跑出来的人，所以那些只能继续在那等别人去叫他们。

如果你在等待的时候突然有人用其他方式把你喊了回去(外部未给signal却被中断)，你又主动从在外面等待走到了厕所前去排队等待继续去用厕所，但是等你重新排到包厢时，发现测试还是很脏（Condition的 条件未满足），你就会抛出异常。