A.Q.S源码分析（condition条件）

先上代码：

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)                unlinkCancelledWaiters();            if (interruptMode != 0)                reportInterruptAfterWait(interruptMode);        }

首先调用addConditionWaiter把当前节点加入到condition队列。然后调用fullyRelease释放当前节点获得的锁。然后判断是否在sync队列（其实就是判断是否有notify），如果没有notify，那么只有阻塞当前线程，如果有notify信号，那么按照acquire锁的逻辑再走一遍。当await返回的时候，当前线程又持有锁了。

里面的核心判断是isOnSyncqueue()，来看下什么时候返回为真：

 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;    }

可以看到transferForSignal里面有把node从condition队列移到sync队列的逻辑，并且unpark了node持有的线程，从阻塞状态中醒过来，这样就可以继续竞争锁了。其中signal使用了这个方法，以使阻塞的线程从await中醒过来。