通过ReentrantLock源代码分析AbstractQueuedSynchronizer独占模式

1. 重入锁的概念与作用

      reentrant 锁意味着什么呢？简单来说，它有一个与获取锁相关的计数器，如果已占有锁的某个线程再次获取锁，那么lock方法中将计数器就加1后就会立刻返回。当释放锁时计数器减1，若计数器不为0，说明线程仍然占有锁；若计数器值为0，线程才会真正释放锁。

     可重入锁可以避免同一个线程嵌套（或者说递归）获取锁时的死锁现象。

      考虑下面这样一种情况

public class LockAnalysis {
	private Lock l = new ReentrantLock();
	public void funA(){
		l.lock();
		System.out.println("funA do something");
		l.unlock();
	}
	public void funB(){
		l.lock();
		System.out.println("funB do something");
		funA();
		l.unlock();
	}
}

       如果不是可重入锁，那么线程调用这个类的对象的funB方法时就会导致死锁现象。

       可重入锁的好处是，线程当前的操作需要加锁时，直接加锁即可，不需要考虑已加锁的代码块中是否又进行了加锁的操作。

      如果不是可重入锁，那么线程调用这个类的对象的funB方法时就会导致死锁现象。

       可重入锁的好处是，线程当前的操作需要加锁时，直接加锁即可，不需要考虑已加锁的代码块中是否又进行了加锁的操作。

2. ReentrantLock的内部结构

      内部类

Sync extends AbstractQueuedSynchronizer
NonfairSync extends Sync
FairSync extends Sync

       Sync继承了AbstractQueuedSynchronizer，并依据ReentrantLock的语义实现了相关方法，其它两个内部类分别表示公平锁和非公平锁所对应的同步队列，它们主要是在tryAcquire方法和lock方法的实现上采取了不同的策略，以符合公平锁和非公平锁的语义。

      重要数据成员

private final Sync sync;

       如果构造的是公平锁，sync就引用FairSync的对象，如果构造的是非公平锁sync就是NonfairSync对象的引用。

      构造函数

public ReentrantLock() {
    sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

       无参数时，默认为非公平锁。有参数时，若参数为false,则为公平锁。

4. AQS的内部结构

        锁的获取过程实际上对应了AQS对状态的改变过程。现在我们就要对AQS类进行一个简要的介绍。在本文中做如下规定：未能获得锁的线程会进入队列中排队获取锁，我们称这个队列为等待（锁的）队列。线程调用Condition对象方法的await方法会阻塞，阻塞的线程会进入一个队列中等待其它线程调用signal方法唤醒，我们称这个队列为条件队列。AbstractQueuedSynchronizer简称为AQS。

      重要的数据成员

private volatile int state;
private transient volatile Node head;
private transient volatile Node tail;

         state：对于锁而言它表明了锁的状态，0表示没有线程占有锁；非0表示已有线程占有锁，非0值表示可重入次数。

        未能获取锁的线程就进入队列进行等待，数据成员head和tail 表示等待队列的头和尾。

      内部类Node

static final class Node {
    /** Marker to indicate a node is waiting in shared mode */
    static final Node SHARED = new Node();
    /** Marker to indicate a node is waiting in exclusive mode */
    static final Node EXCLUSIVE = null;

    /** waitStatus value to indicate thread has cancelled */
    static final int CANCELLED =  1;
    /** waitStatus value to indicate successor's thread needs unparking */
    static final int SIGNAL    = -1;
    /** waitStatus value to indicate thread is waiting on condition */
    static final int CONDITION = -2;
    /**
     * waitStatus value to indicate the next acquireShared should
     * unconditionally propagate
     */
    static final int PROPAGATE = -3;
    volatile int waitStatus;

    volatile Node prev;
    volatile Node next;
    volatile Thread thread;

    Node nextWaiter;
    ……//其它暂时省略
}

         内部类Node表示了等待队列中的节点，Node中的thread是因未获取锁而等待的线程的引用。prev 和next分别指向了前一个节点和后一个节点。有时候在本文中线程和节点是同一个意思。

       

                                  AQS队列的示意图

         头节点：它是一个哑节点，它的下一个节点开始才表示因未能获取锁而处于等待锁的节点。

         准确的说队列是由prev引用串接在一起的单向链表，节点中next引用只是一个辅助作用，在大多数情况下可以根据next找到当前节点的下一个节点。

         重点要介绍的是waitStatus，它表示节点的状态，它有五种取值

0	新创建的节点、出列的节点、队尾的节点、刚从条件队列中进入等待队列中的节点，都处于这种状态
CANCELLED = 1	表示当前节点表示的线程因超时或者被中断而处于取消的状态。处于取消状态的节点会从队列中移除，并从获取锁的方法中返回（对于可中断获取锁的方法是以抛出异常的方式返回）
SIGNAL = -1	表示当前节点出列时它的下一个节点需要唤醒
CONDITION = -2	表示当前节点位于条件队列中
PROPAGATE = -3	表示共享模式下，若当前节点被唤醒，它的下一个节点也可以被唤醒

          nextWaiter 有两个作用，一个是指明了AQS是共享模式还是独占模式（用SHARED    和      EXCLUSIVE两种值来区分）；另一个作用是用于条件队列的节点指针。

        内部类ConditionObject

public class ConditionObject implements Condition, java.io.Serializable {
    ……
    /** First node of condition queue. */
    private transient Node firstWaiter;
    /** Last node of condition queue. */
    private transient Node lastWaiter;
    ……//其它暂时省略
}

          ConditionObject类的内部实际上维护了一个条件队列，firstWaiter和lastWaiter表示了队列的头和尾。一个锁仅有一个等待队列，但可以对应多个条件队列（当然一个节点不能同时位于条件队列和等待队列中，也不能同时位于多个条件队列中）。由于ConditionObject是个AQS的内部类，正好满足多个条件队列对应一个等待队列，这可以看做内部类特性的一个经典应用。

         分析ReentrantLock中AQS的工作原理需要把握几点

          1. 任何时候都有可能有多个线程来竞争获取锁

          2. 任何时候都有可能有多个线程竞争入列

          3. 唤醒的线程不一定能立刻运行，可能位于就绪状态

          4. 线程随时可以由运行态转变为就绪态

          5. 锁负责状态的定义

          6. AQS负责队列的维护

5. 非公平不可中断锁的获取

public void lock() {
    sync.lock();
}

      非公平不可中断锁的获取调用了ReentrantLock类中的lock方法，实际上内部调用了NonfairSync类的lock方法。

final void lock() {
    if (compareAndSetState(0, 1)) //快速尝试获取锁
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}

        NonfairSync类内部的lock方法首先尝试快速获取锁（而不考虑是等待队列是否有中节点还在等待获取锁，这是非公平语义的体现），如果成功直接返回，如果失败则调用了AQS类的acquire方法。

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

         tryAcquire的作用是尝试获取锁，获取成功，lock方法返回，线程继续执行；获取失败，调用addWaiter创建一个新的节点到等待队列中。acquireQueued的作用是确保当前线程阻塞后能被唤醒。

       注意：这里调用的不是AQS中的tryAcquire，而是调用了被NonfairSync类覆盖的tryAcquire方法。而NonfairSync类中tryAcquire实际上又调用了Sync类中的nonfairTryAcquire方法。

final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

对于非公平锁，上述代码才是tryAcquire的核心，我们现在对它进行简要的分析。

1. 判断当前状态（AQS的state字段）是否为0，

         1.1若为0，尝试用原子类操作将其置为1（任何时候都有可能有多个线程来竞争获取锁，所以必须使用原子类操作，这里也体现了锁的非公平特性，即未入列就可以尝试获取锁）。

                1.1.1成功：说明已获取锁，通过setExclusiveOwnerThread将占有锁的线程标记当前线程，然后返回true，ture说明获取锁成功。

                1.1.2 失败：返回false，说明同时有其它线程也来获取锁，并且当前线程获取锁失败。

          1.2 若为非0：判断要获取锁的线程是否是当前线程（可重入锁语义的实现）。

                1.2.1 是：state = state + 1 （即重入次数加1），然后返回true，ture说明获取锁成功。

                1.2.2 否：返回false，说明已有线程占有锁，当前线程获取锁失败了。

private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    // Try the fast path of enq; backup to full enq on failure
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}

       现在我们再来分析一下addWaiter，它的主要作用就是将等待的线程入列

       1. 构造一个节点，节点的nextWaiter的值为EXCLUSIVE（ReentrantLock中都是这个值，它表示了独占模式，即同时只能有一个线程拥有锁）

       2. 判断队列的尾节点是否为空

            2.1 否：通过原子操作入列，注意pred.next = node 不是原子操作不能保证入列后立刻被执行（也就是说如果一个节点的next值为null不能说明它后面没有节点，next不为null说明它一定有后继节点）。然后返回新构造的节点的引用，程序结束。

       3. 调用enq方法。

       4. 返回新构造的节点的引用

private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        if (t == null) { // Must initialize
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

      继续分析enq方法。

      1. 判断当前队列的尾部是否为null，这里再次判断的目的就是考虑到多个线程会可能会先后执行enq这段程序，只有一个线程新创建的节点能作为尾节点，其它线程建立的节点都会被垃圾回收线程回收。

          1.1 是：创建一个节点，尝试通过原子操作将其作为队尾（此时它也是队列的头部）。

                1.1.1 成功：说明当前线程为队列设置了尾节点，回到步骤1

                1.1.2 失败：说明其它线程已为队列设置了尾节点，回到步骤1

          1.2 否：尝试入列

                1.2.1 成功：结束

                1.2.2 失败：说明有其它线程也在入列，发生了碰撞，并且当前线程竞争失败了。回到步骤1，再来一次循环。

        以上就是addWaiter的代码分析，现在我们再来分析一下acquireQueued方法的代码分析。

        acquireQueued的主要作用是确认是否要阻塞当前线程，如果要阻塞，该方法要确保前一个节点出列时，当前线程能被唤醒。

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node); // 不可中断锁中永远不会被执行
    }
}

        如果入列后发现当前节点的上一个节点是头节点就会调用setHead(node)，它的作用是当节点成功获取锁以后，将当前作为头节点，上一个头节点会出列。注意头节点的更改是在成功获取锁之后，而不是在释放锁的时候。这样做的目的是考虑到非公平锁状态下，当前节点会和未入列的节点（调用nonfairTryAcquire方法中的compareAndSetState(0, acquires)语句）竞争获取锁，当未入列的节点获取到锁时，队列的头节点应该保持不变。

        p == head && tryAcquire(arg) 的作用：如果当前节点的上一个节点是头节点，当前线程要再次尝试获取锁。这样的原因，就是保证唤醒过程不会出现死链的情况。为了解释的清楚一下，我现在不得不把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;
}

        从释放锁的代码可以看出，如果头节点的waitStatus为0时，它不会唤醒头节点之后的下一个节点。

         我们现在可以举个例子，假设这样一种情况，线程a已占有锁，b，c，d线程因锁已被占有而竞争入列，a在成功释放锁后，即tryRelease(arg)返回true时，b，c，d线程还没有完成头节点的设置（原谅这三个肉肉的线程，由于调度的原因，他们动作比较慢）。这时a线程以为没有线程需要它唤醒，即unparkSuccessor(h)不会执行，它就拍拍屁股走了。此时三个线程才入列完毕（head<-b<-c<-d），注意这个时候其实锁时空闲的，如果这个时候b把自己阻塞了，那有整个等待队列中的节点都不会被唤醒。所以，某个节点发现自己的上一个节点是头节点时，还要再次尝试获取锁，如果失败，要确定头节点的waitStatus必须为SIGNAL，然后再次获取锁（这是为了防止将头节点的waitStatus设置为SIGNAL之前，锁恰好被释放），又失败了才能安心的阻塞自己（调用parkAndCheckInterrupt方法中的LockSupport.park(this)阻塞自己）。

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)
        /*
         * This node has already set status asking a release
         * to signal it, so it can safely park.
         */
        return true;

    
   
   
       
     
    
    
    if (ws > 0) {
        
    
   
   
   
    
   
   
   
     
    
    
    /* * Predecessor was cancelled. Skip over predecessors and * indicate retry. */
        
     
    
    
    do {
            node.prev = pred = pred.prev;
        } 
     
    
    
    while (pred.waitStatus > 0);
        pred.next = node;
    } 
     
    
    
    else {
    
   
   
   
        /*
         * waitStatus must be 0 or PROPAGATE.  Indicate that we
         * need a signal, but don't park yet.  Caller will need to
         * retry to make sure it cannot acquire before parking.
         */
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);

    
   
   
   
    
    
    
         }
    
   
   
   
    return false;
}

          shouldParkAfterFailedAcquire的作用：当前线程就要把自己阻塞了，在阻塞之前务必要保证前一个节点成功释放锁后，会把当前线程唤醒。不可中断锁中节点的状态不会有waitStatus>0的情况，因此我们将不会执行的代码删除。当shouldParkAfterFailedAcquire返回true时，说明可以放心阻塞当前线程了，这时就会调用parkAndCheckInterrupt()方法来阻塞当前线程。当该节点被唤醒时，会继续从parkAndCheckInterrupt()方法中的下一条语句继续执行。

       获取锁过程的几点说明：

       （1） 如果在没有其它线程占有锁的情况下成功获取锁，则该线程不会进入队列

       （2） 节点的出列（也就是头节点的改变）是在成功获取锁之后，而不是释放锁的时候

       （3） cancelAcquire(node)在不可中断锁中不会执行

6. 可中断锁的获取

       可中断锁响应中断只有两个时刻，一个是未入列之前调用acquireInterruptibly方法时，另一个是被唤醒后从parkAndCheckInterrupt方法中返回的时候。如果线程调用lockInterruptibly抛出异常，线程就会从lockInterruptibly方法中返回，并捕获异常。

        lockInterruptibly调用了AQS的acquireInterruptibly，它实际上又调用了doAcquireInterruptibly

private void doAcquireInterruptibly(int arg) throws InterruptedException {
    final Node node = addWaiter(Node.EXCLUSIVE);
    boolean failed = true;
    try {
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                throw new InterruptedException();
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

         doAcquireInterruptibly方法的代码基本和acquireQueued类似，区别就在于当线程检测到自己的中断标志位被设置后（在parkAndCheckInterrupt方法中实现）会抛出异常 InterruptedException，使得finally块中的cancelAcquire方法得到执行。

private void cancelAcquire(Node node) {
    if (node == null)
        return;
    node.thread = null;

    
   
   
   
    
    
    
         Node pred = node.prev;
    
     
    
    
    while (pred.waitStatus > 0)
        node.prev = pred = pred.prev;
    Node predNext = pred.next;
    
   
   
   
    node.waitStatus = Node.CANCELLED; 
    // If we are the tail, remove ourselves.
    if (node == tail && compareAndSetTail(node, pred)) {
        compareAndSetNext(pred, predNext, null);
    } else {

    
   
   
           
     
    
    
    int ws;
        
     
    
    
    if (pred != head &&
            ((ws = pred.waitStatus) == Node.SIGNAL ||
             (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
            pred.thread != 
     
    
    
    null) {
            Node next = node.next;
            
     
    
    
    if (next != 
     
    
    
    null && next.waitStatus <= 0)
                compareAndSetNext(pred, predNext, next);
        } 
     
    
    
    else {
    
   
   
   
            unparkSuccessor(node);

    
   
   
   
    
    
    
             }
    
   
   
   
        node.next = node; // help GC
    }
}

        代码的基本思路就是，从这个队列中删头节点的下一个节点（也就是当前线程自身对应的节点），并唤醒下下一个节点，因为线程一旦入列并处于等待状态，只有被唤醒以后才能响应中断，而被唤醒的前提时节点是必须位于头节点的下一个节点（前面的节点都以陆续出列）。

        cancelAcquire方法是为了可中断锁和超时锁的取消操作共同设计的，可中断锁中没有用到的代码都以横线的方式删除了。

7. 超时可中断锁的获取

private boolean doAcquireNanos(int arg, long nanosTimeout)
        throws InterruptedException {
    if (nanosTimeout <= 0L)
        return false;
    final long deadline = System.nanoTime() + nanosTimeout;
    final Node node = addWaiter(Node.EXCLUSIVE);
    boolean failed = true;
    try {
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return true;
            }
            nanosTimeout = deadline - System.nanoTime();
            if (nanosTimeout <= 0L)
                return false;
            if (shouldParkAfterFailedAcquire(p, node) &&
                nanosTimeout > spinForTimeoutThreshold)
                LockSupport.parkNanos(this, nanosTimeout);
            if (Thread.interrupted())
                throw new InterruptedException();
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

         deadline表示了截止时间，nanoTimeout表示了尝试获取锁剩的余时间，当nanoTimeout大于一个阀值时（这主要是考虑到park操作和unpark操作所耗费的时间，该值由spinForTimeoutThreshold表示），当前线程才会调用LockSupport.parkNanos(this, nanosTimeout)将自己阻（阻塞的时间为nanosTimeout），否则继续执行续循环体。

        可以看出获取锁给定的时间在执行的时候不是一个精确的时间，实际上很可能会大于获取锁所规定的时间。不是一个精确的时间有两方面的原因，一个是由于系统的调度使得线程由运行态转为就绪态，而处于就绪态的时间不固定；另一个是执行park和unpark方法的代码需要的时间无法精确给出。

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    …………
    if (ws > 0) {
        /* * Predecessor was cancelled. Skip over predecessors and * indicate retry. */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    }
    …………
}

          此时在不可中断锁中shouldParkAfterFailedAcquire被划掉的代码才会实现

private void cancelAcquire(Node node) {
    …………
    while (pred.waitStatus > 0)
        node.prev = pred = pred.prev;
    Node predNext = pred.next;
    …………
        int ws;
        if (pred != head &&
            ((ws = pred.waitStatus) == Node.SIGNAL ||
             (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
            pred.thread != null) {
            Node next = node.next;
            if (next != null && next.waitStatus <= 0)
                compareAndSetNext(pred, predNext, next);
        } else {
            …………
        }
}

        基本思想就是跳过那些处于取消状态的节点，如果取消的节点是头节点的下一个节点，则将下下个节点唤醒。与可中断锁不同，这个时候的才可能有多个线程同时执行cancleAcquire方法，划掉的代码才可能会被执行。

8.锁释放代码的分析

public void unlock() {
    sync.release(1);
}

        释放锁的代码实际上调用了AQS的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;
}

        代码的主要功能：1. tryRelease释放锁     2. unparkSuccessor唤醒头节点的下一个节点

        上面代码中最重要就是tryRelease方法。

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

         这里调用的是Sync类中的的tryRelease方法。对于可重入锁，每执行一次unlock方法，可重入次数减1，当state的值为0时，才真正释放了锁。

private void unparkSuccessor(Node node) {
    /*
     * If status is negative (i.e., possibly needing signal) try
     * to clear in anticipation of signalling.  It is OK if this
     * fails or if status is changed by waiting thread.
     */
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);

    /*
     * Thread to unpark is held in successor, which is normally
     * just the next node.  But if cancelled or apparently null,
     * traverse backwards from tail to find the actual
     * non-cancelled successor.
     */
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}

          unparkSuccessor传入的参数是头结点，

         当头节点的next值为null时，不能说明队列为空，而要从后往前寻找需要唤醒的节点。我们将当前节点称为A，A的前一个节点称为B。当节点A入列时，无法对当前节点的prev和前一个节点B的next值同时进行原子操作。有可能正要对B节点的next引用赋值时，线程发生了调度，导致前B节点的next值为null，但实际上A节点已入列，并且位于B节点的后面。

         被唤醒的线程从parkAndCheckInterrupt()继续执行。

9. Condition的await方法和signal方法源码分析

         下面的代码表示阻塞前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方法阻塞当前线程之前的代码，唤醒后执行的代码我们用删除线划掉。

        如果在线程在调用await方法之前就被中断了，那么await会直接抛出异常，此时当前线程没有执行释放锁的状态。

         一个线程调用await方法，说明这个线程必定处于运行（或就绪状）态，处于运行态（或就绪态），那么它必定不会在等待队列中，也没有与之对应节点。所以addConditionWaiter内部是新建一个节点，并加入到条件队列中。

          fullyRelease 方法的作用是释放锁，对于可重入锁，释放的过程是将AQS的status值（可重入次数）存储在savedState变量中，然后通过原子类操作将status的值直接更改为0。而不是像unlock方法那样依次递减为0。

          isOnSyncQueue 判断是否在等待队列中，显然此时不在等待队列中（而位于条件队列中），至于为什么要进行这个判断，还没有彻底理解。

         最后线程调用LockSupport.park(this)将自己阻塞。

private void doSignal(Node first) {
    do {
        if ( (firstWaiter = first.nextWaiter) == null)
            lastWaiter = null;
        first.nextWaiter = null;
    } while (!transferForSignal(first) &&
             (first = firstWaiter) != null);
}

        当其它线程调用这个条件队列的signal方法时（调用signal方法时前必须获取锁），条件队列将头节点从条件队列中取出，然后加入到等待队列中。signal方法主要调用了dosignal方法。

   
  
  
  

    
   
   
   
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方法实现，首先将节点的状态由CONDITION修改为0，然后调用enq方法入列（注意enq方法返回的是当前节点入列后的前一个节点），如果等待队列中已入列的前一个节点的处于取消状态，要将已入列的节点唤醒（这是为了防止死链）；否则就要等到等待队列中该节点之前的已入列的节点依次出列（或者被取消）才能被唤醒。被唤醒后继续回到await中执行（被唤醒的前提是位于条件队列的队首）。

         下面的代码表示唤醒后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);
}

        检查位于条件队列中的时候是否被中断，如果是，跳出循环。否则判断循环条件isOnSyncQueue(node)，显然，singal方法再唤醒前已将队首节点加入到等待队列中，所以不满足循环条件。执行acquireQueued(node, savedState)，这个方法前面分析过，如果获取锁失败，则线程会在这里被阻塞，直到该节点成为了头节点的下一个节点。不同的是若果获取锁成功，这里是将status的值直接更新为可重入次数（就是前面保存的savedState的值），然后从await方法中返回，而不是像重入加锁操作那样每次累加1。

参考博客

[1] http://ifeve.com/jdk1-8-abstractqueuedsynchronizer/

[2] http://www.tuicool.com/articles/RJ3Eza2

[3] http://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html