在了解如何加锁时候，我们再来了解如何解锁。可重入互斥锁ReentrantLock的解锁方法unlock()并不区分是公平锁还是非公平锁，Sync类并没有实现release(int arg)方法，这里会实现调用其父类AbstractQueuedSynchronizer的release(int arg)方法。在release(int arg)方法中，会先调用其子类实现的tryRelease(int arg)方法，这里我们看看ReentrantLock.Sync.tryRelease(int releases)的实现。
正常情况下，这段代码只能由占有锁的线程调用，所以这里会先获取锁的引用计数，再减去释放次数，即：c = getState() - releases，然后判断尝试释放锁的线程，是否是独占锁的线程，如果不是则抛出IllegalMonitorStateException异常。如果独占线程在释放锁后锁的引用计数为0，则设置独占线程为null，再设置state为0，代表锁成为无主状态。
如果确定锁成为无主状态后，release(int arg)会检查队列中是否有需要唤醒的线程，如果头节点header为null，则代表除了释放锁的线程，没有任何线程抢锁，如果头节点的等待状态为0，代表头节点目前没有需要唤醒的后继节点。如果头节点不为null且等待状态不为0，则代表队列中可能存在需要唤醒的线程，会进而执行unparkSuccessor(Node node)，将头节点作为参数传入。
当我们将头节点传入unparkSuccessor(Node node)，如果判断头节点的等待状态<0，则会将头节点的等待状态设置为0，如果头节点的后继节点不为null，或者后继节点尚未被取消，会直接唤醒后继节点，后继节点会退出parkAndCheckInterrupt()方法，acquireQueued(final Node node, int arg)的循环中重新竞争锁，如果竞争成功，则后继节点成为头节点，退出抢锁逻辑开始访问资源，如果竞争失败，这里最多循环两次执行shouldParkAfterFailedAcquire(Node pred, Node node)，第一次先将后继节点的前驱节点的等待状态由0改为SIGNAL（1），表示前驱节点的后继节点处于等待唤醒状态，第二次循环如果还是抢锁失败，shouldParkAfterFailedAcquire(Node pred, Node node)判断前驱节点的等待状态为SIGNAL，返回true，后继节点的线程陷入阻塞。需要注意的是，即便是公平锁，也可能存在不公平的情况，公平锁头节点的后继节点，也有可能存在抢锁失败的情况，比如之前说过，公平锁在调用tryLock()时是不保证公平的。
这里我们需要注意一下，后继节点是可能存在被移除的情况，这种情况会在后续讲解tryLock(long timeout, TimeUnit unit)的时候说明，如果一旦出现后继节点被移除的情况（waitStatus > 0），在唤醒后继节点时，会从尾节点向前驱节点遍历，找到最靠近头节点的有效节点。
public class ReentrantLock implements Lock, java.io.Serializable {
//...
private final Sync sync;
//...
abstract static class Sync extends AbstractQueuedSynchronizer {
//...
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;
}
//...
}
//...
public void unlock() {
sync.release(1);
}
//...
}
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {
//...
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
//...
//由子类实现尝试解锁方法。
protected boolean tryRelease(int arg) {
throw new UnsupportedOperationException();
}
//...
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)
node.compareAndSetWaitStatus(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;
//如果后继节点不为null但被移除，会从尾节点向前驱节点遍历，找到最靠前的有效节点
for (Node p = tail; p != node && p != null; p = p.prev)
if (p.waitStatus <= 0)
s = p;
}
if (s != null)
LockSupport.unpark(s.thread);
}
//...
}
可重入互斥锁的tryLock()方法不分公平锁或非公平锁，统一调用ReentrantLock.Sync.nonfairTryAcquire(int acquires)，在JUC长征篇之ReentrantLock源码解析（一）已经介绍过nonfairTryAcquire(int acquires)方法了，这里就不再赘述了。
public class ReentrantLock implements Lock, java.io.Serializable {
//...
private final Sync sync;
//...
abstract static class Sync extends AbstractQueuedSynchronizer {
//...
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;
}
//...
}
//...
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
//...
}
调用ReentrantLock.tryLock(long timeout, TimeUnit unit)方法时，会调用Sync父类AQS的tryAcquireNanos(int arg, long nanosTimeout)方法，如果线程已被标记为中断，则会进入<1>处的分支并抛出InterruptedException异常，否则先调用tryAcquire(int acquires)尝试抢夺，如果抢锁失败，则会调用doAcquireNanos(int arg, long nanosTimeout)陷入计时阻塞，如果在阻塞期间内线程被中断，则会抛出InterruptedException异常，如果到达有效期后线程还未获得锁，tryAcquireNanos(int arg, long nanosTimeout)将返回false。
当进入doAcquireNanos(int arg, long nanosTimeout)后，会先在<2>处计算获取锁的截止时间，之后和原先的acquireQueued()很像，先把当前线程封装成一个Node对象并加入到等待队列，再判断当前节点的前驱节点是否是头节点，是的话再尝试抢锁，如果抢锁成功则退出。否则用截止时间减去系统当前时间，算出线程剩余的抢锁时间（nanosTimeout）。如果剩余时间<=0的话，代表到达截止时间后线程依旧未占用锁，于是调用<3>处的代表将线程对应的Node节点从等待队列中移除，返回false表示抢锁失败。如果在后面的循环中如果发现当前时间大于截止时间，而线程还未获得锁，代表抢锁失败。
如果剩余时间大于0，则会调用shouldParkAfterFailedAcquire()，如果前驱节点的状态状态为0，则将前驱节点的等待状态设置为-1表示其后继节点等待唤醒，然后在下一次循环的时候，shouldParkAfterFailedAcquire()判断前置节点的等待状态为-1，就有机会阻塞当前线程。但相比acquireQueued()不同的是，这里会判断剩余时间是否大于1000纳秒，如果剩余时间小于等于1000纳秒的话，这里就不会阻塞线程，而是用自旋的方式，直到抢锁成功，或者锁超时抢锁失败。如果自旋期间或者阻塞期间线程被中断，则会在<6>处抛出InterruptedException异常。
public class ReentrantLock implements Lock, java.io.Serializable {
//...
private final Sync sync;
//...
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
//...
}
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {
static final long SPIN_FOR_TIMEOUT_THRESHOLD = 1000L;
//...
public final boolean tryAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())//<1>
throw new InterruptedException();
return tryAcquire(arg) ||
doAcquireNanos(arg, nanosTimeout);
}
//...
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
final long deadline = System.nanoTime() + nanosTimeout;//<2>
final Node node = addWaiter(Node.EXCLUSIVE);
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
return true;
}
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L) {
cancelAcquire(node);//<3>
return false;
}
if (shouldParkAfterFailedAcquire(p, node) &&//<4>
nanosTimeout > SPIN_FOR_TIMEOUT_THRESHOLD)//<5>
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();//<6>
}
} catch (Throwable t) {
cancelAcquire(node);
throw t;
}
}
//...
}
下面，我们来看看AQS是如何移除一个节点的，当要移除一个节点时，会先置空它的线程引用，再在<1>处遍历当前节点的前驱节点，直到找到有效节点（等待状态<=0），找到最靠近当前节点的有效节点pred后，再找到有效节点的后继节点predNext（pred.next），然后我们将当前节点的等待状态置为CANCELLED（1），如果当前节点是尾节点，则用CAS的方式设置尾节点为有效节点pred，如果pred成功设置为为节点，这里还会用CAS的方式设置pred的后继为null，因为尾节点不应该有后继节点，这里用CAS设置尾节点的后继节点是防止pred成为尾节点后，还未置空尾节点的后继节点前，又有新的节点入队成为新的尾节点，并且设置pred的后继节点为最新的尾节点。如果<2>出的代码执行成功，代表当前没有新的节点入队，如果执行失败，代表有新的节点入队，pred已经不是尾节点，且pred的后继已经被修改。
如果node不是尾节点，或者在执行compareAndSetTail(node, pred)的时候，有新节点入队，tail引用指向的对象已经不是node本身,或者在执行compareAndSetTail()执行失败，则会进入<3>处的分支。进入<3>处的分支后，会先判断当前节点的前驱节点是不是头节点，如果是头节点的话，会进入<5>处的分支，唤醒当前节点的后继节点来竞争锁，如果当前节点的后继节点为null或者被取消的话，则会从尾节点开始遍历前驱节点，找到队列最前的有效节点，唤醒有效节点竞争锁。
如果前驱节点不是头节点，且前驱节点的等待状态为SIGNAL或者前驱节点的等待状态为有效状态（waitStatus<=0）且成功设置前驱节点的等待状态为SIGNAL，再判断前驱节点前驱节点的thread引用是否为null，如果不为null则代表前驱节点还不是头节点或者尚未被取消，此时就可以进入<4>处的分支，这里如果判断当前节点的后继节点不为null或者尚未被取消，则用CAS的方式设置前驱节点的后继节点，为当前节点的后继节点。
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {
//...
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
if (node == null)
return;
node.thread = null;
// Skip cancelled predecessors
Node pred = node.prev;
while (pred.waitStatus > 0)//<1>
node.prev = pred = pred.prev;
// predNext is the apparent node to unsplice. CASes below will
// fail if not, in which case, we lost race vs another cancel
// or signal, so no further action is necessary, although with
// a possibility that a cancelled node may transiently remain
// reachable.
Node predNext = pred.next;
// Can use unconditional write instead of CAS here.
// After this atomic step, other Nodes can skip past us.
// Before, we are free of interference from other threads.
node.waitStatus = Node.CANCELLED;
// If we are the tail, remove ourselves.
if (node == tail && compareAndSetTail(node, pred)) {
pred.compareAndSetNext(predNext, null);//<2>
} else {//<3>
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && pred.compareAndSetWaitStatus(ws, Node.SIGNAL))) &&
pred.thread != null) {//<4>
Node next = node.next;
if (next != null && next.waitStatus <= 0)
pred.compareAndSetNext(predNext, next);
} else {//<5>
unparkSuccessor(node);
}
node.next = node; // help GC
}
}
//...
}
先前我们说过，会存在后继节点指向被取消节点的情况，就是发生在cancelAcquire(Node node)方法里，下图是一个锁的等待队列，N1是队头，N1所对应的线程T1正占有锁进行资源访问，N2和N5调用lock()方法采用非计时阻塞请求锁，除非N2和N5对应的线程获取到锁，否则将永远阻塞；N3和N4调用tryLock(long timeout, TimeUnit unit)方法采用计时阻塞请求锁，如果超时对应的线程还未获取到锁，N3和N4将会从队列中移除，返回抢锁失败。
我们假定N3和N4已经超时，要从队列中移除，看看并发场景下是如何出现有效节点的后继引用指向无效节点，这里笔者稍微简化cancelAcquire(Node node)，我们只要专注可能出现有效节点指向无效节点的代码。
假定N3和N4两个节点对应的线程是T3和T4，T3要从等待队列中移除N3，先获取N3的前驱节点pred(N3)为N2，N2是一个有效节点（waitStatus<=0），所以不需要在<1>处遍历，接着在<2>处获取N2的后继节点predNext(N2)为N3，再将N3的等待状态改为CANCELLED，此时T3挂起，T4开始执行。T4线程同样获取N4前驱节点pred(n4)为N3，然后发现N3的等待状态>0，会一直往前遍历到N2，所以N4的前驱节点pred(N4)会为N2，接着T4执行<2>处的代码，predNext(N2)也是N3，此时T4挂起，T3恢复执行。T3判断N3不是尾节点，于是进入分值<4>，T3判断N3的前驱节点N2不是头节点，N2的状态为为SIGNAL，且N2的thread字段不为空，表明N2既没有被取消，也不是头节点，于是进入<5>处的分值，这里获取N3的后继节点N4，由于N4对应的线程T4尚未执行到<3>处的代码，N4的等待状态依旧为SIGNAL，所以T3会进入<6>处的分支，将N2的后继节点指向N4。此时T4开始执行，将N4的等待状态改为CANCELLED，T4进行<4>处的分支，N4的前驱N2不是头节点，等待状态为SIGNAL，且N2的线程引用不为怒null，继而进入<5>处的分值，获取到N4的后继N5，N5不Wie空，且N5的等待状态<=0，进而进入到<6>分支，最后要用CAS的方式尝试将N2的后继节点设置为N5，但这里的设置一定会失败，因为此时N2的后继节点为N4，而T4原先获取到N2的后继节点为N3，出现了有效节点指向无效节点的情况。
private void cancelAcquire(Node node) {
//...
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;//<1>
Node predNext = pred.next;//<2>
node.waitStatus = Node.CANCELLED;//<3>
if (node == tail && compareAndSetTail(node, pred)) {
//...
} else {//<4>
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && pred.compareAndSetWaitStatus(ws, Node.SIGNAL))) &&
pred.thread != null) {//<5>
Node next = node.next;
if (next != null && next.waitStatus <= 0)//<6>
pred.compareAndSetNext(predNext, next);
} else {
//...
}
//...
}
}
最后等待队列的布局如下所示，N2指向无效节点N4，而非N4的后继节点。同时这里也引出另一个问题，哪怕N4不是无效节点，在上面移除节点的代码中，只设置了N2的后继引用指向N4，却没设置N4的前驱引用指向N2，所以这里N4的前驱依旧指向N3。
那么如果真的出现上述这样的情况，ReentrantLock是如何来修复这个队列呢？答案在释放锁的时候调用unparkSuccessor(Node node)。笔者先前在介绍这个方法时，就有意提到后继节点可能指向无效节点，当N1对应的线程使用完锁释放之后，N2对应的线程T2接着使用锁并释放锁，在N2释放锁的时候，发现N2的后继节点已经成为失效节点（waitStatus > 0），这里会从尾节点开始找到队列中最前面的有效节点，然后将其唤醒，这里也就是N5。
private void unparkSuccessor(Node node) {
//...
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node p = tail; p != node && p != null; p = p.prev)
if (p.waitStatus <= 0)
s = p;
}
if (s != null)
LockSupport.unpark(s.thread);
}
N5在被唤醒后，会调用shouldParkAfterFailedAcquire(Node pred, Node node)发现原先的前驱节点N4的等待状态处于被移除，会进入<1>处的分支，查找到最靠近自己的有效前驱节点，并将前驱节点的后继节点指向自己。这里也能回答我们先前的问题，为何在要移除一个节点时，只修改前驱节点的后继引用为被移除节点的后继，却不将被移除节点的后继节点的前驱引用，指向其前驱，因为在释放锁的时候，会唤醒头节点的后继，如果被唤醒的后继发现自己的前驱已经被移除，会往前查找最靠近自己的有效前驱，这里一般是头节点，接着将头节点的后继引用指向自己，再往后就是我们熟悉的流程了，如果前驱节点是头节点且抢锁成功，则退出acquireQueued()方法进行资源的访问，如果抢锁失败，则最多执行两次shouldParkAfterFailedAcquire()然后陷入阻塞，等待下一次的唤醒。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
//...
if (ws > 0) {//<1>
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
//...
}
return false;
}
我们已经了解了lcok()、tryLock()以及tryLock(long timeout, TimeUnit unit)，下面的lockInterruptibly()就变得尤为简单，lockInterruptibly()顾名思义也是无限期陷入阻塞，直到获得锁或者被中断，如果线程本身被中断，在抢锁时会直接抛出InterruptedException异常，否则就开始抢锁，如果抢锁成功则皆大欢喜，抢锁失败则执行doAcquireInterruptibly(int arg)，这个方法相信不需要笔者做过多的介绍，基本上很多步骤和方法在上面已经介绍过了。将线程封装成Node节点并入队，判断Node节点的前驱是否是头节点，是的话则试图抢锁，如果不是的话则最多循环两次执行shouldParkAfterFailedAcquire()，然后陷入阻塞，直到前驱节点成为头节点并释放锁将其唤醒，或者线程被中断，抛出InterruptedException异常。
public class ReentrantLock implements Lock, java.io.Serializable {
//...
private final Sync sync;
//...
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
//..
}
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {
//...
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}
//...
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
final Node node = addWaiter(Node.EXCLUSIVE);
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
return;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} catch (Throwable t) {
cancelAcquire(node);
throw t;
}
}
//...
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
//...
}
最后，笔者就简单介绍下公平锁（FairSync）的tryAcquire(int acquires)方法，如果我们查看ReentrantLock的源码会发现，在执行lock()、tryLock(long timeout, TimeUnit unit)和lockInterruptibly()，这几个方法最终都会调用到AQS对应的三个方法：acquire(int arg)、tryAcquireNanos(int arg, long nanosTimeout)、acquireInterruptibly(int arg)，这三个方法在抢锁的时候会优先执行子类实现的tryAcquire(int arg)方法，也就是公平锁（FairSync）或者非公平锁（NonfairSync）实现的tryAcquire(int arg)方法，抢锁失败再执行AQS自身实现的入队、阻塞方法。
下面，我们来看下公平锁实现的tryAcquire(int acquires)方法，其实这个方法的实现也非常简单，先判断锁目前是否处于无主状态，是的话再判断队列中是否有等待线程，确认锁是无主状态且队列中没有等待线程，便开始尝试抢锁，抢锁成功则直接返回。公平锁相较于非公平锁的抢锁逻辑，也仅仅是多了一步而已，判断锁是否无主，是的话再判断队列中是否有等待线程，不像非公平锁，只要判断是无主线程便不再查看等待队列，直接尝试抢锁。
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
@ReservedStackAccess
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//如果state为0，且队列中没有等待线程，则尝试抢锁
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}