AQS框架partⅠ-ReentrantLock非公平锁的加锁过程
Java中除了提供synchronized这个关键字来实现对对象的加锁之外，在J.U.C包中还提供了其他加锁的方式。其中最重要，最常见的莫过于ReentrantLock。ReentrantLock是一个可重入互斥锁，其具有与使用synchronized方法和语句访问的隐式监视锁相同的基本行为和语义，但具有更多功能，如支持非公平锁、支持可中断和超时机制等待。
ReentrantLock可分为公平锁和非公平锁。所谓的公平或非公平，是指对获取锁的线程不遵循“先到先得”这个原则。公平锁就是先到先得，非公平锁不是。ReentrantLock可通过构造方法来指定实现公平锁还是非公平锁。
其构造方法如下：
//同步器
private final Sync sync;
//非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
//fair为true时就是公平锁，否则为非公平锁
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
可以看出，公平锁或是非公平锁的实现依赖于NonfairSync或者FairSync来实现。
NonfairSync和FairSync都是内部类，他俩都继承了Sync这个类，而Sync这个内部类继承了AQS框架，从而具备了锁的功能。
/**
* Sync object for non-fair locks
* 非公平锁同步对象
*/
static final class NonfairSync extends Sync {......}
/**
* Sync object for fair locks
* 公平锁同步对象
*/
static final class FairSync extends Sync {......}
/**
* Base of synchronization control for this lock. Subclassed
* into fair and nonfair versions below. Uses AQS state to
* represent the number of holds on the lock.
* 锁的同步状态控制的基础类
*/
abstract static class Sync extends AbstractQueuedSynchronizer {......}
我们先不细看这些类中有哪些属性和方法。先专注于ReentrantLock。通常我们使用ReentrantLock就是为了使用它的加锁和解锁功能。那我先来看一下这两个方法。
/ **
*获取锁。如果没有被另一个线程持有，则获取锁并立即返回，将锁持有计数设置为1。如果当前* 线程已经持有该锁，那*么hold *计数将增加一，该方法将立即返回。 * * <p>如果该锁由另一个线程持有，则*当前线程将出于线程调度目的*而被禁用*并处于休眠状态，直到获取该锁为止，此时锁保持计数被设置为1。
* /
public void lock() {
sync.lock();
}
lock()方法其实是通过调用sync.lock()方法来实现的。sync取决于ReentrantLock的构造方法。我们先来看一下非公平锁的加锁方法。
非公平锁的加锁方法
final void lock() {
// 插队操作 CAS尝试加锁 0表示锁处于空闲状态，1表示锁处于被占有状态
if (compareAndSetState(0, 1))
//获取锁成功后设置当前线程为占有锁线程
setExclusiveOwnerThread(Thread.currentThread());
else
//若CAS操作失败，则执行acquire()方法
acquire(1);
}
上面就是非公平锁的加锁方法。逻辑其实很简单，先使用CAS尝试进行加锁，如果加锁成功的话，就将当前线程设置为占有锁的线程。若CAS获取锁失败的话，则执行acquire方法。这里就体现出非公平锁的特性，不排队，先插队尝试获取。acquire方法是AQS框架中的方法，如下所示：
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {
.............................
public final void acquire(int arg) {
//tryAcquire方法是一个抽象方法，是由其子类具体实现的
//addWaiter方法以独占锁的方法加入到队列当中
//acquireQueued 以自旋的方式获取锁
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
/**
*由各个子类自己实现
*/
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}
}
这里我们先不看addWaiter和acquireQueued方法，后面会讲解到。我们先看一下ReentrantLock中非公平锁是如何重写tryAcquire方法的。
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
final boolean nonfairTryAcquire(int acquires) {
//获取当前现场
final Thread current = Thread.currentThread();
//获取共享变量
int c = getState();
//c==0时表示还未加锁
if (c == 0) {
//使用CAS方式将c设置为acquires
if (compareAndSetState(0, acquires)) {
//成功的话就将当前线程设置为锁的拥有者
setExclusiveOwnerThread(current);
//返回加锁成功
return true;
}
}
//c!=0表示当前锁已被占有
//判断一下当前锁是不是被来加锁的线程占有
//这里就是偏向锁的使用
else if (current == getExclusiveOwnerThread()) {
//是的话，将c设置为c + acquires
int nextc = c + acquires;
//共享变量c是int 小于0 说明已经溢出
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
//将c设置为nextc
setState(nextc);
//返回加锁成功
return true;
}
//上面两种条件都不满足，说明锁当前被其他线程占有，加锁失败
return false;
}
上面的compareAndSetState，setExclusiveOwnerThread，getExclusiveOwnerThread以及setState方法都比较简单，可以自己点进去看看。
接下来说说addWaiter，当线程获取独占式锁失败后就会将当前线程加入同步队列，此时就会调用addWaiter方法，源码如下：
/**
* 将当前线程包装成Node节点，然后插入到等待队列当中
*/
private Node addWaiter(Node mode) {
// 将当前线程以给定的Node模式包装成一个Node节点
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
//尝试快速加入到队列尾部，如果失败的话再进行正常入队
//获取队列的尾结点
Node pred = tail;
//如果尾结点不为null 说明队列中此时已经有在排队的Node节点
if (pred != null) {
//将node的前置指针指向尾结点
node.prev = pred;
//将当前节点尾插入的方式插入同步队列中
//以CAS的方式将node设置为尾结点
//若是插入成功，则返回尾结点node
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
//若尾结点为null，说明当前线程是第一个加入同步队列进行等待的线程
//node节点开始入队
enq(node);
return node;
}
private Node enq(final Node node) {
//for循环实现自旋
for (;;) {
//获取尾结点
Node t = tail;
//尾结点为空，说明队列为空，此时必须进行初始化
if (t == null) { // Must initialize
//new Node()形成一个没有任何属性的空节点，然后CAS将其设置为队列的头节点
if (compareAndSetHead(new Node()))
//tail初始化与head一样
tail = head;
} else {
//将node的前置指针指向尾结点
node.prev = t;
//将当前节点尾插入的方式插入同步队列中
//以CAS的方式将node设置为尾结点
//若是插入成功，则返回尾结点node
//否则插入失败，则自旋不断尝试
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
好了，现在我们已经知道获取锁失败的线程会被包装成Node节点，然后插入到队列当中。那如果此时拥有锁的线程释放了锁，那队列中排队的线程如何获取锁呢？答案就在acquireQueued方法中。
final boolean acquireQueued(final Node node, int arg) {
// 标记是否成功拿到资源
boolean failed = true;
try {
// 标记等待过程中是否中断过
boolean interrupted = false;
//for循环实现自旋
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)
//清除 node 节点(清除的过程是先给 node 打上 CANCELLED标志, 然后再删除)
cancelAcquire(node);
}
}
private void setHead(Node node) {
//将node设置为头节点
head = node;
//node的线程和前驱节点都设置为null
node.thread = null;
node.prev = null;
}
上面的注释已经说的很清楚了，若是当前节点的前驱节点是头节点，且可以通过tryAcquire方法获取到锁，则将当前线程设置为头节点，同时为了方便gc回收，将之前的头节点的引用进行释放。若是加锁失败了，则会继续调用shouldParkAfterFailedAcquire方法和parkAndCheckInterrupt方法。那这两个方法又是什么用处呢？
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//获取前继Node节点的waitStaus
//几种waitStatus会在下面注释
int ws = pred.waitStatus;
//如果ws等于SIGNAL状态，说明头结点处于唤醒状态 直接return true
if (ws == Node.SIGNAL)
return true;
//若是ws大于0，说明处于取消状态
if (ws > 0) {
// 通过 do while循环，向前查找已经被设置为取消的节点
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
//把取消节点从队列中剔除
pred.next = node;
} else {
//若ws是其他状态，则设置当前节点的前继节点的等待状态为 SIGNAL
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
//CANCELLED 说明节点已经 取消获取 lock 了(一般是由于 interrupt 或 timeout 导致的)
static final int CANCELLED = 1;
//SIGNAL 标识当前节点的后继节点需要唤醒(PS: 这个通常是在 独占模式下使用, 在共享模式下有时用 // PROPAGATE)
static final int SIGNAL = -1;
shouldParkAfterFailedAcquire方法实际上就是入队线程被挂起的过程，示意图如下：
parkAndCheckInterrupt方法就比较简单了，其底层调用的是LockSupport#park方法，将当前线程挂起，实现线程的阻塞，并检查当前线程是否中断。
private final boolean parkAndCheckInterrupt() {
//阻塞当前线程
LockSupport.park(this);
//检查是否中断
return Thread.interrupted();
}
综合来看，整个acquiredQueued方法前半部分的流程如下所示：
若是在整个获取锁的过程中，出现失败，如线程中断，则此时cancelAcquire方法就要排上用场了。cancelAcquire 会将当前节点从等待队列中移除，具体过程如下所示。
private void cancelAcquire(Node node) {
// 将无效节点过滤
if (node == null)
return;
//将该节点的线程设置为null，即不关联任何线程，也就是虚节点
node.thread = null;
// 通过前驱节点，跳过取消状态的 node
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
// 获取过滤后的前驱节点的后继节点
// //node前置节点的后置节点，不一定是node
Node predNext = pred.next;
// 把当前 node 的状态设置为 CANCELLED
node.waitStatus = Node.CANCELLED;
// 如果当前节点是尾节点，更新tail为pred
if (node == tail && compareAndSetTail(node, pred)) {
//如果更新成功，将 tail 的后继节点设置为 null
compareAndSetNext(pred, predNext, null);
} else {
// 1.如果当前节点不是 head 的后继节点，
// 2. 判断当前节点前驱节点的是否为 SIGNAL，
// 3. 如果不是，则把前驱节点设置为 SINGAL 看是否成功
// 如果 2 和 3 中有一个为 true，再判断当前节点的线程是否为 null
// 如果上述条件都满足，把当前节点的前驱节点的后继指针指向当前节点的后继节点
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) {
Node next = node.next;
if (next != null && next.waitStatus <= 0)
compareAndSetNext(pred, predNext, next);
} else {
// 如果当前节点是 head 的后继节点，或者上述条件不满足，那就唤醒当前节点的后继节点
unparkSuccessor(node);
}
//最终把取消acquire的 node的next指针指向的它自己
node.next = node; // help GC
}
}
cancelAcquire主要流程如下：
1.获取当前节点的前驱节点，如果前驱节点的状态是CANCELLED，那就一直向前遍历，直到waitStatus<=0的节点，将当前Node的状态设置为CANCELLED。
根据当前节点的位置，有以下三种情况：
(1)当前节点为尾节点，此时node的出队过程如下所示：
(ⅰ) cancelAcquire()调用compareAndSetTail()方法将tail指向pred;
(ⅱ) cancelAcquire()调用compareAndSetNext()方法将pred的后继节点设置为null
(2)node既不是tail，也不是head的后继节点
cancelAcquire()调用了compareAndSetNext()方法将pred指向successor。将successor指向pred是谁干的？
执行 cancelAcquire 的时候，当前节点的前置节点可能已经从队列中出去了 （已经执行过 Try 代码块中的 shouldParkAfterFailedAcquire 方法了），如果此时修改 Prev 指针，有可能会导致 Prev 指向另一个已经移除队列的 Node， 因此这块变化 Prev 指针不安全。 shouldParkAfterFailedAcquire 方法中， 会执行下面的代码，其实就是在处理Prev 指针。shouldParkAfterFailedAcquire 是获取锁失败的情况下才会执行，进入该方法后，说明共享资源已 被获取，当前节点之前的节点都不会出现变化，因此这个时候变更 Prev 指针 比较安全。情况2最后如下所示：
shouldParkAfterFailedAcquire中：
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
(3)node是head的后继节点
``cancelAcquire()调用了unparkSuccessor()，不过，unparkSuccessor()中并没有对队列做任何调整呀。 这次，cancelAcquire()对于出队这件事情可以说是啥都没干。 出队操作实际上是由unparkSuccessor()唤醒的线程执行的。 unparkSuccessor()会唤醒successor结点，当被唤醒后将会实际执行出队操作。 现在需要搞清楚successor是从什么地方恢复执行的呢？这要看successor`是在哪里被挂起的。
successor线程是从acquireQueued中的parkAndCheckInterrupt被挂起的，恢复执行时，也从此处开始重新执行。successor将会重新执行acquireQueued中的for循环，此时，node尚未出队，successor的前继节点依然是node，而不是head。所以，successor会执行到shouldParkAfterFailedAcquire()处。而从场景2中可以得知，shouldParkAfterFailedAcquire()中将会调整successor的prev指针（同时也调整head的next指针），从而完成了node的出队操作 ，最后如下所示：
解锁方法
与加锁不同，解锁对于公平锁还是非公平锁都是一样的。
public void unlock() {
sync.release(1);
}
方法其实很简单，都是直接调用了sync#release方法。这其实是AQS框架里的一个方法，子类可以直接调用的。
public final boolean release(int arg) {
// 调用子类重写的tryRelease方法
if (tryRelease(arg)) {
//如果成功的话 获取同步队列的头结点
Node h = head;
//如果头节点不为null 且不是初始状态
if (h != null && h.waitStatus != 0)
//从头开始唤醒等待锁的节点
unparkSuccessor(h);
return true;
}
return false;
}
先来看一下Sync重写的tryRelease方法吧，还是比较简单的。
protected final boolean tryRelease(int releases) {
// 获取更新过后的state变量大小
int c = getState() - releases;
// 如果不是拥有锁的线程来解锁 直接抛出异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
// 标记
boolean free = false;
if (c == 0) {
// 如果 state此时为0 说明处于空闲的状态
free = true;
//将占有锁的线程设为null
setExclusiveOwnerThread(null);
}
//若不为0 说明是可重入锁 此时要更新state的状态
setState(c);
// 返回标记
return free;
}
接下来继续看 unparkSuccessor方法，它的主要作用就是当线程释放锁成功后，从 node 开始唤醒同步队列中的节点，通过唤醒机制,保证线程不会一直在同步队列中阻塞等待。
private void unparkSuccessor(Node node) {
//当前node节点的等待状态，即头结点的等待状态
int ws = node.waitStatus;
// 如果小于0的，则直接重新置为初始化状态
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
//方法传递进来的node其实是同步队列的头结点 也就是获取头结点的下一个节点
Node s = node.next;
// 判断下一个节点是否为空 或者 是被取消的状态
if (s == null || s.waitStatus > 0) {
s = null;
//是的话 开始从尾向前开始遍历 找到第一个 waitStatus 字段不是被取消的
// 从尾向前遍历主要是因为节点是被在 acquireQueued 方法里面调用的parkAndCheckInterrupt方法
//阻塞的，唤醒时也一定会在 acquireQueued 方法里面被唤醒，此时继续执行acquireQueued的
//for(;;)，此时的判断条件是，当前节点的前置节点是否是头节点。而如果在unparkSuccessor方法这里
//采用从尾到头的遍历顺序，通过一些条件的过滤，则可以提前将那些无效的前置节点给过滤掉，这样就可以
//避免线程刚被唤醒，继续执行acquireQueued方法中的for循环时又被阻塞中。
for (Node t = tail; t != null && t != node; t = t.prev)
// 等待状态<=0 说明不是处于取消状态 肯定还在等待被唤醒
if (t.waitStatus <= 0)
//将t赋给s
s = t;
}
if (s != null)
//唤醒s的线程
LockSupport.unpark(s.thread);
}
这里重点是要弄清楚为什么要从尾向前遍历，主要目的是为了避免被唤醒的线程在继续执行acquireQueued的循环时又被阻塞，这样的话，就会线程就会一直被阻塞住不能被释放掉。
总结
上面就是ReentrantLock非公平锁的加锁和解锁过程了，公平锁的加锁过程少了抢占compareAndSetState这一步插队操作，其余的均与非公平锁的加锁操作一样，这也是公平与非公平锁的主要区别。解锁过程对于公平锁和非公平锁都是一样的流程。
参考
美团后台篇中的ReentrantLock https://juejin.im/post/5e37824ff265da3e3a5381b8#heading-14
深入剖析ReentrantLock公平锁与非公平锁源码实现 https://juejin.im/post/5de622076fb9a016510d82bb#heading-1
