目录
一、概述
ReentrantLock 是JDK1.5 引入的J.U.C包中的一个比较重要的可重入的、互斥的并且支持公平和非公平的锁，其实现了 Lock接口，其内部是通过 AQS + CAS 原理实现的。其具备 synchronized 关键字加锁的所有功能，并且还具备一些 synchronized 锁不具备的功能，比如：尝试拿锁，支持中断、支持超时等待等。
二、什么是可重入锁
可重入锁，顾明思议，就是支持重进入的锁，它表示该锁能够支持同一个线程对资源的重复加锁。通俗来讲就是 如果线程 A 已经获取的锁，那么在线程A在未释放锁时，线程A 再次来申请锁，那么此时不会被阻塞，而是可以重复进入，只是锁的计数器加1。
如果互斥锁不支持可重入的话，比如在递归场景下就会造成死锁。
三、公平锁和非公平锁
公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。
-
优点：所有的线程都能得到资源，不会饿死在队列中。
-
缺点：吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大。
非公平锁：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。
-
优点：可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。
-
缺点：你们可能也发现了，这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。
四、ReentrantLock 实现原理
1、ReentrantLock类继承层次
在介绍ReentrantLock 的实现原理之前我们先看看，ReentrantLock 类继承层次。
图列说明：I：表示接口，A：表示抽象类，C：表示类，$表示内部类。实线表示继承关系，虚线表示引用关系。由上图可知道，ReentrantLock 内部也是基于 AQS 实现的。
2、基本实现原理
Sync的父类 AbstractQueuedSynchronizer 经常被称作队列同步器（AQS），该类的父类是 AbstractOwnableSynchronizer。为了实现一把具有阻塞或唤醒功能的锁，需要几个核心要素：
(1)、 需要一个state变量，标记该锁的状态。state变量至少有两个值：0、1。对state变量的操作，要确保线程安全，也就是会用到CAS。
(2)、 需要记录当前是哪个线程持有锁。
(3)、 需要底层支持对一个线程进行阻塞或唤醒操作。
(4)、 需要有一个队列维护所有阻塞的线程。这个队列也必须是线程安全的无锁队列，也需要用到CAS。
针对于(1)、(2)两种情况 是通过 AbstractQueuedSynchronizer 和 AbstractOwnableSynchronizer 类中的满足的。如下所示：
public abstract class AbstractOwnableSynchronizer{
.....
private transient Thread exclusiveOwnerThread; // 记录持有锁的线程
.....
}
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer {
......
private volatile int state; // 记录当前的锁的同步状态，是通过 CAS 操作。
......
}由 AbstractQueuedSynchronizer 源码可知 其可以记录当前持有锁的线程(exclusiveOwnerThread 记录的值)，已经当前锁的同步状态(state 的值)，其中 state 为 0 表示当前没有锁没有被占有，state 为 1，表示锁已被占有，state 的还可以大于 1，此时表示，锁被重入了。例如，state 等于 3，表示线程 重入了 3次。在释放是也需要释放三次。
针对有 （3）阻塞与唤醒 LockSupport的工具类中对原语做了简单封，如下所示：
public class LockSupport {
//禁用当前线程的线程调度
public static void park(Object blocker) {
Thread t = Thread.currentThread();
setBlocker(t, blocker);
UNSAFE.park(false, 0L); // 最终调用的是 Unsafe类中的 park 方法
setBlocker(t, null);
}
// 唤醒 指定的线程
public static void unpark(Thread thread) {
if (thread != null)
UNSAFE.unpark(thread); //最终调用的是 Unsafe类中的 unpark 方法
}
}针对要素 (4) 是通过 在 AQS 中维护类一个双向队列，通过 CAS 操作实现的，如下所示：
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer {
static final class Node { // 节点
volatile Thread thread; // 当前线程引用
volatile Node prev; // 前置节点
volatile Node next; // 后续节点
}
private transient volatile Node head; // 头结点
private transient volatile Node tail; // 尾结点
......
}阻塞队列是整个AQS核心中的核心，head指向双向链表头部，tail指向双向链表尾部。当锁已被占用后，后续申请锁的线程就会被构造成一个Node，插入到队列中，入队就是把新的 Node 加到tail后面，然后对tail进行CAS操作；出队就是对head进行CAS操作，把head向后移一个位置。队列结构如下所：
3、ReentrantLock 的实现
ReentrantLock是现象了 Lock 接口，其内部实现非常简单，其中获取锁和释放锁的操作都是委托给了其内部类 Sync ( 其继承了 AbstractQueuedSynchronizer 并实现类其模板方法) 来实现的。具体源码可以自行查看，都非常简答。接下来主要分析一下 Sync 的实现。
Sync 也是一个抽象类，其有两个子类，分别为 NonfairSync (非公平锁) 和 FairSync (公平锁)，都实现了 Sync 的抽象方法 lock();
3.1、公平锁和非公平锁的实现差异
非公平锁：
static final class NonfairSync extends Sync {
final void lock() {
// 上来就更改 state 状态，也就是抢锁
// 不考虑队列中有没有其他线程在排队，体现了非公平锁
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());// 如果抢成功则设置锁的拥有者为当前线程
else
acquire(1); // 如果抢占失败则进行重新申请
}
}公平锁：
static final class FairSync extends Sync {
final void lock() {
acquire(1); // 没有上了就抢锁，而是调用此方法，进行排队。
}
}由两者的实现源码可知 非公平锁 “不讲武德”来了就更新 state 的状态，也就是抢锁，当抢不到了才去排队，而公平锁则是来了就去排队等待。其中的 acquire() 是 AQS 中的一个模板方法，具体如下：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}其内部的 调用 tryAcquire(int arg) 方法尝试拿锁，但是，tryAcquire() 方法是个空方法，需要子类进行去实现。那么在看看 NonfairSync (非公平锁) 和 FairSync (公平锁) 对这个方法的实现差异，
//非公平锁
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {// 如果当前 state 为0，就更新state的状态不考虑有没有线程排队
//如果更新成功则设置锁的所有者为当前线程
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
//如果 state 不为0 表示锁已被占用，则判断锁的拥有者是否为当前线程
//如果是当前线程 则 state 加 1；
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;
}
//公平锁
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;
}这两段代码非常相似，唯一的区别是公平锁中多了 一个 if （！hasQueuedPredecessors（））。什么意思呢？就是只有当c==0（没有线程持有锁），并且排在队列的第1个时（即当队列中没有其他线程的时候），才去抢锁，否则继续排队，这才是 讲武德 (公平)！
3.2、阻塞与唤醒
在上面的 acquire() 方法中可以看到，当调用 tryAcquire() 方法返回 false 后回调 acquireQueued(addWaiter(Node.EXCLUSIVE), arg)，此方法的作用就是把当前线程构造成一个Node节点，然后进行阻塞。
先说addWaiter（..）函数，就是为当前线程生成一个Node，然后把Node放入双向链表的尾部。要注意的是，这只是把Thread对象放入了一个队列中而已，线程本身并未阻塞（Node.EXCLUSIVE 表示构造一个独占节点）。
private Node addWaiter(Node mode) {
// 把申请资源的当前线程 构造成一个 Node 节点 mode 为模式( 独占 或 共享 )
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail; // 取到尾结点
if (pred != null) { //如果尾结点不为空 则尝试把新构建节点 同 CAS 操作插入到尾部
node.prev = pred;
if (compareAndSetTail(pred, node)) { // 先尝试把节点加入到队列尾部，如果不成功则调用下
pred.next = node; // 面的 enq 方法通过 CAS + 自旋的方式加入到队列尾部
return node;
}
}
enq(node); // 如果 插入失败，则进行“自旋 + CAS” 操作插入尾部。
return node;
}调用addWaiter(mode) 方法把包含 Thread 对象的节点加入阻塞队列之后的工作就会调用 acquireQueued() 方法来完成线程的阻塞功能。线程一旦进入acquireQueued() 就会被无限期阻塞，即使有其他线程调用 interrupt() 方法也不能将其唤醒，除非有其他线程释放了锁，并且该线程拿到了锁，才会从accquireQueued() 返回。注意：进入acquireQueued()，该线程被阻塞。在该函数返回的一刻，就是拿到锁的那一刻，也就是被唤醒的那一刻，此时会删除队列的第一个元素（head指针前移1个节点）。
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;
}
//如果自己可以休息了，就通过park()进入waiting状态，直到被unpark()。
// 如果不可中断的情况下被中断了，那么会从park()中醒过来，发现拿不到资源，从而继续进入park()等待。
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}acquireQueued() 方法的返回值表示在它阻塞期间是否有其他线程对它发出了中断信号。如果有，则该函数会返回true；否则，返回false。
我们再次看下 acquire() 方法
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt(); // 如果 acquireQueued() 方法返回true，则进行中断补偿
}
static void selfInterrupt() {
Thread.currentThread().interrupt(); // 重新发出中断信号
}有上面代码我们看到，当acquireQueued() 方法返回true时，回调selfInterrupt()方法自己给自己发送中断信号，也就是自己把自己的中断标志位设为true。之所以要这么做，是因为自己在阻塞期间，收到其他线程中断信号没有及时响应，现在要进行补偿。这样一来，如果该线程在lock代码块内部有调用sleep（）之类的阻塞方法，就可以抛出异常，响应该中断信号。
接下来我们在看看 acquireQueued() 方法中对线程的阻塞部分。在线程进行阻塞之前会先判断此线程需不需要阻塞。如下所示：
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus; // 前驱节点状态
if (ws == Node.SIGNAL) //如果前驱节点的状态为 SIGNAL 返回出则进行阻塞
return true;
if (ws > 0) { // 如果前驱节点已取消(超时或者被中断)，则节点往前移，把已取消的节点
// 都移除调用
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
// 否则把前驱节点的状态更新为 SIGNAL 也就是当前驱节点释放
// 锁后唤醒当前线程去抢锁。
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}如果调用 shouldParkAfterFailedAcquire() 方法返回ture,则当前线程进行休眠等待，具体操作如下：
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this); // 进行休眠
return Thread.interrupted(); // 当被唤醒后返回当前线程是否被中断过
}parkAndCheckInterrupt 方法中调用 park() 方法使当前线程进行休眠，也就是自己把自己阻塞起来，直到被其他线程唤醒，该函数返回。park() 函数返回有两种情况。
情况1：其他线程调用了unpark()。
情况2：其他线程调用了t.interrupt()。
需要注意的是，lock() 不能响应中断，但 LockSupport.park() 会响应中断。也正因为LockSupport.park() 可能被中断唤醒，所以 acquireQueued() 方法才写了一个for死循环。唤醒之后，如果发现自己排在队列头部，就去拿锁；如果拿不到锁，则再次自己阻塞自己。不断重复此过程，直到拿到锁。被唤醒之后，通过 Thread.interrupted() 来判断是否被中断唤醒。如果是情况1，会返回false；如果是情况2，则返回true。
3.3、释放锁原理
聊完了lock，下面分析unlock的实现。unlock不区分公平还是非公平。
// 释放锁 ReentrantLock 中的方法
public void unlock() {
sync.release(1); // 释放锁 AbstractQueuedSynchronizer 中的方法
}
// 释放锁 AbstractQueuedSynchronizer 中的模板方法
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;
}
// ReentrantLock.$Sync 中的方法
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
// 只有拥有锁的线程才能释放锁，否则 抛出异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) { //没调用1次tryRelease，state 减 1 直到 为0才才表示锁释放成功
free = true;
setExclusiveOwnerThread(null);
}
setState(c); // 关键点：因为是排他锁，只有获取锁的线程才可以调用tryRelease方法进行释放锁，
// 所以此处 没有使用 CAS 操作。
return free;
}通过分析源码 我们知道调用 unlock() 方法实际是调用了 AQS中的 release()方法。release() 里面做了两件事：一是调用 tryRelease() 方法释放锁；一是调用 unparkSuccessor() 方法唤醒队列中的后继者。
关键说明：
因为 ReentrantLock 是排他锁，只有已经持有锁的线程才有资格调用 releas()，这意味着没有其他线程与它争抢。所以，在上面的tryRelease() 方法中，对state值的修改，不需要CAS操作，直接减1即可。
我们在看下 unparkSuccessor 方法：
private void unparkSuccessor(Node node) {
int ws = node.waitStatus; // 获取节点的状态
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
//unpark的线程被保存在后续节点中，后者通常只是下一个节点。
// 但如果取消或明显为空，则从尾部向后遍历，以找到实际未取消的后继项
Node s = node.next; // 获取头结点的后续节点
// 如果后续节点为null,或者 状态为已取消 (超时 或 被中断)
// 侧从 尾结点开始变量，找到第一个未放弃的线程
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);
}
unparkSuccessor() 方法也很简单，其主要逻辑就是拿到当前节点的后继节点，然后进行唤醒。有一点值的注意的是，当当前节点的后继节点为null 或者 为取消状态时，回从队列的尾部开始遍历，直到找到第一个未取消的节点，进行唤醒。
3.4、acquireInterruptibly() 分析
lock 是不能被中断，而 lockInterruptibly() 是可以被中断，下面看一下两者在实现上有什么差别。
// ReentrantLock 中方法
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
// AbstractQueuedSynchronizer 中方法
public final void acquireInterruptibly(int arg) throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}从上面代码中我们可以发现，acquireInterruptibly() 也是AQS中的一个模板方法，其内部调用 tryAcquire() 方法与上面lock方法是一样的，在此不再赘序。我们重点看下 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);
}
}其实现原理与 accquireQueued() 方法非常相似，主要的区别就是，当parkAndCheckInterrupt() 返回 true 的时候，说明有其他线程发送中断信号，直接抛出InterruptedException，跳出for循环，整个函数返回。
3.5、tryLock()实现分析
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}tryLock() 实现基于调用非公平锁的tryAcquire()，对state进行CAS操作，如果操作成功就拿到锁；如果操作不成功则直接返回false，也不阻塞。
五、总结
我们说了什么是重入锁，公平锁和非公平锁的优缺点。通过源码的方式分析了ReentrantLock的实现原理，其内部实现很简单，主要功能都是基于AQS 来实现的，弄明白了AQS的原理不但能够清楚 ReentrantLock实现原理，JUC包中的很多工具类都是基于AQS实现的。
参考文献：
《Java并发实现原理：JDK源码剖析》
《Java并发编程的艺术》
《Java并发编程实战》