AQS实现原理分析——ReentrantLock

时间 2019-11-05

原文原文链接

在Java并发包java.util.concurrent中能够看到，很多源码是基于AbstractQueuedSynchronizer（如下简写AQS）这个抽象类，由于它是Java并发包的基础工具类，是实现ReentrantLock、CountDownLatch、Semaphore、FutureTask 等类的基础。
AQS的主要使用方式是继承，子类经过继承AQS并实现它的抽象方法来管理同步状态，在抽象方法中免不了要对同步状态进行更改，这时就须要使用AQS提供的3个方法（getState()、setState(int newState)和compareAndSetState(int expect,int update) 来进行操做，由于他们可以保证状态的改变是安全的。java

1 AQS原理介绍

在 AQS 内部，经过维护一个FIFO队列来管理多线程的排队工做。在公平竞争的状况下，没法获取同步状态的线程将会被封装成一个节点，置于队列尾部。入队的线程将会经过自旋的方式获取同步状态，若在有限次的尝试后，仍未获取成功，线程则会被阻塞住。大体示意图以下：

当头结点释放同步状态后，且后继节点对应的线程被阻塞，此时头结点线程将会去唤醒后继节点线程。后继节点线程恢复运行并获取同步状态后，会将旧的头结点从队列中移除，并将本身设为头结点。大体示意图以下：
node

2 AQS结构

2.1 AQS属性

先来看看 AQS 有哪些变量，搞清楚这些基本就知道 AQS 是什么套路了，毕竟能够猜嘛！安全

// 头结点，你直接把它当作当前持有锁的线程多是最好理解的
private transient volatile Node head;
// 阻塞的尾节点，每一个新的节点进来，都插入到最后，也就造成了一个隐视的链表
private transient volatile Node tail;
// 这个是最重要的，不过也是最简单的，表明当前锁的状态，0表明没有被占用，大于0表明有线程持有当前锁
// 之因此说大于0，而不是等于1，是由于锁能够重入嘛，每次重入都加上1
private volatile int state;
// 表明当前持有独占锁的线程，举个最重要的使用例子，由于锁能够重入
// reentrantLock.lock()能够嵌套调用屡次，因此每次用这个来判断当前线程是否已经拥有了锁
// if (currentThread == getExclusiveOwnerThread()) {state++}
private transient Thread exclusiveOwnerThread; //继承自AbstractOwnableSynchronizer

在并发的状况下，AQS 会将未获取同步状态的线程将会封装成节点，并将其放入同步队列尾部。同步队列中的节点除了要保存线程，还要保存等待状态。无论是独占式仍是共享式，在获取状态失败时都会用到节点类。因此这里咱们要先看一下节点类的实现，为后面的源码分析进行简单铺垫。既然AQS经过一个双向链表来维护全部的的节点，那么先看一下每个节点的结构：数据结构

static final class Node {
/** Marker to indicate a node is waiting in shared mode */
// 标识节点当前在共享模式下
static final Node SHARED = new Node();
/** Marker to indicate a node is waiting in exclusive mode */
// 标识节点当前在独占模式下
static final Node EXCLUSIVE = null;
// ======== 下面的几个int常量是给waitStatus用的 ===========
/** waitStatus value to indicate thread has cancelled */
// 代码此线程取消了争抢这个锁
static final int CANCELLED = 1;
/** waitStatus value to indicate successor's thread needs unparking */
// 官方的描述是，其表示当前node的后继节点对应的线程须要被唤醒
static final int SIGNAL = -1;
/** waitStatus value to indicate thread is waiting on condition */
// 本文不分析condition，因此略过吧，下一篇文章会介绍这个
static final int CONDITION = -2;
/**
* waitStatus value to indicate the next acquireShared should
* unconditionally propagate
*/
// 一样的不分析，略过吧
static final int PROPAGATE = -3;
// =====================================================
// 取值为上面的一、-一、-二、-3，或者0(之后会讲到)
// 这么理解，暂时只须要知道若是这个值大于0 表明此线程取消了等待，
// 也许就是说半天抢不到锁，不抢了，ReentrantLock是能够指定timeouot的。。。
volatile int waitStatus;
// 前驱节点的引用
volatile Node prev;
// 后继节点的引用
volatile Node next;
// 这个就是线程本尊
volatile Thread thread;
}

Node 的数据结构其实也挺简单的，就是 thread + waitStatus + pre + next 四个属性而已。多线程

2.1 AQS方法

本节将介绍三组重要的方法，经过使用这三组方法便可实现一个同步组件。并发

第一组方法是用于访问/设置同步状态的，以下：app

方法	描述
int getState()	获取同步状态
void setState()	设置同步状态
boolean compareAndSetState(int expect, int update)	经过 CAS 设置同步状态

第二组方须要由同步组件覆写。以下：less

方法	描述
boolean tryAcquire(int arg)	独占式获取同步状态
boolean tryRelease(int arg)	独占式释放同步状态
int tryAcquireShared(int arg)	共享式获取同步状态
boolean tryReleaseShared(int arg)	共享式私房同步状态
boolean isHeldExclusively()	检测当前线程是否获取独占锁

第三组方法是一组模板方法，同步组件可直接调用。以下：ide

方法	描述
void acquire(int arg)	独占式获取同步状态，该方法将会调用 tryAcquire 尝试获取同步状态。获取成功则返回，获取失败，线程进入同步队列等待。
void acquireInterruptibly(int arg)	响应中断版的 acquire
boolean tryAcquireNanos(int arg,long nanos)	超时+响应中断版的 acquire
void acquireShared(int arg)	共享式获取同步状态，同一时刻可能会有多个线程得到同步状态。好比读写锁的读锁就是就是调用这个方法获取同步状态的。
void acquireSharedInterruptibly(int arg)	响应中断版的 acquireShared
boolean tryAcquireSharedNanos(int arg,long nanos)	超时+响应中断版的 acquireShared
boolean release(int arg)	独占式释放同步状态
boolean releaseShared(int arg)	共享式释放同步状态

3 ReentrantLock加锁

ReentrantLock 在内部用了内部类 Sync 来管理锁，因此真正的获取锁和释放锁是由 Sync 的实现类来控制的。
Sync 有两个实现，分别为 NonfairSync（非公平锁）和 FairSync（公平锁），咱们看 NonfairSync 部分。工具

3.1 NonfairSync锁

加锁的一步以下：

public void lock() {
sync.lock();
}

对于非公平锁，则执行以下流程：

final void lock() {
// 若是锁没有被任何线程锁定且加锁成功则设定当前线程为锁的拥有者
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}

1）咱们假设在这个时候，尚未任务线程获取锁，这个时候，第一个线程过来了(咱们使用的是非公平锁)，那么第一个线程thread1会去获取锁，这时它会调用下面的方法，经过CAS的操做，将当前AQS的state由0变成1，证实当前thread1已经获取到锁，而且将AQS的exclusiveOwnerThread设置成thread1，证实当前持有锁的线程是thread1。
2）若是此时来了第二个线程thread2，而且咱们假设thread1尚未释放锁，由于咱们使用的是非公平锁，那么thread2首先会进行抢占式的去获取锁，调用NonFairSync.lock方法获取锁。NonFairSync.lock方法的第一个分支是经过CAS操做获取锁，很明显，这一步确定会失败，由于此时thread1尚未释放锁。那么thread2将会走NonFairSync.lock方法的第二个分支，进行acquire(1)操做。acquire(1)实际上是AQS的方法，acquire(1)方法内部首先调用tryAcquire方法，ReentrantLock.NonFairLock重写了tryAcquire方法，而且ReentrantLock.NonFairLock的tryAcquire方法又调用了ReentrantLock.Sync的nonfairTryAcquire方法，nonfairTryAcquire方法以下：

// 该方法来自父类AQS，我直接贴过来这边，下面分析的时候一样会这样作，不会给读者带来阅读压力
// 咱们看到，这个方法，若是tryAcquire(arg) 返回true, 也就结束了。
// 不然，acquireQueued方法会将线程压到队列中
public final void acquire(int arg) {
// 首先调用tryAcquire(1)一下，名字上就知道，这个只是试一试
// 由于有可能直接就成功了呢，也就不须要进队列排队了，
// 对于公平锁的语义就是：原本就没人持有锁，根本不必进队列等待(又是挂起，又是等待被唤醒的)
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
protected final boolean tryAcquire(int acquires) {
//直接调用下面方法
return nonfairTryAcquire(acquires);
}
/**
* Performs non-fair tryLock. tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
// 尝试直接获取锁，返回值是boolean，表明是否获取到锁
// 返回true：1.没有线程在等待锁；2.重入锁，线程原本就持有锁，也就能够理所固然能够直接获取
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
// state == 0 此时此刻没有线程持有锁
if (c == 0) {
// 用CAS尝试一下，成功了就获取到锁了，
// 不成功的话，只能说明一个问题，就在刚刚几乎同一时刻有个线程抢先了 =_=
// 由于刚刚还没人的，我判断过了???
if (compareAndSetState(0, acquires)) {
// 到这里就是获取到锁了，标记一下，告诉你们，如今是我占用了锁
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
// 会进入这个else if分支，说明是重入了，须要操做：state=state+1
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
// 若是到这里，说明前面的if和else if都没有返回true，说明没有获取到锁
// 回到上面一个外层调用方法继续看:
// if (!tryAcquire(arg)
// && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
// selfInterrupt();
return false;
}

nonfairTryAcquire方法的执行逻辑以下：
1. 获取当前将要去获取锁的线程，在此时的状况下，也就是咱们的thread2线程。
2. 获取当前AQS的state的值。若是此时state的值是0，那么咱们就经过CAS操做获取锁，而后设置AQS的exclusiveOwnerThread为thread2。很明显，在当前的这个执行状况下，state的值是1不是0，由于咱们的thread1尚未释放锁。
3. 若是当前将要去获取锁的线程等于此时AQS的exclusiveOwnerThread的线程，则此时将state的值加1，很明显这是重入锁的实现方式。在此时的运行状态下，将要去获取锁的线程不是thread1，也就是说这一步不成立。
4. 以上操做都不成立的话，咱们直接返回false。
既然返回了false，那么以后就会调用addWaiter方法，这个方法负责把当前没法获取锁的线程包装为一个Node添加到队尾。经过下面的代码片断咱们就知道调用逻辑：

// 假设tryAcquire(arg) 返回false，那么代码将执行：
// acquireQueued(addWaiter(Node.EXCLUSIVE), arg)，
// 这个方法，首先须要执行：addWaiter(Node.EXCLUSIVE)
/**
* Creates and enqueues node for current thread and given mode.
*
* @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
* @return the new node
*/
// 此方法的做用是把线程包装成node，同时进入到队列中
// 参数mode此时是Node.EXCLUSIVE，表明独占模式
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加到链表的最后面去，也就是进到阻塞队列的最后
Node pred = tail;
// tail!=null => 队列不为空(tail==head的时候，其实队列是空的，不过无论这个吧)
if (pred != null) {
// 设置本身的前驱为当前的队尾节点
node.prev = pred;
// 用CAS把本身设置为队尾, 若是成功后，tail == node了
if (compareAndSetTail(pred, node)) {
// 进到这里说明设置成功，当前node==tail, 将本身与以前的队尾相连，
// 上面已经有 node.prev = pred
// 加上下面这句，也就实现了和以前的尾节点双向链接了
pred.next = node;
// 线程入队了，能够返回了
return node;
}
// 仔细看看上面的代码，若是会到这里，
// 说明 pred==null(队列是空的) 或者 CAS失败(有线程在竞争入队)
// 读者必定要跟上思路，若是没有跟上，建议先不要往下读了，往回仔细看，不然会浪费时间的
enq(node);
return node;
}

很明显在addWaiter内部：
第一步：将当前将要去获取锁的线程也就是thread2和独占模式封装为一个node对象。而且咱们也知道在当前的执行环境下，线程阻塞队列是空的，由于thread1获取了锁，thread2也是刚刚来请求锁，因此线程阻塞队列里面是空的。很明显，这个时候队列的尾部tail节点也是null，那么将直接进入到enq方法。
第二步：咱们首先看下enq方法的内部实现。首先内部是一个自旋循环。

/**
* Inserts node into queue, initializing if necessary. See picture above.
* @param node the node to insert
* @return node's predecessor
*/
// 采用自旋的方式入队
// 以前说过，到这个方法只有两种可能：等待队列为空，或者有线程竞争入队，
// 自旋在这边的语义是：CAS设置tail过程当中，竞争一次竞争不到，我就屡次竞争，总会排到的
private Node enq(final Node node) {
for (;;) {
Node t = tail;
// 以前说过，队列为空也会进来这里
if (t == null) { // Must initialize
// 初始化head节点
// 细心的读者会知道原来head和tail初始化的时候都是null，反正我不细心
// 仍是一步CAS，你懂的，如今多是不少线程同时进来呢
if (compareAndSetHead(new Node()))
// 给后面用：这个时候head节点的waitStatus==0, 看new Node()构造方法就知道了
// 这个时候有了head，可是tail仍是null，设置一下，
// 把tail指向head，放心，立刻就有线程要来了，到时候tail就要被抢了
// 注意：这里只是设置了tail=head，这里可没return哦，没有return，没有return
// 因此，设置完了之后，继续for循环，下次就到下面的else分支了
tail = head;
} else {
// 下面几行，和上一个方法 addWaiter 是同样的，
// 只是这个套在无限循环里，反正就是将当前线程排到队尾，有线程竞争的话排不上重复排
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}

第一次循环：t为null，随后咱们new出了一个空的node节点，而且经过CAS操做设置了线程的阻塞队列的head节点就是咱们刚才new出来的那个空的node节点，其实这是一个“假节点”，那么什么是“假节点”呢？那就是节点中不包含线程。设置完head节点后，同时又将head节点赋值给尾部tail节点，到此第一次循环结束。此时的节点就是以下：

第二次循环：如今判断维度tail已经不是null了，那么就走第二个分支了，将尾部tail节点赋值给咱们传递进来的节点Node的前驱节点，此时的结构以下：

而后再经过CAS的操做，将咱们传递进来的节点node设置成尾部tail节点，而且将咱们的node节点赋值给原来的老的尾部节点的后继节点，此时的结构以下：

这个时候代码中使用了return关键字，也就是证实咱们通过了2次循环跳出了这个自悬循环体系。

在执行addWaiter将节点加入阻塞队列后，接下来将会调用acquireQueued方法，主要是判断当前节点的前驱节点是否是head节点，若是是的话，就再去尝试获取锁，若是不是，就挂起当前线程。这里可能有人疑问了，为何判断当前节点的前驱节点是head节点的话就去尝试获取锁呢？由于咱们知道head节点是一个假节点，若是当前的节点的前驱节点是头节点便是假节点的话，那么这个假节点的后继节点就有可能有获取锁的机会，因此咱们须要去尝试。
如今咱们看下acquireQueued方法内部，咱们也能够清楚的看到，这个方法的内部也是一个自悬循环。：

// 如今，又回到这段代码了
// if (!tryAcquire(arg)
// && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
// selfInterrupt();
// 下面这个方法，参数node，通过addWaiter(Node.EXCLUSIVE)，此时已经进入阻塞队列
// 注意一下：若是acquireQueued(addWaiter(Node.EXCLUSIVE), arg))返回true的话，
// 意味着上面这段代码将进入selfInterrupt()，因此正常状况下，下面应该返回false
// 这个方法很是重要，应该说真正的线程挂起，而后被唤醒后去获取锁，都在这个方法里了
/**
* Acquires in exclusive uninterruptible mode for thread already in
* queue. Used by condition wait methods as well as acquire.
*
* @param node the node
* @param arg the acquire argument
* @return {@code true} if interrupted while waiting
*/
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
// p == head 说明当前节点虽然进到了阻塞队列，可是是阻塞队列的第一个，由于它的前驱是head
// 注意，阻塞队列不包含head节点，head通常指的是占有锁的线程，head后面的才称为阻塞队列
// 因此当前节点能够去试抢一下锁
// 这里咱们说一下，为何能够去试试：
// 首先，它是队头，这个是第一个条件，其次，当前的head有多是刚刚初始化的node，
// enq(node) 方法里面有提到，head是延时初始化的，并且new Node()的时候没有设置任何线程
// 也就是说，当前的head不属于任何一个线程，因此做为队头，能够去试一试，
// tryAcquire已经分析过了, 忘记了请往前看一下，就是简单用CAS试操做一下state
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
// 到这里，说明上面的if分支没有成功，要么当前node原本就不是队头，
// 要么就是tryAcquire(arg)没有抢赢别人，继续往下看
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}

第一次循环：获取咱们传入node的前驱节点，判断是不是head节点，如今咱们的状态是：

很明显知足当前node节点的前驱节点是head节点，那么如今咱们就要去调用tryAcquire方法，也就是NonfairSync类的tryAcquire方法，而这个方法又调用了ReentrantLock.Sync.nonfairTryAcquire方法。

很明显thread1占用锁，因此thread2获取锁是失败的，直接返回false。按照调用流程，如今进入了当前节点的前驱节点的shouldParkAfterFailedAcquire方法，检查当前节点的前驱节点的waitstatus。shouldParkAfterFailedAcquire方法内部以下：

/**
* Checks and updates status for a node that failed to acquire.
* Returns true if thread should block. This is the main signal
* control in all acquire loops. Requires that pred == node.prev.
*
* @param pred node's predecessor holding status
* @param node the node
* @return {@code true} if thread should block
*/
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
// 前驱节点的 waitStatus == -1 ，说明前驱节点状态正常，当前线程须要挂起，直接能够返回true
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
// 前驱节点 waitStatus大于0 ，以前说过，大于0 说明前驱节点取消了排队。这里须要知道这点：
// 进入阻塞队列排队的线程会被挂起，而唤醒的操做是由前驱节点完成的。
// 因此下面这块代码说的是将当前节点的prev指向waitStatus<=0的节点，
// 简单说，就是为了找个好爹，由于你还得依赖它来唤醒呢，若是前驱节点取消了排队，
// 找前驱节点的前驱节点作爹，往前循环总能找到一个好爹的
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
// 仔细想一想，若是进入到这个分支意味着什么
// 前驱节点的waitStatus不等于-1和1，那也就是只多是0，-2，-3
// 在咱们前面的源码中，都没有看到有设置waitStatus的，因此每一个新的node入队时，waitStatu都是0
// 用CAS将前驱节点的waitStatus设置为Node.SIGNAL(也就是-1)
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}

上面的流程以下：
1 若是当前节点的前驱节点的waitStatus=-1，就直接返回true；
2 若是当前节点的前驱节点的waitStatus>0，也就是前驱节点被取消了，那么就从阻塞队列中删除前驱节点；
3 若是以上状况都不知足，则经过CAS操做将前驱节点设置为-1（SIGNAL)。
此时，阻塞队列中，会将head节点的waitStatus由0变为-1（初始化节点的waitStatus都是0），而后返回false；

而后回到acquireQueued执行第二次循环：很明显知足当前node节点的前驱节点是head节点，那么如今咱们就要去调用tryAcquire方法，也就是NonfairSync类的tryAcquire方法，而这个方法又调用了ReentrantLock.Sync.nonfairTryAcquire方法。很明显此时thread2获取锁是失败的，直接返回false。按照调用流程，如今进入了当前节点的前驱节点的shouldParkAfterFailedAcquire方法，检查当前节点的前驱节点的waitstatus。此时waitstatus为-1，这个方法返回true。shouldParkAfterFailedAcquire返回true后，就会调用parkAndCheckInterrupt方法，直接将当前线程thread2中断。

// 1. 若是shouldParkAfterFailedAcquire(p, node)返回true，
// 那么须要执行parkAndCheckInterrupt():
// 这个方法很简单，由于前面返回true，因此须要挂起线程，这个方法就是负责挂起线程的
// 这里用了LockSupport.park(this)来挂起线程，而后就停在这里了，等待被唤醒=======
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}

仔细看这个方法acquireQueued方法，是无限循环，感受若是p == head && tryAcquire(arg)条件不知足循环将永远没法结束，在这里，固然不会出现死循环。由于parkAndCheckInterrupt会把当前线程挂起，从而阻塞住线程的调用栈。分析到这里，咱们的thread2线程已经被中断了，这个线程不会再继续执行下去了。

3）假设如今咱们的thread1尚未释放锁，而如今又来了一个线程thread3。
thread3首先调用lock方法获取锁，首先去抢占锁，由于咱们知道thread1尚未释放锁，这个时候thread3确定抢占失败，因而又调用了acquire方法，接着又失败。接着会去调用addWaiter方法，将当前线程thread3封装成node加入到线程阻塞队列的尾部。如今的结构以下：

而后，调用addWaiter方法后，第一步，将当前将要去获取锁的线程也就是thread3和独占模式封装为一个node对象。而且咱们也知道在当前的执行环境下，线程阻塞队列不是空的，由于thread2获取了锁，thread2已经加入了队列。很明显，这个时候队列的尾部tail节点也不是null，那么将直接进入到if分支。将尾部tail节点赋值给咱们传入的node节点的前驱节点。以下：

第二步：经过CAS将咱们传递进来的node节点设置成tail节点，而且将新tail节点设置成老tail节点的后继节点。

在执行addWaiter方法，将thread3插入到阻塞队列尾部后，而后继续调用acquireQueued方法，这是一个自循环方法。

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

第一次循环：获取thread3节点的前驱节点，判断是不是head节点，如今阻塞队列的结果以下：

因为thread3的节点的前驱节点是thread2，不是head，因此会直接调用shouldParkAfterFailedAcquire方法：
1 判断thread3节点的前驱节点的waitStatus，状态为-1，直接返回true；
2 若是thread3节点的前驱节点的waitStatus大于0，说明这个节点被CANCEL了，一直循环向前查找，直到找到waitStatus<=0；
3 若是都不是以上的状况，就经过CAS操做将这个前驱节点设置成-1（SIGHNAL）。
此时的结构以下，主要是thread2节点的waitStatus由0变成了-1。

第二次循环：获取thread3节点的前驱节点，判断是不是head节点，因为明显不是head节点，那么直接进入调用shouldParkAfterFailedAcquire方法，此时，thread3节点的前驱节点的waitStatus为-1，由于返回ture，因此接下来会调用parkAndCheckInterrupt方法，直接将当前线程thread3线程中断。如今thread2和thread3线程都被中断了。

3.2 FairSync锁

其实，公平锁和非公平锁，不一样点只存在两个地方：
1 对于非公平锁，获取锁的第一步就是经过CAS设置state的状态，若是成功，则直接获取了锁；
2 对于公平是和非公平锁，都会调用tryAcquire方法来获取锁，可是两者是有区别的：

//非公平锁
/**
* Performs non-fair tryLock. tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
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;
}
//公平锁
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
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;
}
}

4 ReentrantLock 释放锁

如今thread1要开始释放锁了。调用unlock方法，unlock方法又调用了内部的release方法:

/**
* Releases in exclusive mode. Implemented by unblocking one or
* more threads if {@link #tryRelease} returns true.
* This method can be used to implement method {@link Lock#unlock}.
*
* @param arg the release argument. This value is conveyed to
* {@link #tryRelease} but is otherwise uninterpreted and
* can represent anything you like.
* @return the value returned from {@link #tryRelease}
*/
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 final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
// 是否彻底释放锁
boolean free = false;
// 其实就是重入的问题，若是c==0，也就是说没有嵌套锁了，能够释放了，不然还不能释放掉
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}

调用tryRelease方法释放锁，获取当前AQS的state，并减去1，判断当前线程是否等于AQS的exclusiveOwnerThread，若是不是，就抛异常，这就保证了加锁和释放锁必须是同一个线程。若是(state-1)的结果不为0，说明锁被重入了，须要屡次unlock。若是(state-1)等于0，咱们就将AQS的ExclusiveOwnerThread设置为null。若是上述操做成功了，也就是tryRelase方法返回了true，那么就会判断当前队列中的head节点，当前结构以下：

若是head节点不为null，而且head节点的waitStatus不为0，咱们就调用unparkSuccessor方法去唤醒head节点的后继节点。

/**
* Wakes up node's successor, if one exists.
*
* @param node the node
*/
// 唤醒后继节点
// 从上面调用处知道，参数node是head头结点
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;
// 若是head节点当前waitStatus<0, 将其修改成0
if (ws < 0)
compareAndSetWaitStatus(node, 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.
*/
// 下面的代码就是唤醒后继节点，可是有可能后继节点取消了等待（waitStatus==1）
// 从队尾往前找，找到waitStatus<=0的全部节点中排在最前面的
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
// 从后往前找，仔细看代码，没必要担忧中间有节点取消(waitStatus==1)的状况
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
// 唤醒线程
LockSupport.unpark(s.thread);
}

第一步：获取head节点的waitStatus，若是小于0，就经过CAS操做将head节点的waitStatus修改成0，如今是：

第二步：寻找head节点的下一个节点，若是这个节点的waitStatus小于0，就唤醒这个节点，不然遍历下去，找到第一个waitStatus<=0的节点，并唤醒。如今thread2线程被唤醒了，咱们知道刚才thread2在acquireQueued被中断，如今继续执行，又进入了for循环，当前节点的前驱节点是head而且调用tryAquire方法得到锁而且成功。那么设置当前Node为head节点，将里面的thead和prev设置为null。
此时，thread2获取了锁，并成为头节点，原来的头节点释放掉，等待被回收。