共享模式与基于 Condition 的等待 / 通知机制实现（4）

look_w

Condition的await()方法实现原理—-线程等待前面我们看了Condition构建等待队列的过程，接下来我们看一下等待的过程，await()方法的代码比较短，再贴一下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

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

构建完毕队列之后，执行第5行的fullyRelease方法，顾名思义：fullyRelease方法的作用是完全释放Node的状态。方法实现为：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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

这里第4行获取state，第5行release的时候将整个state传过去，理由是某线程可能多次调用了lock()方法，比如调用了10次lock，那么此线程就将state加到了10，所以这里要将10传过去，将状态全部释放，这样后面的线程才能重新从state=0开始竞争锁，这也是方法被命名为fullyRelease的原因，因为要完全释放锁，释放锁之后，如果有竞争锁的线程，那么就唤醒第一个，这都是release方法的逻辑了，前面的文章详细讲解过。
接着看await()方法的第7行判断”while(!isOnSyncQueue(node))”：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

final boolean isOnSyncQueue(Node node) {     if (node.waitStatus == Node.CONDITION || node.prev == null)         return false;     if (node.next != null) // If has successor, it must be on queue         return true;     /*      * node.prev can be non-null, but not yet on queue because      * the CAS to place it on queue can fail. So we have to      * traverse from tail to make sure it actually made it.  It      * will always be near the tail in calls to this method, and      * unless the CAS failed (which is unlikely), it will be      * there, so we hardly ever traverse much.      */     return findNodeFromTail(node); }

注意这里的判断是Node是否在AbstractQueuedSynchronizer构建的队列中而不是Node是否在Condition构建的队列中，如果Node不在AbstractQueuedSynchronizer构建的队列中，那么调用LockSupport的park方法阻塞。
至此调用await()方法的线程构建Condition等待队列–释放锁–等待的过程已经全部分析完毕。