JAVASE-3 多线程体系2-ReentrantLock源码
背景：
在并发场景下，为了保证线程安全，需要进行加锁操作。
在使用ReentrantLock时需要手动加锁解锁，这一点区分于Synchronized的自动释放。
所以在使用ReentrantLock时一定要遵循java编码规范，在try块钱调用lock()方法获取锁，在finnally块中调用unlock()方法释放锁，这样保证锁一定能被正确释放。Synchronized代码块是通过monitorenter 和 monitorexit 指令来实现的，ReentrantLock的实现原理呢？
本文重点在于结合源码介绍ReentrantLock的实现原理。这个过程中会涉及到AQS，针对涉及到的点进行AQS相关的介绍。
ReentrantLock源码介绍
下面进入ReentrantLock原码分析，ReentrantLock实现了Lock接口。
1.lock
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}
包括了4个加锁接口，一个释放锁的接口，以及一个生成Condition对象的接口。源码分析就从这些加锁、解锁接口进入并深入，至于newCondition()在JAVASE-3 多线程体系2-Condition与ConditionObject中详细介绍。
2.ReentrantLock
先整体看一下ReentrantLock这个类的内部组成：
public class ReentrantLock implements Lock, Serializable {
private final ReentrantLock.Sync sync;
public ReentrantLock() {
this.sync = new ReentrantLock.NonfairSync();
}
public ReentrantLock(boolean isFair) {
this.sync = (ReentrantLock.Sync)(isFair? new ReentrantLock.FairSync() : new ReentrantLock.NonfairSync());
}
static final class FairSync extends ReentrantLock.Sync { // 省略FairSync逻辑}
static final class NonfairSync extends ReentrantLock.Sync { // 省略NonfairSync逻辑}
abstract static class Sync extends AbstractQueuedSynchronizer{ // 省略Sync逻辑}
// 此处省略ReentrantLock的其他方法，lock系列，unlock,...
}
内部定义了一个Sync类，该类继承自AQS；定义了两个Sync的子类：FairSync和NonfairSync，从名字可以看出这两个子类的区别在于获取锁的策略是否公平。从默认构造函数可以看出，ReentrantLock默认支持不公平的锁策略。
在简单看一下ReentrantLock关于Lock的实现：
private final ReentrantLock.Sync sync;
public void lock() {
this.sync.lock();
}
public void lockInterruptibly() throws InterruptedException {
this.sync.acquireInterruptibly(1);
}
public boolean tryLock() {
return this.sync.nonfairTryAcquire(1);
}
public boolean tryLock(long var1, TimeUnit var3) throws InterruptedException {
return this.sync.tryAcquireNanos(1, var3.toNanos(var1));
}
public void unlock() {
this.sync.release(1);
}
public Condition newCondition() {
return this.sync.newCondition();
}
可以看出，Lock中提供的方法最终都调用了sync的方法来实现，ReentrantLock就是提供了一层封装而已。ReentrantLock就是基于AQS来实现的，因此本文不可避免地需要接触AQS。
由于这部分涉及的概念较多，且代码量比较大，因此只对涉及内容进行简单讲解。本文涉及的ReentrantLock是一个独占锁，因此对AQS的介绍会有所聚焦；对AQS内容感兴趣，可以参考：JAVASE-3 多线程体系10-AQS源码。
ReentrantLock不仅是独占性质的锁，从名字可以看出来，还具有可重入性。这两点在AQS中体现在两个实例变量上：Thread类型的exclusiveOwnerThread 和 int类型的state。
ReentrantLock的sync继承自AQS，每个ReentrantLock实例都对应一个sync实例变量，因此每个ReentrantLock对象多对应一个exclusiveOwnerThread和state变量, 即每个ReentrantLock都有一把锁。
exclusiveOwnerThread 和 state 的使用方式如下：
当没有线程获取锁时，exclusiveOwnerThread为null,state等于1；
当锁被线程获取时，exclusiveOwnerThread指向获取锁的线程，state变成1；
当该线程再次获取锁时，state加1；释放锁的时候，也是没释放一次，state减1。
这里介绍的内容都会在下文的代码解析里体现。首先看一下NonfairSync和FairSync的继承体系：
从上图可以看出，Sync中定义了nonfairTryAcquire(int)和tryRelease(int)
NonfairSync和FairSync中分别重写了lock()和tryAcquire(int)。
因此释放锁，没有公平与否的概念，走的都是Sync中的tryRelease(int)逻辑。
接下来我们先看一下非公平锁是怎么实现的，再对比一下公平锁。
非公平锁 lock()
final void lock() {
acquire(1);
}
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {
selfInterrupt();
}
}
lock() 直接调用AQS的acquire(1);在acquire中有一个条件!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
这里的tryAcquire就是上面提到的NonfairSync和FairSync自己重载的方法。
我们看一下NonfairSync的tryAcquire方法：
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
非公平锁的tryAcquire直接调用了Sync类中定义的nonfairTryAcquire方法。
因此非公平锁的lock()主要实现逻辑就在nonfairTryAcquire方法：
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){
throw new Error("Maximum lock count exceeded");
}
setState(nextc);
return true;
}
return false;
}
先获取state的值，如果是state的值等于，0表示没有被加锁：则使用CAS方式将state加1，
然后当前线程的值赋值给exclusiveOwnerThread。
如果不等于0，表示锁已经被线程占用，这时需要判断是不是自己占用了锁：current == getExclusiveOwnerThread()；如果是该线程占用了锁，则是重入，对state加1，否则，尝试加锁失败-返回false。
=> tryAcquire(int args) 就是一次尝试加锁，如果加锁成功-返回true,加锁失败返回false;
继续回到!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)，
tryAcquire(arg)加锁成功了，就不会执行后面的条件判断了，直接退出；
加锁失败后，进入acquireQueued(addWaiter(Node.EXCLUSIVE), arg)，首先执行addWaiter(Node.EXCLUSIVE)，将当前线程加入到等待队列中:
private Node addWaiter(Node mode) {
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;
}
第一步构造一个Node对象new Node(Thread.currentThread(), mode),mode是Node.EXCLUSIVE，为null，是一个标志位(在AQS中独占锁用null表示，new Node()表示共享锁，存在nextWaiter变量里)；
接下来：
if (pred != null) {
Node pred = tail;
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
cas需要和自旋配合才可以起作用，这里只是进行了一次判断，如果可以使用cas将新创建的节点设置为尾节点，则操作成功，并退出。如果一次不成功呢？
没关系，还有enq()方法：
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) {
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
enq()就是一个自旋+cas的组合，将新创建的节点加入到同步队列的尾部；
这里是不是有点疑惑，那为什么addWaiter上多此一举地加了一次cas判断？
其实是作了一层优化：一次判断如果可以退出，没必要再进自旋块。
=> addWaiter方法时使用当前线程构造一个Node对象，加入同步队列中，并返回该Node对象。
这个Node对象会传参给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);
}
}
主体内容在一个自旋块中，线程如果获取不到锁，就会一直阻塞在这个自旋逻辑中，直到成功获取锁。
在介绍这个逻辑之前，先说明一下AQS对于独占锁的唤醒机制：
当前节点用currentNode表示，前驱节点用preNode表示，因此有以下关系：currentNode.prev == preNode;
(1) currentNode由preNode唤醒;
(2) preNode必须时Signal的，才能唤醒currentNode;
(3) 只有当preNode位于同步队列的头结点时，才会触发唤醒currentNode操作；
接下来，我们继续看自旋的主体逻辑线：
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;
}
}
该自旋逻辑只有一个退出执行点:return interrupted;，且位于p == head && tryAcquire(arg)条件逻辑中。说明只有node的前驱节点是头结点，然后调用tryAcquire获取锁成功时，才会退出该自旋逻辑(获取锁成功后，会把node设置为头结点)。
在看一下第二个条件语句：shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()；注意：这个条件语句也是存在于自旋块中的。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
return true;
if (ws > 0) {
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
shouldParkAfterFailedAcquire方法比较清晰，使用cas方式将node的前驱节点设置为SIGNAL状态；
同步队列的Node有4种状态:CANCELLED=1, SIGNAL=-1; CONDITION=-2; PROPAGATE=-3;
pred.waitStatus > 0表示该节点所在的线程已经被cancel了；设置前驱节点的过程也会更新同步对类信息，剔除已经被cancel的节点。
在shouldParkAfterFailedAcquire配合着自旋块，将node的前驱节点状态设置为SIGNAL时；再次自旋进入shouldParkAfterFailedAcquire方法会返回true；此时会调用parkAndCheckInterrupt()方法：
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
该方法逻辑简单，直接调用LockSupport.park(this);使得该线程休眠，等待被前驱节点唤醒。
=> 至此，非公平整个lock的解锁逻辑以及清楚了。
在此基础上了解公平锁lock就比较简单了。
从下面的图可以看出，NonfairSync和FairSync的区别仅在于lock()和tryAcquire(int),至于获取锁失败后怎么添加到同步队列是没有区别的。
// 公平锁
final void lock() {
acquire(1);
}
// 非公平锁
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
对比两个lock()方法：
公平锁按照获取锁的流程调用acquire(1);来获取锁；
非公平锁，直接先试探一下能否获取锁成功，失败了再调用acquire(1);获取锁。
acquire会调用tryAcquire，在前面介绍过，这里不再赘述。正如前文所述，在tryAcquire中非公平锁，直接进行尝试加锁。
我们再看一下公平锁下的加锁策略：
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;
}
}
在尝试加锁之前，先调用hasQueuedPredecessors判断是否已经有其他线程在等待锁了，如果没有才会加锁，如果有了返回false表示加锁失败。其实在tryAcquire中已经可以实现公平和非公平加锁的区别了，在非公平锁的lock()里的一次尝试加锁是一层优化。
对比可以发现：
非公平锁，可以避免线程等待时间，省去了释放cpu和获取cpu的时间。
假如线程A准备加锁时，已经有线程B和C在同步队列中等待，这时锁正好被线程D释放；此时A就不需要先去队列排序，再被唤醒，而是直接获取锁；这样从整体的角度，省去了一次线程切换的时间开销，有助于提高程序运行效率。
这样也直接导致了一个问题，从A后面由A1，A2，A3……他们到来的时候，锁正好被释放，那么B和C就会一直等下去，出现线程饥饿线程。
unlock()
unlock在公平锁和非公平锁中没有区分，调用的是同一个方法：
public void unlock() {
sync.release(1);
}
进入Sync的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;
}
release方法中涉及tryRelease和unparkSuccessor两个方法：
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;
}
tryRelease方法直接操作state和exclusiveOwnerThread变量，先给state将去需要释放锁的数量，然后判断如果state为0，就将exclusiveOwnerThread置为null。
其中 if (Thread.currentThread() != getExclusiveOwnerThread())是为了保证释放锁的操作需要由只有锁的线程来进行。
当线程占用的锁都释放完成后，即state变为0的时候，release(1)返回true,此时进入
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
这里调用unparkSuccessor(h)唤醒头结点的一个有效的后继节点。因为独占锁只能被一个线程所占用，所以没必要唤醒很多线程，然后让他们去竞争-从而浪费资源。在后续文章中提及的共享锁，和这里有所区分，一次会唤醒多个线程，届时会详细介绍。
我们再看一下unparkSuccessor方法的逻辑:
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0) {
compareAndSetWaitStatus(node, ws, 0);
}
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev){
if (t.waitStatus <= 0){
s = t;
}
}
}
if (s != null){
LockSupport.unpark(s.thread);
}
}
这里头结点的后继节点不为null,则调用LockSupport.unpark(s.thread);激活该线程，否则Node t = tail; t != null && t != node; t = t.prev：从尾结点开始便利，直到遇到一个没有被cancel的节点。
是不是有个疑问：为什么不是释放头结点，而是释放头结点的后继节点？
这里，我们需要结合前面的addWaiter方法一起介绍：
在addWaiter方法中，调用enq方法将线程加入到同步队列中，中有一个判断：判断头结点是否为空；
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
t == null表示头结点和尾结点都为null,此时调用compareAndSetHead(new Node())创建了一个新的头结点，后续因获取锁失败而阻塞的线程都会添加在这个头结点之后。这就是为什么当锁完全被释放后，释放节点要从头结点的后继节点开始。所以，释放锁的过程是FIFO，是公平的。
其他方法
除了lock()和unlock()之外，Lock接口中还定义了tryLock()，lockInterruptibly()，tryLock(long var1, TimeUnit var3)方法，是对功能的补充，本质的实现都是依赖于AQS。
tryLock() 和 tryLock(long, TimeUnit)
tryLock()不是一个阻塞方法，如果获取成功返回true, 获去失败返回false:
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
可以看出tryLock()直接调用了上面介绍的nonfairTryAcquire()方法尝试获取锁，是一次性判断(不是自旋)，也是一个非公平性质的加锁操作。
至于tryLock(long times, TimeUnit unit)无非是一个具有超时机制的加锁操作，在等待times时间，还没有获取到锁，就返回false；否则加锁成功-返回true。
public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
调用的是tryAcquireNanos方法：
public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException {
if (Thread.interrupted()) throw new InterruptedException();
return tryAcquire(arg) || doAcquireNanos(arg, nanosTimeout);
}
逻辑和acquire方法比较相似，不同点是：在调用tryAcquireNanos过程中，如果线程被中断了会抛出中断异常。
再看一下具有延时功能的doAcquireNanos方法，由于代码与前面介绍的加锁过程极其相似，只挑出主线逻辑进行介绍：
private boolean doAcquireNanos(int arg, long nanosTimeout) throws InterruptedException {
final long deadline = System.nanoTime() + nanosTimeout;
final Node node = addWaiter(Node.EXCLUSIVE);
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
return true;
}
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L)
return false;
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();
}
} // 省略部分逻辑，突出矛盾的主要方面
除了正常加锁之外，多了一层判断，如果事件超时了，if (nanosTimeout <= 0L)，则返回false; 因为超时后，需要自动被唤醒，所以不能调用LockSupport.park方法，此处调用的是LockSupport.parkNanos(this, nanosTimeout);
lockInterruptibly()
看到这个方法就知道这个方法时lock的copy版本，增加一个响应中断的能力。
在介绍lock时未曾提到会抛出InterruptedException异常，事实上，Lock接口提供的加锁操作只有lockInterruptibly()和tryLock(long timeout, TimeUnit unit)具有响应中断的能力。
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
调用acquireInterruptibly加锁：
public final void acquireInterruptibly(int arg) throws InterruptedException {
if (Thread.interrupted()){
throw new InterruptedException();
}
if (!tryAcquire(arg)){
doAcquireInterruptibly(arg);
}
}
如果此时线程被中段，就会抛出InterruptedException异常；
加锁成功，会直接返回；如果加锁失败，就会进入doAcquireInterruptibly()
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);
}
}
parkAndCheckInterrupt执行完后，会返回这个过程中线程是否被中断过，这里因为和lock加锁过程一致，不再详细介绍。
但是这里有一处需要看一下：
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
相同的逻辑在lock()中是这样的：
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
之后因为返回的interrupted 是true, 而调用Thread.currentThread().interrupt();使线程处于中断状态，而不是抛出异常。
除此之外，还有一个newCondition()方法，用于生成一个Condition对象，这里不再讲解了。放在ConditionObject文章中一起讲解。