俗话说得好，编程不识Doug Lea，写尽Java也枉然。本章将开启J.U.C源码探索，让我们通过一个ReentrantLock类，来开启AQS的大门。
～～～～～～～～～～～～～ 祖师爷庇护，并发从此无难题。～～～～～～～～～～～～
ReentrantLock简介
ReentrantLock 是一种基于AQS框架的应用实现，是JDK中的一种线程并发访问的同步手段，它的功能类似于 synchronized 是一种互斥锁，可以保证线程安全。而且它具有比synchronized更多的特性，比如它支持手动加锁与解锁，支持加锁的公平性。
废话不多说，直接从构造开始撸：
ReentrantLock reentrantLock = new ReentrantLock(true); // true为公平锁 默认false
构造方法为以下两个：
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
对象实例化后调用其加锁方法：
reentrantLock.lock();
内部逻辑：
public void lock() {
sync.lock(); // 同步机制的实例（FairSync / NonfairSync）
}
其中 Sync 是 ReentrantLock 中的内部抽象类，它有两个实现类，本章以公平锁同步实例进行源码跟踪（主要区别是新的线程进入加锁逻辑时，非公平实现不会去看队列中是否有存在排队的线程，而是去直接尝试获取锁）。
上图看到 ReentrantLock 中的同步实例其实是继承自 AbstractQueuedSynchronizer（也就是本章要学习的AQS），首先来看看AQS中的主要结构：
Node内部类
/**
* Wait queue node class
*/
static final class Node {
// 标记节点未共享模式
static final Node SHARED = new Node();
// 标记节点为独占模式
static final Node EXCLUSIVE = null;
// 在同步队列中等待的线程等待超时或者被中断，需要从同步队列中取消等待
static final int CANCELLED = 1;
// 后继节点的线程处于等待状态，而当前的节点如果释放了同步状态或者被取消，将会通知后继节点，使后继节点的线程得以运行。
static final int SIGNAL = -1;
// 节点在等待队列中，节点的线程等待在Condition上，当其他线程对Condition调用了signal()方法后，该节点会从等待队列中转移到同步队列中，加入到同步状态的获取中
static final int CONDITION = -2;
// 表示下一次共享式同步状态获取将会被无条件地传播下去
static final int PROPAGATE = -3;
/**
* 标记当前节点的信号量状态 (1,0,-1,-2,-3)5种状态
* 使用CAS更改状态，volatile保证线程可见性，高并发场景下，
* 即被一个线程修改后，状态会立马让其他线程可见。
*/
volatile int waitStatus;
// 前继节点
volatile Node prev;
// 后继节点
volatile Node next;
// 持有的线程
volatile Thread thread;
// 在等待队列（共享模式）中这个字段是一个SHARED常量，在等待队列（独占模式）中它与后继节点指向同一个节点；在条件队列中维护单向链表结构关系
Node nextWaiter;
// 返回节点是否处于Shared状态下
final boolean isShared() {
return nextWaiter == SHARED;
}
// 返回前继节点
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
// Shared模式下的Node构造函数
Node() {
}
// 用于同步队列(CLH)addWaiter
Node(Thread thread, Node mode) {
this.nextWaiter = mode;
this.thread = thread;
}
// 用于条件队列Condition
Node(Thread thread, int waitStatus) {
this.waitStatus = waitStatus;
this.thread = thread;
}
}
基于Node实现AQS当中的同步等待队列
也称 CLH 队列，CLH 队列是Craig、Landin、Hagersten三人发明的一种基于双向链表数据结构的队列，是FIFO先入先出线程等待队列，Java中的CLH队列是原CLH队列的一个变种,线程由原自旋机制改为阻塞机制。
基于Node实现AQS当中的条件等待队列
Condition 是一个多线程间协调通信的工具类，使得某个，或者某些线程一起等待某个条件（Condition），只有当该条件具备时，这些等待线程才会被唤醒，从而重新争夺锁。
AQS的阻塞队列是以双向链表的形式保存，是通过 prev 和 next 建立起关系的。而AQS中的条件队列是以单向链表的形式保存，是通过 nextWaiter 建立起关系的。也就是说AQS中的阻塞队列和条件队列并非同一个队列。
了解完两种阻塞队列的实现原理，我们继续看AQS的其它重要属性：
// 指向同步等待队列的头节点
private transient volatile Node head;
// 指向同步等待队列的尾节点
private transient volatile Node tail;
// 同步资源状态
private volatile int state;
AQS的基本工作模型：
现在，我们已经对它做了初步的了解：AQS定义了一套多线程访问共享资源的同步器框架，是一个依赖状态（state）的同步器。
AQS内部维护了一个volatile语义（支持多线程下的可见性）的共享资源变量（state） 和一个FIFO线程等待队列（多线程竞争state 被阻塞时就会进入此队列）。
理论知识了解的差不多，我们继续回到加锁的逻辑上：
点击进入公平锁的 lock() 方法，发现它的加锁逻辑其实只是调用了它父类的 acquire() 方法，我们来跟踪分析一下它的实现逻辑。
public final void acquire(int arg) {
/**
* 1 .尝试获取锁失败后进入下个操作
* 2. 加入阻塞队列并再次尝试获取锁，失败后阻塞当前线程直到被唤醒，会返回一个当前线程是否被中断过的标识
*/
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
直接进入子类重写的 tryAcquire() 方法：
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState(); // 获取状态
if (c == 0) {
/**
* 1. 队列当中如果没有等待的节点
* 2. 如果没有则可以尝试CAS获取锁
*/
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
// 状态改变成功，独占模式的所有者设置为当前线程
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
// 当前线程可重入，state+1操作
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
从上面加锁逻辑我们证实了AQS同步器的确是依赖状态（state）的，如果获取锁失败呢？先看一下 addWaiter() 逻辑：
private Node addWaiter(Node mode) {
// 将当前线程构建成Node类型（独占模式）
Node node = new Node(Thread.currentThread(), mode);
// 尾节点不为空，说明队列已存在，直接从尾部插入
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
// 初始化队列并从尾部插入
enq(node);
return node;
}
入队完成后进入阻塞等待及不断自旋尝试获取锁阶段：
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;
}
/**
* 1. 判断是否应该被阻塞（pred.waitStatus == -1）
* 2. 阻塞当前线程 LockSupport.park(this) 并返回当前线程的中断状态
*/
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
acquireQueued()方法总结为3个步骤：
- addWriter() 将当前线程加入到等待队列的尾部，并标记为独占模式；
- acquireQueued() 使线程在等待队列中获取资源，直到获取到资源返回，若整个等待过程被中断过，则返回true，否则返回false。
- 如果线程在等待过程中被中断过，则先标记上，待获取到资源后再进行自我中断 selfInterrupt()，将中断响应掉。
再来看下 acquireQueued()中的 shouldParkAfterFailedAcquire()方法：
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
if (ws > 0) {
// 节点前移（移除已取消的前驱节点）
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.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
shouldParkAfterFailedAcquire() 方法是判断一个争用锁的线程是否应该被阻塞。它首先判断一个节点的前置节点的状态是否为Node.SIGNAL，如果是，说明此节点已经将状态设置-如果锁释放，则应当通知它，所以它可以安全的阻塞了，返回true。否则只能通过不断自旋和改变前驱节点状态来确认是否应该被阻塞。
到此，线程获取锁资源的代码（独占模式）就跟完了，总结一下过程：
- 首先线程通过 tryAcquire() 方法尝试获取共享资源，若获取成功则直接返回，若不成功，则将该线程以独占模式添加到等待队列尾部，tryAcquire() 方法由继承AQS的自定义同步器来具体实现；
- 当前线程加入等待队列后，会通过 acquireQueued() 方法基于 CAS 自旋不断尝试获取资源，直至获取到资源；
- 若在自旋过程中，线程被中断过，acquireQueued() 方法会标记此次中断，并返回true。
- 若 acquireQueued() 方法获取到资源后，返回 true，则执行线程自我中断操作 selfInterrupt()。
最后，我们一起看下 ReentrantLock 的解锁过程：
/**
* 释放独占模式持有的锁
*/
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
// 若头结点不为空且其ws值非0，则唤醒h的后继节点
unparkSuccessor(h);
return true;
}
return false;
}
点击 tryRelease() 进入 ReentrantLock类实现的 tryRelease()方法：
具体看下释放逻辑：
protected final boolean tryRelease(int releases) {
// 考虑到可重入，锁的数量减1
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;
}
锁资源释放成功后，开始唤醒后继节点，它传入的是head节点（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;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
// 判断后继节点是否为空或者是否是取消状态
if (s == null || s.waitStatus > 0) {
s = null;
/**
* 1. 从尾部向前遍历找到最前面的一个waitStatus小于0的节点（why？后续）
* 2. 退出条件：要唤醒的节点不为空并且不是当前已经释放锁资源的 head节点
*/
for (Node t = tail; t != null && t != node; t = t.prev)
// 只有节点处于ke才能被唤醒
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
// 节点唤醒后继续进入循环进一步尝试 tryAcquire()方法来获取锁
LockSupport.unpark(s.thread);
}
当阻塞队列中第一个等待节点被唤醒后，它就会继续在 acquireQueued()方法中尝试获取锁资源，之前分析过的逻辑截图如下，由于是公平锁实现缘故，它将会在此拿到锁资源：
总结
本章基于 ReentrantLock公平锁的独占锁实现，我们初步分析了AQS（同步队列，后续还会对条件队列进行分析）的实现过程。在获得同步锁时，同步器会维护一个同步队列，获取锁资源（状态）失败的线程都会被加入到队列中并在队列中进行自旋（阻塞）；移出队列（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用 tryRelease()方法释放同步状态，然后唤醒头节点的后继节点。
补充内容一：AQS对中断的支持
ReentrantLock 类的 lockInterruptibly()方法可以来响应线程的中断信号（线程如果在阻塞过程中被中断，会抛出InterruptedException异常）。下面我们看下关键实现：
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
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;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
// 若被中断，会立即向上抛出中断异常
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
与我们上面讲到的 acquireQueued()方法的区别：
当调用线程获取锁失败，进入阻塞后，如果中途被中断，acquireQueued()只是用一个标识记录线程被中断过，而 doAcquireInterruptibly()则是直接抛出异常。
补充内容二：AQS对限时等待的支持
ReentrantLock 类还有一个 tryLock()方法，用于在指定的时间内尝试获取锁，无论是否获取成功，只要超时，就返回结果。下面直接看重点方法：
public final boolean tryAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
// 支持响应中断
if (Thread.interrupted())
throw new InterruptedException();
/**
* 1. 尝试获取独占锁
* 2. 指定超时时间的入队等待逻辑
*/
return tryAcquire(arg) ||
doAcquireNanos(arg, nanosTimeout);
}
跟入 doAcquireNanos()方法，大体逻辑一致，不同之处见注释：
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
final long deadline = System.nanoTime() + nanosTimeout;
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 true;
}
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L)
// 在指定时间内未获取到锁，直接返回false
return false;
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
// 阻塞指定时长，超时则线程自动被唤醒
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
另外还要注意，当上面两种方式获取锁失败后，他们都会走 cancelAcquire() 来终结掉当前正在尝试获取锁的节点。
