深入JVM锁机制之二:Lock

前文（深入JVM锁机制-synchronized）分析了JVM中的synchronized实现，本文继续分析JVM中的另一种锁Lock的实现。与synchronized不同的是，Lock完全用Java写成，在java这个层面是无关JVM实现的。

AD：

前文（）分析了JVM中的synchronized实现，本文继续分析JVM中的另一种锁Lock的实现。与synchronized不同的是，Lock完全用Java写成，在java这个层面是无关JVM实现的。

在java.util.concurrent.locks包中有很多Lock的实现类，常用的有ReentrantLock、ReadWriteLock（实现类ReentrantReadWriteLock），其实现都依赖java.util.concurrent.AbstractQueuedSynchronizer类，实现思路都大同小异，因此我们以ReentrantLock作为讲解切入点。

1. ReentrantLock的调用过程

经过观察ReentrantLock把所有Lock接口的操作都委派到一个Sync类上，该类继承了AbstractQueuedSynchronizer：

static abstract class Sync extends AbstractQueuedSynchronizer  

Sync又有两个子类：

final static class NonfairSync extends Sync

final static class FairSync extends Sync 

显然是为了支持公平锁和非公平锁而定义，默认情况下为非公平锁。

先理一下Reentrant.lock()方法的调用过程（默认非公平锁）：

这些讨厌的Template模式导致很难直观的看到整个调用过程，其实通过上面调用过程及AbstractQueuedSynchronizer的注释可以发现，AbstractQueuedSynchronizer中抽象了绝大多数Lock的功能，而只把tryAcquire方法延迟到子类中实现。tryAcquire方法的语义在于用具体子类判断请求线程是否可以获得锁，无论成功与否AbstractQueuedSynchronizer都将处理后面的流程。

2. 锁实现（加锁）

简单说来，AbstractQueuedSynchronizer会把所有的请求线程构成一个CLH队列，当一个线程执行完毕（lock.unlock()）时会激活自己的后继节点，但正在执行的线程并不在队列中，而那些等待执行的线程全部处于阻塞状态，经过调查线程的显式阻塞是通过调用LockSupport.park()完成，而LockSupport.park()则调用sun.misc.Unsafe.park()本地方法，再进一步，HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。

该队列如图：

与synchronized相同的是，这也是一个虚拟队列，不存在队列实例，仅存在节点之间的前后关系。令人疑惑的是为什么采用CLH队列呢？原生的CLH队列是用于自旋锁，但Doug Lea把其改造为阻塞锁。

当有线程竞争锁时，该线程会首先尝试获得锁，这对于那些已经在队列中排队的线程来说显得不公平，这也是非公平锁的由来，与synchronized实现类似，这样会极大提高吞吐量。

如果已经存在Running线程，则新的竞争线程会被追加到队尾，具体是采用基于CAS的Lock-Free算法，因为线程并发对Tail调用CAS可能会导致其他线程CAS失败，解决办法是循环CAS直至成功。AbstractQueuedSynchronizer的实现非常精巧，令人叹为观止，不入细节难以完全领会其精髓，下面详细说明实现过程：
 

2.1 Sync.nonfairTryAcquire

nonfairTryAcquire方法将是lock方法间接调用的第一个方法，每次请求锁时都会首先调用该方法。

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;   

}   

该方法会首先判断当前状态，如果c==0说明没有线程正在竞争该锁，如果不c !=0 说明有线程正拥有了该锁。

如果发现c==0，则通过CAS设置该状态值为acquires,acquires的初始调用值为1，每次线程重入该锁都会+1，每次unlock都会-1，但为0时释放锁。如果CAS设置成功，则可以预计其他任何线程调用CAS都不会再成功，也就认为当前线程得到了该锁，也作为Running线程，很显然这个Running线程并未进入等待队列。

如果c !=0 但发现自己已经拥有锁，只是简单地++acquires，并修改status值，但因为没有竞争，所以通过setStatus修改，而非CAS，也就是说这段代码实现了偏向锁的功能，并且实现的非常漂亮。

2.2 AbstractQueuedSynchronizer.addWaiter

addWaiter方法负责把当前无法获得锁的线程包装为一个Node添加到队尾：

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;   

}   

其中参数mode是独占锁还是共享锁，默认为null，独占锁。追加到队尾的动作分两步：

如果当前队尾已经存在(tail!=null)，则使用CAS把当前线程更新为Tail。

如果当前Tail为null或则线程调用CAS设置队尾失败，则通过enq方法继续设置Tail。

下面是enq方法：

private Node enq(final Node node) {   

    for (;;) {   

        Node t = tail;   

        if (t == null) { // Must initialize   

            Node h = new Node(); // Dummy header   

            h.next = node;   

            node.prev = h;   

            if (compareAndSetHead(h)) {   

                tail = node;   

                return h;   

            }   

        }   

        else {   

            node.prev = t;   

            if (compareAndSetTail(t, node)) {   

                t.next = node;   

                return t;   

            }   

        }   

    }   

}   

该方法就是循环调用CAS，即使有高并发的场景，无限循环将会最终成功把当前线程追加到队尾（或设置队头）。总而言之，addWaiter的目的就是通过CAS把当前现在追加到队尾，并返回包装后的Node实例。

把线程要包装为Node对象的主要原因，除了用Node构造供虚拟队列外，还用Node包装了各种线程状态，这些状态被精心设计为一些数字值：

◆ SIGNAL(-1) ：线程的后继线程正/已被阻塞，当该线程release或cancel时要重新这个后继线程(unpark)。

◆ CANCELLED(1)：因为超时或中断，该线程已经被取消。

◆ CONDITION(-2)：表明该线程被处于条件队列，就是因为调用了Condition.await而被阻塞。

◆ PROPAGATE(-3)：传播共享锁。

◆ 0：0代表无状态。