ReentrantLock源码分析

在进入源码分析之前，先提出如下问题：
问题1：一个线程用lock方法申请锁而被阻塞后，调用线程的interput方法，会发生什么情况，能中断锁的获取吗？
问题2：什么是CLH算法，RenntrantLock针对CLH算法做了哪些变化？
问题3：Node.CANCEL状态的节点在什么时候会删除？

本文重点关注如下几个方法的实现：lock()、unlock()、lockInterruptibly()

ReentrantLock.lock()方法

以ReentrantLock.NonFairSync源码为例：

final void lock() {
    if (compareAndSetState(0, 1))     // @1
        setExclusiveOwnerThread(Thread.currentThread());
     else
        acquire(1); // @2
}

  代码@1 首先线程请求锁时，第一步，直接通过锁的状态 state, 如果 state 为0，通过 CAS 尝试去获取锁，如果获取，直接返回，这里就是所谓的不公平，先抢占，然后再尝试排队。如果当前锁被占用，则尝试申请锁, 进入代码 @2。
  继续查看 acquire(1)方法，该方法存在于 AbstractQueuedSynchronizer 类，该类是 java.util.concurent.locks 锁的队列机制实现类，基于CLH 算法的变体的基本思想。附上 AbstractQueuedSynchronizer 的 acquire 方法源码：

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

先进入到 tryAcquire(arg)方法，查看获取锁的逻辑，该方法不阻塞。尝试获取锁的代码在 ReentrantLock内部类 Sync 汇总，Sync 是 NonFairSync 和 FairSync 的父类。

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

该方法，尝试获取锁，如果成功获取锁，则返回true,否则，返回false。重点关注代码@1, 再次查看锁的state，该字段表示该锁被占用的次数，如果为0，表示没有线程持有该锁；如果大于1，表示同一个线程，多次请求锁，即可重入锁的实现原理。代码@2：进一步说明可重入锁的实现机制。
  再次回到上文提到的AbstractQueuedSynchronizer的 acquire(arg)方法。如果 tryAcquire(arg) 返回 true，则不会执行 acquireQueued，表示成功获取锁；如果 tryAcquire(arg) 返回 false，说明没有成功获取锁，则加入请求队列中。接着进入addWaiter (Node.EXCLUSIVE) 方法。
  addWaiter 中涉及的逻辑就是CLH思想的实现，故在AbstractQueuedSynchronizer 中，源码如下：

    private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        Node pred = tail;
        if (pred != null) { //@1 start
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        } //@1 end
        enq(node);
        return node;
    }

  对于上面的代码@1处，如果当前该锁的尾部节点不为空时，只需要原子性的将新增节点放入原先的尾部，然后更新锁的 tail 属性即可，尾部节点不为空说明有线程已经在该锁上等待；如果尾部为空，表示没有线程持有锁，那为什么获取锁没有成功呢？该线程在没有执行到 addWaiter 时，尾部不为空，无法获取锁，当执行到 addWaiter 时，别的线程释放了锁，导致尾部为空，可以重新获取锁了。进入到 enq(node) 方法中：

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

  使用自旋来加入。CLH算法需要初始化一个假的 head 节点，即head 节点并不代表一个等待获取锁的对象，AbstractQueuedSynchronzier选择初始化head，tail的时机为第一次产生锁争用的时候。@1处为初始化head,tail，初始化后，再将新添加的节点放入到队列的尾部，然后该方法会返回原先的尾节点。addWaiter方法执行后，接下来查看acquireQueued方法，addWaiter方法返回的是代表当前线程的Node节点。

    final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();    //  @1
                if (p == head && tryAcquire(arg)) {    // @2
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&  parkAndCheckInterrupt()  )   //@3
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

  @1获取该节点的 node 的上一个节点。
  @2如果node的前节点是head，因为head初始化时，都是假节点，不代表有线程拥有锁，所以，再次尝试获取锁，如果获取锁，则将锁的 head 设置为当前获取锁的线程的 Node，然后返回 false。返回 false则代表 if (!tryAcquire(arg)&&acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) 的结果为 false，直接返回，并不需要设置中断标记。如果当前节点不是head的话，则说明该锁被别的线程占用了，那就需要等待其他线程释放该锁，具体看一下shouldParkAfterFailedAcquire，为了更好的理解 shouldParkAfterFailedAcquire，先看一下parkAndCheckInterrupt 方法。

    private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);
        return Thread.interrupted();
    }
    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;   //  @1
        if (ws == Node.SIGNAL)    // @2
            return true;
        if (ws > 0) {   // @3
            do {   // @4 start
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);   //@4 end
            pred.next = node; // @5
        } else { // @6
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

@1首先获取前置节点的 waitStatus。
@2如果前置节点的waitStatus =Node.SIGNAL,那么当前节点，直接阻塞，说明状态是一个信号，如果前置节点状态为Node.SIGNAL，那么后续节点应该阻塞的信号量，为什么这么说，情况代码@6，一个节点，新增的时候，为 0 正常。
@3,ws > 0 ，则代表前置节点已取消。
@4 处的代码就是当前 Node 的第一个不为取消状态的前置节点，重构 CLH 队列后，返回 false，再次进入到acquireQueued的无限循环中，又继续 acquireQueued 的流程，继续尝试获取锁，获取锁，或者阻塞。
@6，如果前置节点为0或 PROPAGATE(可传播)，如果前置节点为0，还没有其他节点通过(prev)来判断该 prev 的后继节点是否需要阻塞过，所以，通过 CAS 设置前置节点为 Node.SIGNAL, 重试获取锁过程，避免不必要的线程阻塞。

至此，获取锁的过程就结束了，其流程图：

ReentrantLock.unlock()

public void unlock() {
    sync.release(1);
}
    public final boolean release(int arg) {
        if (tryRelease(arg)) {  @1
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

直接看代码 tryRelease(arg)方法：tryRelease 方法，是由具体的子类实现的，故将目光转移到 NonFairSync 类的 tryRelease() 方法。

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

代码@1，首先，计算持有锁的次数=当前被持有锁的次数-减去释放的锁的数量
代码@2，判断当前锁的持有线程释放与释放锁的线程是否相同，否则，直接抛出运行时异常
代码@3，如果释放锁后，占有次数为0，则代表该锁被释放，设置锁的占有线程为null
代码@4，设置锁的state,如果返回true,表示锁被释放，如果返回false,表示，锁继续被该线程占有（重入了多次，就需要释放多次）。再次回到release方法，如果tryRelease方法返回true,表示可以释放锁，

  public final boolean release(int arg) {
        if (tryRelease(arg)) {  @1
            Node h = head;
            if (h != null && h.waitStatus != 0)   // @2
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

  代码@2为什么需要判断 h!=null && h.waitStatus != 0的判断呢？在讲解获取锁的时候，方法 shouldParkAfterFailedAcquire 中对于代码@6处的讲解，其实不难发现，一个节点在请求锁时，只有当它的前驱节点的waitStatus=Node.SIGNAL时，才会阻塞。如果 head为空，则说明 CLH 队列为空，压根就不会有线程阻塞，故无需执行 unparkSuccessor(h), 同样的道理，如果根节点的waitStatus=0，则说明压根就没有 head 后继节点判断是否要绑定的逻辑，故也没有线程被阻塞这一说。原来一个更重要的原因：改进后的CLH，head如果不为空，该节点代表获取锁的那个线程对于的Node,请看获取锁代码acquireQueued中的代码@2处，如果获得锁，setHead(node);知道这一点，就不难理解为什么在释放锁时调用unparkSuccessor(h)时，参数为head了。

现在将目光转移到 AbstractQueuedSynchronizer. unparkSuccessor(h)方法中:

    private void unparkSuccessor(Node node) {
        int ws = node.waitStatus;  
        if (ws < 0)     // @1
            compareAndSetWaitStatus(node, ws, 0);
        Node s = node.next;
        if (s == null || s.waitStatus > 0) {  //@2 start
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        } // @2 end
        if (s != null) // @3
            LockSupport.unpark(s.thread);
    }

代码@1，目前waitStatus > 0表示取消，等于0表示正常（新建），该步骤主要是 为了保护，避免重复释放。
代码@2 start-end,此处，主要是从占有锁的节点，往后找，找到第一个没有被取 消的节点，然后唤醒它所代表的线程。这里为什么要从尾部寻址呢？
代码@3，唤醒线程，释放锁的逻辑代码已经结束，那调用LockSupport.unpark(s.thread)后，会进入到哪呢？此时，请再次进入获取锁代码的 acquireQueue方法和shouldParkAfterFailedAcquire方法，先解读如下：

  当LockSupport.unpark(s.thread)事，那acquireQueued的代码@3处parkAndCheckInterrupt方法会解除阻塞，继续放下执行，进入到 acquireQueued的for循环处：此时会有两种情况

• HEAD --> Node … > 其中Node 为 LockSupport.unpark 中的 s;
• HEAD --> A Cancel Node --> Node(s)

  如果为第一种情况，直接进入 @2去尝试获取锁。
  如果为第二种情况，shouldParkAfterFailedAcquire(prev,node) 中的 prev 为一个取消的节点，然后会重构整个 CLH 链表，删除Node 到 head 节点直接的取消节点，使得被唤醒线程的节点的上一个节点为 head,从而满足@2处的条件，进入获取锁方法。至此， lock 方法与 unlock 方法流通畅。

final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();    //  @1
                if (p == head && tryAcquire(arg)) {    // @2
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&  parkAndCheckInterrupt()  )   //@3
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

与shouldParkAfterFailedAcquire方法：

    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;   //  @1
        if (ws == Node.SIGNAL)    // @2
            return true;
        if (ws > 0) {   // @3
            do {   // @4 start
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);   //@4 end
 
            pred.next = node; // @5
        } else { // @6
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

为了方便大家理解，给出一个简要的释放锁的流程图：

ReentrantLock.lockInterruptibly()

void lockInterruptibly() throws InterruptedException;

  通过lock()方法去获取锁，如果锁被占用，线程阻塞，如果调用被阻塞线程的interupt()方法，不会取消获取锁吗。
  LockSupport.park会响应中断，但不会抛出InterruptedException。
  接下来，从lockInterruptibly()方法入手，分析与lock方法的差异。首先进入的是AbstractQueuedSynchronizer的acquireInterruptibly方法。

    public final void acquireInterruptibly(int arg)
            throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();
        if (!tryAcquire(arg))
            doAcquireInterruptibly(arg);   // @1
    }
    如果尝试获取锁失败后，进入获取锁并等待锁逻辑，doAcquireInterruptibly
    private void doAcquireInterruptibly(int arg)
        throws InterruptedException {
        final Node node = addWaiter(Node.EXCLUSIVE);   // @1
        boolean failed = true;
        try {
            for (;;) {
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {              // @2
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    throw new InterruptedException();   //@3
            }
        } finally {
            if (failed)
                cancelAcquire(node); //@4
        }
    }

整个获取锁的逻辑与 lock 方法一样，唯一的区别在于parkAndCheckInterrupt如果是通过 t.interupt方法使LockSupport.park取消阻塞的话，会抛出InterruptedException，停止尝试获取锁，然后将添加的节点取消。进入cancelAcquire(node)：

    private void cancelAcquire(Node node) {
        if (node == null)
            return;
        node.thread = null;
        Node pred = node.prev;   
        while (pred.waitStatus > 0)  // @1
            node.prev = pred = pred.prev;
        Node predNext = pred.next; //@2
        node.waitStatus = Node.CANCELLED; 
        if (node == tail && compareAndSetTail(node, pred)) {   // @3 
            compareAndSetNext(pred, predNext, null);
        } else {  // @4
            int ws;
            if (pred != head &&
                ((ws = pred.waitStatus) == Node.SIGNAL ||
                 (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
                pred.thread != null) {   // @5
                Node next = node.next;
                if (next != null && next.waitStatus <= 0)
                    compareAndSetNext(pred, predNext, next);
            } else {  // @6
                unparkSuccessor(node);
            }
            node.next = node; // help GC
        }
    }

代码@1：此处的目的就是设置prev的值为从当前取消节点往head节点方向第一个未取消节点，并将中间的取消节点脱离这条链。
代码@3：如果被取消的节点是尾节点的话，那么将pred设置为尾节点，compareAndSetTail(node, pred)。如果设置失败，说明有别的线程在申请锁，使得尾部节点发生了变化，那么当前节点取消的工作就到此可以结束了；如果设置成功了，既然pred是尾节点，那么再次将pred的next域设置为null。
代码@4：如果取消的节点不是尾部节点的话，这时需要维护CLH链，进入代码@5。
代码@5：首先pred不是head节点，接下来判断是否需要设置pred.next = 当前待取消节点的next。如果pred.waitStatus == Node.SIGNAL或者试图将 pred.waitStatus = Node.SIGNAL 状态成功并且pred.thread 的线程不为空；此时进一步判断待取消的节点的 next 不为空并且状态为非取消的时，将 pred.next 设置为 node.next，该取消节点被删除。
代码@6：如果pred为head,执行一次唤醒操作。

处于Node.CANCEL状态节点的删除发生在shouldParkAfterFailedAcquire，移除就发生在cancelAcquire方法。