我们在前文ReentrantLock-NonfairSync源码逐行深度分析（上）中分析了NonfairSync获取锁和阻塞线程的入队逻辑，也就是定义在AQS中的acquire方法：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
从前文中了解到，addWaiter方法会将Thread包装成一个Node对象，然后通过死循环(自旋)+CAS的方式保证node一定能够入队成功，入队成功之后会返回对应的node，然后当做入参传入acquireQueued方法中，该方法同样定义在AQS中：
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
//标识是否被中断
boolean interrupted = false;
//自旋
for (;;) {
//获取node节点的前驱节点
final Node p = node.predecessor();
//如果前驱节点是head节点，那么这里在阻塞之前再次尝试去获取锁
if (p == head && tryAcquire(arg)) {
//如果获取锁成功，那么将这个node节点设置为新的头节点
//setHead方法会清空node的thread和prev属性，并将node赋值到head
setHead(node);
//把旧头结点的后驱指针设置为空
p.next = null; // help GC
//到这里相当于将旧的那个头结点孤立了，没有指针指向它，等待被GC回收
failed = false;
//返回是否被中断唤醒，明显这里是false
return interrupted;
}
//下面是阻塞和为唤醒做准备的操作
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
这里同样是自旋逻辑，首先会判断当前node的前驱节点是否是head节点，如果是，那么不会立即阻塞当前node代表的线程，而是再次尝试去获取锁。这个逻辑是什么意思呢？其实很好理解，如果这个条件成立，那就代表此时这个node是CLH的第一个真实排队节点，队列中的第二个节点（head头结点是一个空的Node）,此时可能锁已经被持锁线程释放了，那么这个排在首位的线程其实不需要被阻塞，直接获取锁就行了。但是也有可能会获取锁失败，比如现在是非公平锁的场景，即使node是第一个排队的节点，但此时又有一个新的线程来竞争锁，由于是非公平的，那么这个锁就可能被这个新来的线程获取，node还是需要被阻塞。如果获取锁成功，那么成功节点就需要”出队“，但是这里的出队并不是真正的出队，其执行的操作是：将节点的thread和prev属性置空，把head节点设置为当前节点，将旧head节点的next指针断掉。假如原本是这样的状态(t0已经被阻塞，head节点的waitStatus为SIGNAL)：
现在t0被唤醒获取锁成功，对应的node从CLH"出队"之后的状态：
可以看到，node节点并没有真正出队，而是通过一系列字段置空和断开指针操作，node节点变成了新的head节点，而旧的head节点由于没有引用，会被GC清理掉。当然，如果获取锁失败，那么还是需要进入阻塞状态。
接下来看看阻塞的逻辑，这里涉及到了两个方法的调用：shouldParkAfterFailedAcquire和parkAndCheckInterrupt。如果这两个方法都返回true，那么会将interrupted字段设置为true，然后继续下一次循环。首先来看shouldParkAfterFailedAcquire方法，注意该方法调用传入的pred参数是node节点的前驱节点。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//pred为node节点的前驱节点
//获取前驱结点pred的waitStatus值
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
//ws == -1
return true;
if (ws > 0) {
do {
//如果waitStatus为1（CANCELLED）
//那么需要移除pred节点，如果pred的前驱节点还是为CANCELLED
//那么继续移除，直到节点为非CANCELLED状态
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
//将pred的waitStatus字段设置为-1
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
该方法主要是针对waitStatus的一系列操作，关于Node对象的waitStatus字段，前面提到过，其定义了4个值：
-1 ：SIGNAL：可被唤醒
1：CANCELLED：需要删除
-2：CONDITION：条件等待
-3：PROPAGATE：无条件传播
当然还有一个默认的0值，关于1、-2、-3几个值，在本文中不用去关心，后续在总结其它AQS相关实现的工具时遇到再谈，这里只需要关注默认值0和-1。初始状态ws的值为默认值0，那么将会走到CAS修改waitStatus的逻辑，将前驱结点的ws的值修改为-1，然后这个方法返回false（关于ws大于0，当前只定义了一个大于0的值，就是CANCELLED，本文不用理会，这里做的逻辑处理在代码中也给出了注释，就不再多言~）。
shouldParkAfterFailedAcquire方法返回false之后，紧接着的parkAndCheckInterrupt方法也就不会执行，那么在acquireQueued方法中会进入下一次循环，这里我们就先不考虑node是首个排队节点的情况，会再次进入shouldParkAfterFailedAcquire方法的逻辑，只是此时前驱节点的ws的值成了-1，ws == Node.SIGNAL返回true，那么这个方法此时就会返回true。那么就会接着执行parkAndCheckInterrupt方法，该方法很简单，定义如下：
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
通过LockSupport.park方法实现了线程的阻塞。方法体中关于返回当前线程中断状态的逻辑我们暂时不管，现在先来重新思考shouldParkAfterFailedAcquire和parkAndCheckInterrupt两个方法的逻辑。经过前面的分析，shouldParkAfterFailedAcquire会执行两次（不考虑pread==head并且获取锁成功的情况，这时节点不会再阻塞），第一次将node的前驱节点的waitStatus设置为SIGNAL(-1)，方法返回false，第二次判断到waitStatus等于-1，方法返回true，进而进入parkAndCheckInterrupt方法通过park进行阻塞。所以是node节点的前驱节点的waitStatus的取值影响node节点是否会进入park阻塞，这样做的意义暂时不谈，先知道这么个事儿，等我们看了释放锁的逻辑之后再回过头来看。
那现在就来看ReentrantLock的unlock方法：
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;
}
该方法的布尔类型返回值表示释放锁是否成功，先不管失败的情况，直接看看tryReleaes方法是如何实现的。该方法在AQS中也是一个空方法，具体实现在子类中，这里我们看看ReentrantLock类中的实现（Sync）：
protected final boolean tryRelease(int releases) {
//releases传入的是1
//将当前state的值减去1
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
//只能是持锁线程才能释放锁，否则抛出异常
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
//如果state减为0才表示释放锁成功
//对于锁重入的场景，必须有对应重入次数的释放动作
free = true;
//锁释放成功，将exclusiveOwnerThread设置为空
setExclusiveOwnerThread(null);
}
//更新state属性
setState(c);
return free;
}
锁释放的逻辑很简单，看代码中的注释就行，这里不再赘述。假设现在锁释放成功，返回的free为true，那么就需要执行阻塞线程的唤醒动作：
if (tryRelease(arg)) {
//获取头结点
Node h = head;
if (h != null && h.waitStatus != 0)
//这里要求头结点的waitStatus!=0才会去尝试唤醒阻塞线程
unparkSuccessor(h);
//返回true，表示锁释放成功，如果head为null，或head.waitStatus==0，那么不会去尝试唤醒阻塞线程
return true;
}
释放锁和唤醒阻塞线程虽然都由持锁线程处理，但是这两个是独立的动作，按照代码逻辑来看，它们允许不同时发生，判断依据就是waitStatus字段。对应到前面提到的，线程在阻塞之前，会有两次循环，第一次会先把前驱节点的waitStatus修改为SIGNAL(-1)，然后第二次才会进入parkAndCheckInterrupt方法进行阻塞。注意这里唤醒线程是从CLH的头结点开始唤醒，所以需要判断head的waitStatus字段是否不为默认值0，以下状态表示t0线程可以尝试被唤醒：
此时head节点的waitStatus==-1，那么可以进入unparkSuccessor方法尝试唤醒阻塞的线程，该方法同样定义在AQS中：
private void unparkSuccessor(Node node) {
//此时传入的node是head节点
int ws = node.waitStatus;
if (ws < 0)
//如果waitStatus小于0，则需要重置其状态
compareAndSetWaitStatus(node, ws, 0);
//需要唤醒的是node的后驱节点
Node s = node.next;
if (s == null || s.waitStatus > 0) {
//如果node没有后驱节点，或者后驱节点的waitStatus属性大于0
//目前大于0的值就只定义了1，表示CANCELLED，需要被移除
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
//从后往前找，找到最靠近队头的一个waitStatus<=0的节点
if (t.waitStatus <= 0)
//CANCELLED状态的节点不能被唤醒
s = t;
}
if (s != null)
//找到了需要唤醒的节点，调用unpark唤醒节点对应的线程
LockSupport.unpark(s.thread);
}
前面介绍了在shouldParkAfterFailedAcquire方法中有对应CANCELLED节点的移除逻辑，这里也暂时不用考虑太多，只需要知道我们找到了一个需要被唤醒的线程，然后通过unpark方法将其唤醒，而这里被唤醒的节点就是head节点的后驱节点。
那么当对应阻塞的线程被唤醒之后呢？我们回到线程阻塞的代码段：
private final boolean parkAndCheckInterrupt() {
//线程阻塞在这里
LockSupport.park(this);
//返回的是线程是否被中断，该方法会重置中断标志
return Thread.interrupted();
}
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
//阻塞线程被唤醒后，会继续循环，其前驱节点是head节点，才会尝试继续获取锁
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
//线程成功获取到锁，failed参数设置为false
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
//如果线程是被中断唤醒，那么将中断表示interrupted设置为true
interrupted = true;
}
} finally {
if (failed)
//在这里线程如果重新获取到锁，failed不会是true
cancelAcquire(node);
}
}
这里有几个非常重要的点：
第一个是阻塞线程被唤醒之后，不是立马就把锁给它，而是会继续执行循环体，再执行一次：判断前驱结点是否为head，然后尝试通过CAS去竞争锁。对于非公平锁的情况下，如果持锁线程将锁释放了，并不能保证被唤醒线程一定能拿到锁，因为此时可能有一个新的线程来竞争锁，那么这个锁就可能被这个新线程获取到，被唤醒的线程还需要再次陷入阻塞，关于这点在前面分析acquireQueued方法的时候已经有过说明。在前面unparkSuccessor方法唤醒阻塞线程的逻辑中，将head的waitStatus的值又重置为了初始值0，那么这里如果被唤醒线程竞争失败，需要重新陷入阻塞，会又重复两次循环，先将前驱节点(这里是head)的waitStatus设置为SIGNAL(-1)，然后再陷入阻塞，这样不断循环~
第二个是线程中断的处理。线程在方法parkAndCheckInterrupt被阻塞，然后唤醒后，返回了当前线程是否被中断的标志。关于线程中断，可以理解为是一个信号，以前终结一个线程需要调用thread.stop方法，该方法会调用native方法stop0，这个方法很暴力，线程会被直接kill，如果线程正在执行某些操作，也就会被暴力打断。所以后面提供了一个优雅一点的方式：interrupt。线程被中断后，开发人员可以获取到该标识：Thread.interrupted()，然后优雅地退出线程。需要注意的是，调用该方法会重置线程的中断状态：
/**
* Tests if some Thread has been interrupted. The interrupted state
* is reset or not based on the value of ClearInterrupted that is
* passed.
*/
private native boolean isInterrupted(boolean ClearInterrupted);
所以被park阻塞的线程，既可以被upark唤醒，也可以被interrupt唤醒，在此处的实现逻辑中，可以看到不论interrupt是true还是false都没有影响，仍然会不断循环重试，直到成功获取到锁，最终interrupted作为acquireQueued方法的返回值返回给调用者，在前文已经分析过了，其调用者是AQS的acquire方法：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
//acquireQueued方法返回的是线程是否被中断过
//如果被中断过，则需要在这里进行一次自我中断
selfInterrupt();
}
static void selfInterrupt() {
//线程自己中断自己
Thread.currentThread().interrupt();
}
为什么需要自己中断自己？原因就是前面提到的，Thread.interrupted()方法会重置线程的interrput状态，这里需要把中断状态向外传递，使得外层调用者能正确感知到线程被中断过，以便做出相应的处理，所以需要自己中断自己重新设置中断状态。
第三是acquireQueued方法中断finally 代码块：
finally {
if (failed)
cancelAcquire(node);
}
在此处的场景中，这个failed好像除了未知的异常发生之外，永远不会为true，因为即使线程被中断唤醒了，也会继续竞争锁，竞争失败会继续陷入阻塞，竞争成功，那么failed会被设置为false。事实上，ReentrantLock除了lock()方法之外，还有一个lockInterruptibly方法，看方法名可能就知道了，这个方法是支持中断的，看看其在AQS中的实现：
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
//如果线程被中断，那么直接抛出中断异常
throw new InterruptedException();
if (!tryAcquire(arg))
//如果首次尝试获取锁失败，那么调用doAcquireInterruptibly方法阻塞
doAcquireInterruptibly(arg);
}
如果线程被中断，那么直接抛出中断异常，否则就尝试调用tryAcquire方法获取锁，如果获取锁失败，那么调用方法doAcquireInterruptibly完成线程的阻塞工作（前面介绍的lock逻辑是通过acquireQueued方法实现的），来看看这个方法：
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
//和前面分析的acquireQueued方法一样，自旋CAS保证入队成功
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;
}
//同样的修改waitState和阻塞逻辑
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
//但是这里是抛出异常，前面是设置interrupted = true
//抛出异常后，failed 还是为初始值true，那么就会执行finally代码块中的cancelAcquire方法
throw new InterruptedException();
}
} finally {
if (failed)
//如果前面抛出InterruptedException就会执行这个方法
cancelAcquire(node);
}
}
可以看到doAcquireInterruptibly方法和acquireQueued方法"唯一"的区别就是，doAcquireInterruptibly没有返回值，在这里面如果阻塞线程被中断唤醒，那么不会继续参与锁的竞争，而是直接抛出InterruptedException，然后会在finally代码块中执行cancelAcquire方法；而acquireQueued方法即使线程被中断唤醒，那么也只是将中断状态保存下来，然后会继续参与锁的竞争，最终获取到锁之后，会把中断标识返回给方法调用者，最终通过selfInterrupt线程自我中断重新打上中断标记，以便更外层的调用者能够获取到该状态。
那么我们来看看cancelAcquire方法：
private void cancelAcquire(Node node) {
if (node == null)
//判空
return;
//置空当前节点的thread，因为被中断后就不需要了，也不需要被唤醒了
node.thread = null;
//获取node的前驱节点
Node pred = node.prev;
while (pred.waitStatus > 0)
//跳过node所有waitStatus>0(也就是CANCELLED)的前驱节点
//将node的前驱指针指向最近的一个非CANCELLED节点pred
node.prev = pred = pred.prev;
//获取pred的后驱节点
Node predNext = pred.next;
//将当前node节点的waitStatus设置为CANCELLED
node.waitStatus = Node.CANCELLED;
if (node == tail && compareAndSetTail(node, pred)) {
//情况1：node是尾结点并且成功通过CAS将pred设置为尾结点（可能有其它新线程节点入队，导致node不再是尾结点）
//将pred的后驱指针置空：相当于移除了当前node和node的所有CANCELLED前驱节点
compareAndSetNext(pred, predNext, null);
} else {
//node不是尾结点，或者本来是尾结点，但是CAS的时候被其它线程更新了CLH(上面compareAndSetTail失败)，node变成了非尾节点
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) {
//情况2：pred不是head节点，并且pred是有效的节点（waitStatus不是CANCELLED，并且是SIGNAL或被成功修改为SIGNAL,thread不为空）
//如果pred的waitStatus不等于SIGNAL，会尝试将其修改为SIGNAL，表示下个节点可被唤醒
//由于节点的waitStatus可能被其它线程修改，所以使用了CAS操作
Node next = node.next;
if (next != null && next.waitStatus <= 0)
//当node==tail，但是CAS替换tail的时候失败了，逻辑也可能走到这里，所以next可能为null，需要判空
compareAndSetNext(pred, predNext, next);
} else {
//情况三：pred是head节点或者无效的节点
unparkSuccessor(node);
}
//将node的next指向自己
node.next = node; // help GC
}
}
这个方法代码比较复杂，但是实现的逻辑很简单，就是根据节点的不同位置采取不同的逻辑，将该节点从CLH队列中移除，需要的时候还会尝试唤醒后驱节点，代码中给出了相应的注释，这里也通过画图再详细解释一下其逻辑。
首先是注释中提到的，跳过所有waitStatus>0(也就是CANCELLED)的前驱节点，重新设置node的前驱指针。假设初始状态是这样（注意这里不关注waitState<=0的具体状态，所以图中节点只画了1和0两个状态）：
跳过所有CANCELLED前驱节点，重新设置前驱指针，置空thread，接着获取pred的后驱节点，然后将node的waitStatus设置为CANCELLED：
这些逻辑都是做的准备工作，接下来对于三个情况有不同的处理逻辑。
- 情况1：当前node节点是尾结点（tail）。那么就直接移除node节点，还顺带把node的所有CANCELLED前驱节点一并移除，移除的操作是，先将pred设置为tail，然后将pred的next置空，对应到上图就成了这个状态：
最后两个waitStatus为1的节点（包括node）被逻辑移除，没有了GC Root引用链引用，可以被GC清理。当然，CAS更新尾结点可能会失败，如果失败，那么就会走入下面的逻辑。 - 情况2：pred不是head节点，并且pred是有效的节点。那么先获取node的next节点，如果该节点是有效节点，那么尝试将pred的next指向这个node的next，最终将node的next指向自己：
可以看到，中间那个无效节点的指针已经断了，但是node的后驱节点的prev指针仍然指向node，不过没有影响，因为在其后面入队的节点准备阻塞或者中断后会从后往前遍历节点，同时"移除"无效节点。 - 情况3：pred是head节点或者无效的节点。此时直接尝试唤醒node的后驱节点，最后将node的next指向自己。
这里需要注意，情况3中调用unparkSuccessor方法的目的是什么？我们假设这里unparkSuccessor方法调用之前是以下状态：
现在唤醒t1线程，t1线程会在acquireQueued方法中继续循环，显然此时t1的prev节点不是head节点，所以会进入shouldParkAfterFailedAcquire方法修改前驱节点的waitStatus，但是发现前驱节点（也就是node）的watiStatus大于0 ，所以会跳过该节点，前面已经分析过shouldParkAfterFailedAcquire方法，这里就不详细说明了，只贴一下此处关心的代码：
if (ws > 0) {
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
}
return false;
经过这个操作之后，状态变成了：
此时shouldParkAfterFailedAcquire方法返回的false，接着又进行一次循环，这次循环发现t1节点的prev节点是head，那么t1就会尝试去竞争锁，如果竞争失败，则再次陷入阻塞状态。那么为什么不直接修改指针，要通过唤醒t1线程去修改指针呢？试想一下，如果持锁线程unlock释放了锁，那么需要从head唤醒一个阻塞的线程，由于node是head的后驱节点，所以node会被唤醒，而node对应的线程却在方法返回之前突然又出现异常（比如tryAcquire方法中获取锁时抛出了异常），也就相当于唤醒失败了，没有成功获取到锁，从而进入了cancelAcquire方法，那么这个node会在cancelAcquire中被移除。但是这里要注意，node移除之后，本次unlock就相当于没有唤醒任何线程（因为node由于异常持锁失败），如果不来新的线程竞争锁，就可能出现没有线程持有锁，但是却有很多线程被阻塞排队等待锁被释放唤醒它们的情况（纯属个人猜测~）。
另外，关于unparkSuccessor方法前文已经介绍过了，这里不再赘述，就是前文逻辑中入参是head，此处是node。但是为什么寻找有效节点是从后往前找，不是从前往后找呢？结合到无效节点出队的逻辑，可以发现一些无效节点的指针一开始并没有全部断开，而是保留了部分后驱节点对其的前置指针，从后往前遍历可以根据这个前置指针找到这些无效节点，完成真正的出队，也就相当于出队动作被延迟了。
总结
Doug Lea将众多逻辑都凝练到AQS中，单独看某个函数的时候，可能会觉得有些逻辑明明可以有更简单的实现，有些逻辑又是莫名其妙，因为这些函数逻辑考虑了AQS的众多应用场景，所以需要对这块儿有个整体上的把握才能更好的理解其设计。正是由于这个原因，本文在分析函数的时候大多都只考虑当前分析的场景，不然可能会很懵逼。