ReentrantLock源码通读（二）

介绍

上一篇，主要是介绍了多线程之间请求锁的流程。而ReentrantLock还提供了Condition实现，拓展了多线程之间协作功能。这些功能实际上由AbstractQueuedSynchronizer中内部实现的ConditionObject提供，ReentrantLock中只提供newCondition()获取Condition的方法。ConditionObject实现Condition接口，通过firstWaiter、lastWaiter这两个Node类型的变量维护一个队列(之后这个队列称为预队列)。

过程

整个协作流程可以从await打头的几个方法中查看，这些方法在流程上没有本质区别，只是多了状态验证的逻辑，所以这里分析仅awaitUninterruptibly()方法,其他几个方法不作赘述，先看看awaitUninterruptibly()源码，对流程有个大致了解：

//最基础的等待流程直接看这个awaitUninterruptibly()方法
public final void awaitUninterruptibly() {
    //创建一个node，并添加到Condition中的链表中，
    Node node = addConditionWaiter();
    //释放锁
    int savedState = fullyRelease(node);
    boolean interrupted = false;
    //检查node是否在AbstractQueuedSynchronizer的链表中(主队列)
    while (!isOnSyncQueue(node)) {
        LockSupport.park(this);
        if (Thread.interrupted())
            interrupted = true;
    }
    //请求锁
    if (acquireQueued(node, savedState) || interrupted)
        selfInterrupt();
}

Condition的整个流程分解为五个步骤(这样能让我更好的理顺Condition的脉络)：准备(线程1) > 等待(线程1) > 通知(线程2) > 被通知(线程1) > 结束(线程1)。下面根据步骤顺序查看源码。

准备

这个步骤主要方法有两个，addConditionWaiter()、fullyRelease(Node node)。
fullyRelease(Node node)是释放锁，返回锁的重入次数。

主要看addConditionWaiter()中都干了什么：

private Node addConditionWaiter() {
    Node t = lastWaiter;
    //首先清理一遍队列中被取消的节点
    if (t != null && t.waitStatus != Node.CONDITION) {
        unlinkCancelledWaiters();
        t = lastWaiter;
    }
    //condition的节点使用nextWaiter链成队列，针对主队列中Node做区分
    Node node = new Node(Thread.currentThread(), Node.CONDITION);
    if (t == null)
        firstWaiter = node;
    else
        t.nextWaiter = node;
    lastWaiter = node;
    return node;
}

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

先是调用unlinkCancelledWaiters()移除队列中某些状态的Node，t.waitStatus != Node.CONDITION这个条件相对宽泛，被移除的节点将不止是CANCELLED，SIGNAL状态的Node也会被移除。

然后new一个初始状态为初始状态时CONDITION的Node，然后将新Node对象赋值给lastWaiter节点的nextWaiter，并且将lastWaiter也赋值为新Node对象。

如果预队列为没有Node，那么将firstWaiter和lastWaiter都设置为这个刚刚new出来的Node。因为只能用Node节点中的nextWaiter变量，所以预队列遍历时只能从firstWaiter开始。

预队列使用Node对象中nextWaiter变量维护队列，而AbstractQueuedSynchronizer中的队列(之后称为主队列)使用的是Node的prev和next两个变量，预队列和主队列的Node就有了一个明显的区别，就是预队列中的Node的prev和next都是null。

等待

将线程添加到预队列中之后，当前线程已释放锁，通过isOnSyncQueue(Node node)方法检查刚刚创建的节点是否在主队列中：

final boolean isOnSyncQueue(Node node) {
    if (node.waitStatus == Node.CONDITION || node.prev == null)
        return false;
    if (node.next != null)
        return true;
    
    return findNodeFromTail(node);
}

private boolean findNodeFromTail(Node node) {
    Node t = tail;
    for (;;) {
        if (t == node)
            return true;
        if (t == null)
            return false;
        t = t.prev;
    }
}

如果线程的检点一直都不在主队列中，isOnSyncQueue(Node node)返回false，将一直停留在这个while循环处。

补充说明一下，预队列节点和主队列节点的区别就是Node的prev和next是否为null，如果prev和next不在是null，间接表明这个Node在主队列中。什么时候预队列中的Node的prev或next会被赋值呢？下面马上就会说到。

通知

线程进入阻塞状态后，通知步骤将由另一个线程执行Condition中的signal()和signalAll()方法：

public final void signal() {
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    Node first = firstWaiter;
    if (first != null)
        doSignal(first);
        //signalAll中执行的方法是doSignalAll(first);
}

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

private void doSignalAll(Node first) {
    lastWaiter = firstWaiter = null;
    do {
        Node next = first.nextWaiter;
        first.nextWaiter = null;
        transferForSignal(first);
        first = next;
    } while (first != null);
}

在通知前，会检查当前的线程是否持有锁，如果未持有锁，将会直接返回
signal()和signalAll()总体上差别不大，只是signalAll()会通知整个预队列中的线程。signal()只要transferForSignal(Node node)返回true就结束。
再来看看transferForSignal(Node node)中做了什么：

final boolean transferForSignal(Node node) {
    //节点的状态被其他线程修改
    if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
        return false;

    //添加到主队列中
    Node p = enq(node);
    int ws = p.waitStatus;
    //修改状态为SIGNAL
    if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
        LockSupport.unpark(node.thread);
    return true;
}

它先修改一次Node的节点，然后添加主队列(这个时候Node的prev被初始化了），然后才将Node的状态修改为SIGNAL，最后唤醒Node中的线程。这样通知就完成了。

为什么要修改两次Node的状态呢？

因为考虑到使用ConditionObject是多线程场景，可能会有多个线程同时在操作预队列中同一个Node，既有检查Node的状态将它移除出预队列的，也有将它添加到主队列的，第一次修改时，让多个线程使用CAS修改这个节点状态，修改成功的，继续接下来的流程，修改失败的线程直接返回false(一个很有效的failed fast的实现)，跳过这个Node，第二次修改，则是激活Node，虽然在这里Doug Lea大佬用了if语句流程，但是条件基本可以看做是true，我倾向于是Doug Lea大佬为了防止一些意想不到的多线程场景的双保险。

被通知

再回到等待线程的流程中，这个时候这个线程被唤醒，会重新进入isOnSyncQueue(Node node)，现在结合通知步骤的操作再来看那些if的条件语句：

final boolean isOnSyncQueue(Node node) {
    if (node.waitStatus == Node.CONDITION || node.prev == null)
        return false;
    if (node.next != null)
        return true;
    
    return findNodeFromTail(node);
}

node.waitStatus是SIGNAL，node.prev不是null，检查node.next是否为null、调用findNodeFromTail(Node node)都是为了确认node已经完全添加到主队列中了。

当node.next == null时，使用findNodeFromTail(Node node)方法排除node在enq(Node node)中的CAS设置tail节点的操作一直失败，不能真正的从主队列中遍历到这个node的情况。

正常情况下isOnSyncQueue(Node node)返回true后，结束while循环，进入返回阶段。

返回

这个阶段，就是排排坐，分果果了，Node进入主队列排队等待，最后获取到锁，回顾一下awaitUninterruptibly()方法：

public final void awaitUninterruptibly() {
    Node node = addConditionWaiter();
    int savedState = fullyRelease(node);
    boolean interrupted = false;
    while (!isOnSyncQueue(node)) {
        LockSupport.park(this);
        if (Thread.interrupted())
            interrupted = true;
    }
    if (acquireQueued(node, savedState) || interrupted)
        selfInterrupt();
}

之前重入锁的次数savedState，在重新请求锁时，作为参数传入，在被ConditionObject通知之后，重新将锁的持有状态恢复到使用等待方法之前。

总结

基本使用

几个等待的方法使用方法一样，这里使用await()做示范：

1. 通过ReentrantLock对象创建Condition对象；
2. 线程1先持有锁，然后使用Condition对象，调用await()；
3. 另一个线程，线程2持有锁，然后使用这个Condition对象，调用signal()或者signalAll()；
4. 线程1苏醒，请求锁，继续后面的代码流程，结束。
   整个使用过程和synchronized关键字中使用wait()、notify()和notifyAll()的过程很像。

特性

和ReentrantLock相似，提供了相对来讲比较稳定、合理的线程协作组件，无需自己重新实现一套类似的逻辑代码，并且提供了各种可设置超时时间的等待方法，使用起来也比较方便。

为什么推荐使用Condition，而不是synchronized关键字呢？
因为Condition接口本身的实现类会实现一些额外的功能，最基本的就是可超时，可中断这种有效防止死锁的逻辑，另外和实现了一些周边的统计功能，比如,hasWaiters(ConditionObject condition)检查当前是否有线程正在等待的线程;getWaitQueueLength(ConditionObject condition)检查当前等待线程的个数；getWaitingThreads(ConditionObject condition)查询具体等待的线程等等。这些方法的实现，都让我们能够更方便的监控线程的工作状态。