**【1】**什么是可重入，什么是可重入锁? 它用来解决什么问题?
【2】ReentrantLock 的核心是 AQS，那么它怎么来实现的，继承吗? 说说其类内部结构关系。
【3】ReentrantLock 是如何实现公平锁的?
【4】ReentrantLock 是如何实现非公平锁的?
【5】ReentrantLock 默认实现的是公平还是非公平锁?
【6】使用ReentrantLock 实现公平和非公平锁的示例?
【7】ReentrantLock 和 Synchronized的对比?
下面通过伪代码，进行更加直观的比较：
1 // **************************Synchronized的使用方式**************************
2 // 1.用于代码块
3 synchronized (this) {}
4 // 2.用于对象
5 synchronized (object) {}
6 // 3.用于方法
7 public synchronized void test () {}
8 // 4.可重入
9 for (int i = 0; i < 100; i++) {
10 synchronized (this) {}
11 }
12 // **************************ReentrantLock的使用方式**************************
13 public void test () throw Exception {
14 // 1.初始化选择公平锁、非公平锁
15 ReentrantLock lock = new ReentrantLock(true);
16 // 2.可用于代码块
17 lock.lock();
18 try {
19 try {
20 // 3.支持多种加锁方式，比较灵活; 具有可重入特性
21 if(lock.tryLock(100, TimeUnit.MILLISECONDS)){ }
22 } finally {
23 // 4.手动释放锁
24 lock.unlock()
25 }
26 } finally {
27 lock.unlock();
28 }
29 }
二、ReentrantLock 源码分析
1、类的继承关系
ReentrantLock 实现了 Lock接口，Lock接口中定义了 lock与 unlock相关操作，并且还存在 newCondition方法，表示生成一个条件。
public class ReentrantLock implements Lock, java.io.Serializable
2、类的内部类
ReentrantLock 总共有三个内部类，并且三个内部类是紧密相关的，下面先看三个类的关系。
说明：ReentrantLock 类内部总共存在Sync、NonfairSync、FairSync三个类，NonfairSync与 FairSync类继承自 Sync类，Sync类继承自 AbstractQueuedSynchronizer抽象类。下面逐个进行分析。
AQS提供了大量用于自定义同步器实现的 Protected方法。自定义同步器实现的相关方法也只是为了通过修改 State字段来实现多线程的独占模式或者共享模式。自定义同步器需要实现以下方法（ReentrantLock需要实现的方法如下，并不是全部）：
| 方法名 | 描述 |
| protected boolean isHeldExclusively() | 该线程是否正在独占资源。只有用到Condition才需要去实现它。 |
| protected boolean tryAcquire(int arg) | 独占方式。arg为获取锁的次数，尝试获取资源，成功则返回True，失败则返回False。 |
| protected boolean tryRelease(int arg) | 独占方式。arg为释放锁的次数，尝试释放资源，成功则返回True，失败则返回False。 |
| protected int tryAcquireShared(int arg) | 共享方式。arg为获取锁的次数，尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。 |
| protected boolean tryReleaseShared(int arg) | 共享方式。arg为释放锁的次数，尝试释放资源，如果释放后允许唤醒后续等待结点返回True，否则返回False。 |
一般来说，自定义同步器要么是独占方式，要么是共享方式，它们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。ReentrantLock是独占锁，所以实现了tryAcquire-tryRelease。以非公平锁为例，这里主要阐述一下非公平锁与AQS之间方法的关联之处，具体每一处核心方法的作用会在文章后面详细进行阐述。
Sync 类的源码如下：
1 abstract static class Sync extends AbstractQueuedSynchronizer {
2 // 序列号
3 private static final long serialVersionUID = -5179523762034025860L;
4
5 // 获取锁
6 abstract void lock();
7
8 // 非公平方式获取
9 final boolean nonfairTryAcquire(int acquires) {
10 // 当前线程
11 final Thread current = Thread.currentThread();
12 // 获取状态
13 int c = getState();
14 if (c == 0) { // 表示没有线程正在竞争该锁
15 if (compareAndSetState(0, acquires)) { // 比较并设置状态成功，状态0表示锁没有被占用
16 // 设置当前线程独占
17 setExclusiveOwnerThread(current);
18 return true; // 成功
19 }
20 }
21 else if (current == getExclusiveOwnerThread()) { // 当前线程拥有该锁
22 int nextc = c + acquires; // 增加重入次数
23 if (nextc < 0) // overflow
24 throw new Error("Maximum lock count exceeded");
25 // 设置状态
26 setState(nextc);
27 // 成功
28 return true;
29 }
30 // 失败
31 return false;
32 }
33
34 // 试图在共享模式下获取对象状态，此方法应该查询是否允许它在共享模式下获取对象状态，如果允许，则获取它
35 protected final boolean tryRelease(int releases) {
36 int c = getState() - releases;
37 if (Thread.currentThread() != getExclusiveOwnerThread()) // 当前线程不为独占线程
38 throw new IllegalMonitorStateException(); // 抛出异常
39 // 释放标识
40 boolean free = false;
41 if (c == 0) {
42 free = true;
43 // 已经释放，清空独占
44 setExclusiveOwnerThread(null);
45 }
46 // 设置标识
47 setState(c);
48 return free;
49 }
50
51 // 判断资源是否被当前线程占有
52 protected final boolean isHeldExclusively() {
53 return getExclusiveOwnerThread() == Thread.currentThread();
54 }
55
56 // 新生一个条件
57 final ConditionObject newCondition() {
58 return new ConditionObject();
59 }
60
61 // 返回资源的占用线程
62 final Thread getOwner() {
63 return getState() == 0 ? null : getExclusiveOwnerThread();
64 }
65 // 返回状态
66 final int getHoldCount() {
67 return isHeldExclusively() ? getState() : 0;
68 }
69
70 // 资源是否被占用
71 final boolean isLocked() {
72 return getState() != 0;
73 }
74
75 // 自定义反序列化逻辑
76 private void readObject(java.io.ObjectInputStream s)
77 throws java.io.IOException, ClassNotFoundException {
78 s.defaultReadObject();
79 setState(0); // reset to unlocked state
80 }
81 }
NonfairSync 类继承了 Sync类，表示采用非公平策略获取锁，其实现了 Sync类中抽象的 lock方法，源码如下：从 lock方法的源码可知，每一次都尝试获取锁，而并不会按照公平等待的原则进行等待，让等待时间最久的线程获得锁。Acquire方法是 FairSync和 UnfairSync的父类 AQS中的核心方法。
// 非公平锁
2 static final class NonfairSync extends Sync {
3 // 版本号
4 private static final long serialVersionUID = 7316153563782823691L;
5
6 // 获得锁
7 final void lock() {
8 /**
9 * 若通过CAS设置变量State（同步状态）成功，也就是获取锁成功，则将当前线程设置为独占线程。
10 * 若通过CAS设置变量State（同步状态）失败，也就是获取锁失败，则进入Acquire方法进行后续处理。
11 */
12 if (compareAndSetState(0, 1)) // 比较并设置状态成功，状态0表示锁没有被占用
13 // 把当前线程设置独占了锁
14 setExclusiveOwnerThread(Thread.currentThread());
15 else // 锁已经被占用，或者set失败
16 // 以独占模式获取对象，忽略中断
17 acquire(1); //Acquire方法是FairSync和UnfairSync的父类AQS中的核心方法。
18 }
19
20 protected final boolean tryAcquire(int acquires) {
21 return nonfairTryAcquire(acquires);
22 }
23 }
FairSync 类也继承了 Sync类，表示采用公平策略获取锁，其实现了 Sync类中的抽象 lock方法，源码如下：
// 公平锁
2 static final class FairSync extends Sync {
3 // 版本序列化
4 private static final long serialVersionUID = -3000897897090466540L;
5
6 final void lock() {
7 // 以独占模式获取对象，忽略中断
8 acquire(1);
9 }
10
11 // 尝试公平获取锁
12 protected final boolean tryAcquire(int acquires) {
13 // 获取当前线程
14 final Thread current = Thread.currentThread();
15 // 获取状态
16 int c = getState();
17 if (c == 0) { // 状态为0
18 if (!hasQueuedPredecessors() &&
19 compareAndSetState(0, acquires)) { // 不存在已经等待更久的线程并且比较并且设置状态成功
20 // 设置当前线程独占
21 setExclusiveOwnerThread(current);
22 return true;
23 }
24 }
25 else if (current == getExclusiveOwnerThread()) { // 状态不为0，即资源已经被线程占据
26 // 下一个状态
27 int nextc = c + acquires;
28 if (nextc < 0) // 超过了int的表示范围
29 throw new Error("Maximum lock count exceeded");
30 // 设置状态
31 setState(nextc);
32 return true;
33 }
34 return false;
35 }
36 }
跟踪 lock方法的源码可知，当资源空闲时，它总是会先判断 sync队列(AbstractQueuedSynchronizer中的数据结构)是否有等待时间更长的线程，如果存在，则将该线程加入到等待队列的尾部，实现了公平获取原则。其中，FairSync 类的 lock的方法调用如下，只给出了主要的方法。
可以看出只要资源被其他线程占用，该线程就会添加到 sync queue中的尾部，而不会先尝试获取资源。这也是和 Nonfair最大的区别，Nonfair每一次都会尝试去获取资源，如果此时该资源恰好被释放，则会被当前线程获取，这就造成了不公平的现象，当获取不成功，再加入队列尾部。
为了帮助大家理解 ReentrantLock和 AQS之间方法的交互过程，以非公平锁为例，我们将加锁和解锁的交互流程单独拎出来强调一下，以便于对后续内容的理解。
加锁：
通过ReentrantLock的加锁方法Lock进行加锁操作。
会调用到内部类Sync的Lock方法，由于Sync#lock是抽象方法，根据ReentrantLock初始化选择的公平锁和非公平锁，执行相关内部类的Lock方法，本质上都会执行AQS的Acquire方法。
AQS的Acquire方法会执行tryAcquire方法，但是由于tryAcquire需要自定义同步器实现，因此执行了ReentrantLock中的tryAcquire方法，由于ReentrantLock是通过公平锁和非公平锁内部类实现的tryAcquire方法，因此会根据锁类型不同，执行不同的tryAcquire。
tryAcquire是获取锁逻辑，获取失败后，会执行框架 AQS的后续逻辑，跟ReentrantLock自定义同步器无关。
解锁：
通过 ReentrantLock的解锁方法 Unlock进行解锁。
Unlock会调用内部类 Sync的 Release方法，该方法继承于AQS。
Release中会调用 tryRelease方法，tryRelease需要自定义同步器实现，tryRelease只在ReentrantLock中的Sync实现，因此可以看出，释放锁的过程，并不区分是否为公平锁。
释放成功后，所有处理由AQS框架完成，与自定义同步器无关。
通过上面的描述，大概可以总结出 ReentrantLock加锁解锁时 API层核心方法的映射关系。
3、类的属性
ReentrantLock 类的 sync非常重要，对ReentrantLock 类的操作大部分都直接转化为对 sync和 AQS类的操作。
1 public class ReentrantLock implements Lock, java.io.Serializable {
2 // 序列号
3 private static final long serialVersionUID = 7373984872572414699L;
4 // 同步队列
5 private final Sync sync;
6 }
4、类的构造函数
ReentrantLock 构造函数：默认是采用的非公平策略获取锁
1 public ReentrantLock() {
2 // 默认非公平策略
3 sync = new NonfairSync();
4 }
ReentrantLock(boolean) 构造函数：可以传递参数确定采用公平策略或者是非公平策略，参数为 true表示公平策略，否则，采用非公平策略。
1 public ReentrantLock(boolean fair) {
2 sync = fair ? new FairSync() : new NonfairSync();
3 }
5、核心函数分析
通过分析 ReentrantLock的源码，可知对其操作都转化为对 Sync对象的操作，由于 Sync继承了 AQS，所以基本上都可以转化为对 AQS的操作。如将 ReentrantLock的 lock函数转化为对 Sync的 lock函数的调用，而具体会根据采用的策略(如公平策略或者非公平策略)的不同而调用到 Sync的不同子类。所以可知，在 ReentrantLock的背后，是 AQS对其服务提供了支持。下面还是通过例子来更进一步分析源码。
三、线程加入等待队列
加入队列的时机
当执行Acquire(1)时，会通过tryAcquire获取锁。在这种情况下，如果获取锁失败，就会调用 addWaiter加入到等待队列中去。
如何加入队列
获取锁失败后，会执行 addWaiter(Node.EXCLUSIVE)加入等待队列，具体实现方法如下：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private Node addWaiter(Node mode) {
4 Node node = new Node(Thread.currentThread(), mode);
5 // Try the fast path of enq; backup to full enq on failure
6 Node pred = tail;
7 if (pred != null) {
8 node.prev = pred;
9 if (compareAndSetTail(pred, node)) {
10 pred.next = node;
11 return node;
12 }
13 }
14 enq(node);
15 return node;
16 }
17 private final boolean compareAndSetTail(Node expect, Node update) {
18 return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
19 }
主要的流程如下：
通过当前的线程和锁模式新建一个节点。
Pred指针指向尾节点Tail。
将New中Node的Prev指针指向Pred。
通过compareAndSetTail方法，完成尾节点的设置。这个方法主要是对 tailOffset和 Expect进行比较，如果 tailOffset的 Node和 Expect的 Node地址是相同的，那么设置 Tail的值为 Update的值。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 static {
4 try {
5 stateOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("state"));
6 headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head"));
7 tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
8 waitStatusOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("waitStatus"));
9 nextOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("next"));
10 } catch (Exception ex) {
11 throw new Error(ex);
12 }
13 }从AQS的静态代码块可以看出，都是获取一个对象的属性相对于该对象在内存当中的偏移量，这样我们就可以根据这个偏移量在对象内存当中找到这个属性。tailOffset指的是 tail对应的偏移量，所以这个时候会将 new出来的 Node置为当前队列的尾节点。同时，由于是双向链表，也需要将前一个节点指向尾节点。
如果 Pred指针是 Null（说明等待队列中没有元素），或者当前 Pred指针和 Tail指向的位置不同（说明被别的线程已经修改），就需要看一下 Enq的方法。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private Node enq(final Node node) {
4 for (;;) {
5 Node t = tail;
6 if (t == null) { // Must initialize
7 if (compareAndSetHead(new Node()))
8 tail = head;
9 } else {
10 node.prev = t;
11 if (compareAndSetTail(t, node)) {
12 t.next = node;
13 return t;
14 }
15 }
16 }
17 }如果没有被初始化，需要进行初始化一个头结点出来。但请注意，初始化的头结点并不是当前线程节点，而是调用了无参构造函数的节点。如果经历了初始化或者并发导致队列中有元素，则与之前的方法相同。其实，addWaiter就是一个在双端链表添加尾节点的操作，需要注意的是，双端链表的头结点是一个无参构造函数的头结点。
总结一下，线程获取锁的时候，过程大体如下：
当没有线程获取到锁时，线程1获取锁成功。
线程2申请锁，但是锁被线程1占有。
如果再有线程要获取锁，依次在队列中往后排队即可。
回到上边的代码，hasQueuedPredecessors是公平锁加锁时判断等待队列中是否存在有效节点的方法。如果返回False，说明当前线程可以争取共享资源；如果返回True，说明队列中存在有效节点，当前线程必须加入到等待队列中。
1 // java.util.concurrent.locks.ReentrantLock
2
3 public final boolean hasQueuedPredecessors() {
4 // The correctness of this depends on head being initialized
5 // before tail and on head.next being accurate if the current
6 // thread is first in queue.
7 Node t = tail; // Read fields in reverse initialization order
8 Node h = head;
9 Node s;
10 return h != t && ((s = h.next) == null || s.thread != Thread.currentThread());
11 }
看到这里，我们理解一下h != t && ((s = h.next) == null || s.thread != Thread.currentThread());为什么要判断的头结点的下一个节点？第一个节点储存的数据是什么？
双向链表中，第一个节点为虚节点，其实并不存储任何信息，只是占位。真正的第一个有数据的节点，是在第二个节点开始的。当h != t时： 如果(s = h.next) == null，等待队列正在有线程进行初始化，但只是进行到了Tail指向Head，没有将Head指向Tail，此时队列中有元素，需要返回True（这块具体见下边代码分析）。 如果(s = h.next) != null，说明此时队列中至少有一个有效节点。如果此时s.thread == Thread.currentThread()，说明等待队列的第一个有效节点中的线程与当前线程相同，那么当前线程是可以获取资源的；如果s.thread != Thread.currentThread()，说明等待队列的第一个有效节点线程与当前线程不同，当前线程必须加入进等待队列。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer#enq
2
3 if (t == null) { // Must initialize
4 if (compareAndSetHead(new Node()))
5 tail = head;
6 } else {
7 node.prev = t;
8 if (compareAndSetTail(t, node)) {
9 t.next = node;
10 return t;
11 }
12 }
节点入队不是原子操作，所以会出现短暂的head != tail，此时Tail指向最后一个节点，而且Tail指向Head。如果Head没有指向Tail（可见5、6、7行），这种情况下也需要将相关线程加入队列中。所以这块代码是为了解决极端情况下的并发问题。
等待队列中线程出队列时机
回到最初的源码：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 public final void acquire(int arg) {
4 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
5 selfInterrupt();
6 }
上文解释了addWaiter方法，这个方法其实就是把对应的线程以 Node的数据结构形式加入到双端队列里，返回的是一个包含该线程的Node。而这个 Node会作为参数，进入到 acquireQueued方法中。acquireQueued方法可以对排队中的线程进行“获锁”操作。总的来说，一个线程获取锁失败了，被放入等待队列，acquireQueued会把放入队列中的线程不断去获取锁，直到获取成功或者不再需要获取（中断）。
下面我们从“何时出队列？”和“如何出队列？”两个方向来分析一下acquireQueued源码：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 final boolean acquireQueued(final Node node, int arg) {
4 // 标记是否成功拿到资源
5 boolean failed = true;
6 try {
7 // 标记等待过程中是否中断过
8 boolean interrupted = false;
9 // 开始自旋，要么获取锁，要么中断
10 for (;;) {
11 // 获取当前节点的前驱节点
12 final Node p = node.predecessor();
13 // 如果p是头结点，说明当前节点在真实数据队列的首部，就尝试获取锁（别忘了头结点是虚节点）
14 if (p == head && tryAcquire(arg)) {
15 // 获取锁成功，头指针移动到当前node
16 setHead(node);
17 p.next = null; // help GC
18 failed = false;
19 return interrupted;
20 }
21 // 说明p为头节点且当前没有获取到锁（可能是非公平锁被抢占了）或者是p不为头结点，这个时候就要判断当前node是否要被阻塞（被阻塞条件：前驱节点的waitStatus为-1），防止无限循环浪费资源。具体两个方法下面细细分析
22 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
23 interrupted = true;
24 }
25 } finally {
26 if (failed)
27 cancelAcquire(node);
28 }
29 }
注：setHead方法是把当前节点置为虚节点，但并没有修改waitStatus，因为它是一直需要用的数据。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private void setHead(Node node) {
4 head = node;
5 node.thread = null;
6 node.prev = null;
7 }
8
9 // java.util.concurrent.locks.AbstractQueuedSynchronizer
10
11 // 靠前驱节点判断当前线程是否应该被阻塞
12 private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
13 // 获取头结点的节点状态
14 int ws = pred.waitStatus;
15 // 说明头结点处于唤醒状态
16 if (ws == Node.SIGNAL)
17 return true;
18 // 通过枚举值我们知道waitStatus>0是取消状态
19 if (ws > 0) {
20 do {
21 // 循环向前查找取消节点，把取消节点从队列中剔除
22 node.prev = pred = pred.prev;
23 } while (pred.waitStatus > 0);
24 pred.next = node;
25 } else {
26 // 设置前任节点等待状态为SIGNAL
27 compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
28 }
29 return false;
30 }
parkAndCheckInterrupt主要用于挂起当前线程，阻塞调用栈，返回当前线程的中断状态。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private final boolean parkAndCheckInterrupt() {
4 LockSupport.park(this);
5 return Thread.interrupted();
6 }
上述方法的流程图如下：
从上图可以看出，跳出当前循环的条件是当“前置节点是头结点，且当前线程获取锁成功”。为了防止因死循环导致CPU资源被浪费，我们会判断前置节点的状态来决定是否要将当前线程挂起，具体挂起流程用流程图表示如下（shouldParkAfterFailedAcquire流程）：
从队列中释放节点的疑虑打消了，那么又有新问题了：
shouldParkAfterFailedAcquire中取消节点是怎么生成的呢？什么时候会把一个节点的waitStatus设置为-1？
是在什么时间释放节点通知到被挂起的线程呢？
四、CANCELLED状态节点生成
acquireQueued方法中的 Finally代码：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 final boolean acquireQueued(final Node node, int arg) {
4 boolean failed = true;
5 try {
6 ...
7 for (;;) {
8 final Node p = node.predecessor();
9 if (p == head && tryAcquire(arg)) {
10 ...
11 failed = false;
12 ...
13 }
14 ...
15 } finally {
16 if (failed)
17 cancelAcquire(node);
18 }
19 }
通过cancelAcquire方法，将Node的状态标记为CANCELLED。接下来，我们逐行来分析这个方法的原理：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private void cancelAcquire(Node node) {
4 // 将无效节点过滤
5 if (node == null)
6 return;
7 // 设置该节点不关联任何线程，也就是虚节点
8 node.thread = null;
9 Node pred = node.prev;
10 // 通过前驱节点，跳过取消状态的node
11 while (pred.waitStatus > 0)
12 node.prev = pred = pred.prev;
13 // 获取过滤后的前驱节点的后继节点
14 Node predNext = pred.next;
15 // 把当前node的状态设置为CANCELLED
16 node.waitStatus = Node.CANCELLED;
17 // 如果当前节点是尾节点，将从后往前的第一个非取消状态的节点设置为尾节点
18 // 更新失败的话，则进入else，如果更新成功，将tail的后继节点设置为null
19 if (node == tail && compareAndSetTail(node, pred)) {
20 compareAndSetNext(pred, predNext, null);
21 } else {
22 int ws;
23 // 如果当前节点不是head的后继节点，1:判断当前节点前驱节点的是否为SIGNAL，2:如果不是，则把前驱节点设置为SINGAL看是否成功
24 // 如果1和2中有一个为true，再判断当前节点的线程是否为null
25 // 如果上述条件都满足，把当前节点的前驱节点的后继指针指向当前节点的后继节点
26 if (pred != head && ((ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) && pred.thread != null) {
27 Node next = node.next;
28 if (next != null && next.waitStatus <= 0)
29 compareAndSetNext(pred, predNext, next);
30 } else {
31 // 如果当前节点是head的后继节点，或者上述条件不满足，那就唤醒当前节点的后继节点
32 unparkSuccessor(node);
33 }
34 node.next = node; // help GC
35 }
36 }
当前的流程：
获取当前节点的前驱节点，如果前驱节点的状态是CANCELLED，那就一直往前遍历，找到第一个waitStatus <= 0的节点，将找到的Pred节点和当前Node关联，将当前Node设置为CANCELLED。
根据当前节点的位置，考虑以下三种情况：
(1) 当前节点是尾节点。
(2) 当前节点是Head的后继节点。
(3) 当前节点不是Head的后继节点，也不是尾节点。
根据上述第二条，我们来分析每一种情况的流程。
当前节点是尾节点。
当前节点是Head的后继节点。
当前节点不是Head的后继节点，也不是尾节点。
通过上面的流程，我们对于CANCELLED节点状态的产生和变化已经有了大致的了解，但是为什么所有的变化都是对Next指针进行了操作，而没有对Prev指针进行操作呢？什么情况下会对Prev指针进行操作？
执行cancelAcquire的时候，当前节点的前置节点可能已经从队列中出去了（已经执行过Try代码块中的shouldParkAfterFailedAcquire方法了），如果此时修改Prev指针，有可能会导致Prev指向另一个已经移除队列的Node，因此这块变化Prev指针不安全。 shouldParkAfterFailedAcquire方法中，会执行下面的代码，其实就是在处理Prev指针。shouldParkAfterFailedAcquire是获取锁失败的情况下才会执行，进入该方法后，说明共享资源已被获取，当前节点之前的节点都不会出现变化，因此这个时候变更Prev指针比较安全。
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
五、如何解锁
我们已经剖析了加锁过程中的基本流程，接下来再对解锁的基本流程进行分析。由于 ReentrantLock在解锁的时候，并不区分公平锁和非公平锁，所以我们直接看解锁的源码：
1 // java.util.concurrent.locks.ReentrantLock
2
3 public void unlock() {
4 sync.release(1);
5 }
可以看到，本质释放锁的地方，是通过框架来完成的。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 public final boolean release(int arg) {
4 if (tryRelease(arg)) {
5 Node h = head;
6 if (h != null && h.waitStatus != 0)
7 unparkSuccessor(h);
8 return true;
9 }
10 return false;
11 }
在ReentrantLock里面的公平锁和非公平锁的父类Sync定义了可重入锁的释放锁机制。
1 // java.util.concurrent.locks.ReentrantLock.Sync
2
3 // 方法返回当前锁是不是没有被线程持有
4 protected final boolean tryRelease(int releases) {
5 // 减少可重入次数
6 int c = getState() - releases;
7 // 当前线程不是持有锁的线程，抛出异常
8 if (Thread.currentThread() != getExclusiveOwnerThread())
9 throw new IllegalMonitorStateException();
10 boolean free = false;
11 // 如果持有线程全部释放，将当前独占锁所有线程设置为null，并更新state
12 if (c == 0) {
13 free = true;
14 setExclusiveOwnerThread(null);
15 }
16 setState(c);
17 return free;
18 }
我们来解释下述源码：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 public final boolean release(int arg) {
4 // 上边自定义的tryRelease如果返回true，说明该锁没有被任何线程持有
5 if (tryRelease(arg)) {
6 // 获取头结点
7 Node h = head;
8 // 头结点不为空并且头结点的waitStatus不是初始化节点情况，解除线程挂起状态
9 if (h != null && h.waitStatus != 0)
10 unparkSuccessor(h);
11 return true;
12 }
13 return false;
14 }
这里的判断条件为什么是h != null && h.waitStatus != 0？
h == null Head还没初始化。初始情况下，head == null，第一个节点入队，Head会被初始化一个虚拟节点。所以说，这里如果还没来得及入队，就会出现head == null 的情况。
h != null && waitStatus == 0 表明后继节点对应的线程仍在运行中，不需要唤醒。
h != null && waitStatus < 0 表明后继节点可能被阻塞了，需要唤醒。
再看一下 unparkSuccessor方法：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private void unparkSuccessor(Node node) {
4 // 获取头结点waitStatus
5 int ws = node.waitStatus;
6 if (ws < 0)
7 compareAndSetWaitStatus(node, ws, 0);
8 // 获取当前节点的下一个节点
9 Node s = node.next;
10 // 如果下个节点是null或者下个节点被cancelled，就找到队列最开始的非cancelled的节点
11 if (s == null || s.waitStatus > 0) {
12 s = null;
13 // 就从尾部节点开始找，到队首，找到队列第一个waitStatus<0的节点。
14 for (Node t = tail; t != null && t != node; t = t.prev)
15 if (t.waitStatus <= 0)
16 s = t;
17 }
18 // 如果当前节点的下个节点不为空，而且状态<=0，就把当前节点unpark
19 if (s != null)
20 LockSupport.unpark(s.thread);
21 }
为什么要从后往前找第一个非Cancelled的节点呢？原因如下。
之前的 addWaiter方法：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private Node addWaiter(Node mode) {
4 Node node = new Node(Thread.currentThread(), mode);
5 // Try the fast path of enq; backup to full enq on failure
6 Node pred = tail;
7 if (pred != null) {
8 node.prev = pred;
9 if (compareAndSetTail(pred, node)) {
10 pred.next = node;
11 return node;
12 }
13 }
14 enq(node);
15 return node;
16 }我们从这里可以看到，节点入队并不是原子操作，也就是说，node.prev = pred; compareAndSetTail(pred, node) 这两个地方可以看作Tail入队的原子操作，但是此时pred.next = node;还没执行，如果这个时候执行了unparkSuccessor方法，就没办法从前往后找了，所以需要从后往前找。还有一点原因，在产生CANCELLED状态节点的时候，先断开的是Next指针，Prev指针并未断开，因此也是必须要从后往前遍历才能够遍历完全部的Node。
综上所述，如果是从前往后找，由于极端情况下入队的非原子操作和CANCELLED节点产生过程中断开Next指针的操作，可能会导致无法遍历所有的节点。所以，唤醒对应的线程后，对应的线程就会继续往下执行。继续执行acquireQueued方法以后，中断如何处理？
六、中断恢复后的执行流程
唤醒后，会执行 return Thread.interrupted();，这个函数返回的是当前执行线程的中断状态，并清除。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 private final boolean parkAndCheckInterrupt() {
4 LockSupport.park(this);
5 return Thread.interrupted();
6 }
再回到 acquireQueued代码，当 parkAndCheckInterrupt返回True或者False的时候，interrupted的值不同，但都会执行下次循环。如果这个时候获取锁成功，就会把当前 interrupted返回。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 final boolean acquireQueued(final Node node, int arg) {
4 boolean failed = true;
5 try {
6 boolean interrupted = false;
7 for (;;) {
8 final Node p = node.predecessor();
9 if (p == head && tryAcquire(arg)) {
10 setHead(node);
11 p.next = null; // help GC
12 failed = false;
13 return interrupted;
14 }
15 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
16 interrupted = true;
17 }
18 } finally {
19 if (failed)
20 cancelAcquire(node);
21 }
22 }
如果acquireQueued为True，就会执行selfInterrupt方法。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 static void selfInterrupt() {
4 Thread.currentThread().interrupt();
5 }
该方法其实是为了中断线程。但为什么获取了锁以后还要中断线程呢？这部分属于Java提供的协作式中断知识内容，感兴趣同学可以查阅一下。这里简单介绍一下：
当中断线程被唤醒时，并不知道被唤醒的原因，可能是当前线程在等待中被中断，也可能是释放了锁以后被唤醒。因此我们通过Thread.interrupted()方法检查中断标记（该方法返回了当前线程的中断状态，并将当前线程的中断标识设置为False），并记录下来，如果发现该线程被中断过，就再中断一次。
线程在等待资源的过程中被唤醒，唤醒后还是会不断地去尝试获取锁，直到抢到锁为止。也就是说，在整个流程中，并不响应中断，只是记录中断记录。最后抢到锁返回了，那么如果被中断过的话，就需要补充一次中断。
这里的处理方式主要是运用线程池中基本运作单元Worder中的runWorker，通过Thread.interrupted()进行额外的判断处理，感兴趣的同学可以看下ThreadPoolExecutor源码。
七、小结
我们在1.3小节中提出了一些问题，现在来回答一下。
Q：某个线程获取锁失败的后续流程是什么呢？
A：存在某种排队等候机制，线程继续等待，仍然保留获取锁的可能，获取锁流程仍在继续。
Q：既然说到了排队等候机制，那么就一定会有某种队列形成，这样的队列是什么数据结构呢？
A：是CLH变体的FIFO双端队列。
Q：处于排队等候机制中的线程，什么时候可以有机会获取锁呢？
A：可以详细看下2.3.1.3小节。
Q：如果处于排队等候机制中的线程一直无法获取锁，需要一直等待么？还是有别的策略来解决这一问题？
A：线程所在节点的状态会变成取消状态，取消状态的节点会从队列中释放，具体可见2.3.2小节。
Q：Lock函数通过Acquire方法进行加锁，但是具体是如何加锁的呢？
A：AQS的Acquire会调用tryAcquire方法，tryAcquire由各个自定义同步器实现，通过tryAcquire完成加锁过程。
八、AQS应用
**ReentrantLock的可重入应用：**ReentrantLock的可重入性是 AQS很好的应用之一，在了解完上述知识点以后，我们很容易得知ReentrantLock实现可重入的方法。在ReentrantLock里面，不管是公平锁还是非公平锁，都有一段逻辑。
公平锁：
1 // java.util.concurrent.locks.ReentrantLock.FairSync#tryAcquire
2
3 if (c == 0) {
4 if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
5 setExclusiveOwnerThread(current);
6 return true;
7 }
8 }
9 else if (current == getExclusiveOwnerThread()) {
10 int nextc = c + acquires;
11 if (nextc < 0)
12 throw new Error("Maximum lock count exceeded");
13 setState(nextc);
14 return true;
15 }
非公平锁：
1 // java.util.concurrent.locks.ReentrantLock.Sync#nonfairTryAcquire
2
3 if (c == 0) {
4 if (compareAndSetState(0, acquires)){
5 setExclusiveOwnerThread(current);
6 return true;
7 }
8 }
9 else if (current == getExclusiveOwnerThread()) {
10 int nextc = c + acquires;
11 if (nextc < 0) // overflow
12 throw new Error("Maximum lock count exceeded");
13 setState(nextc);
14 return true;
15 }
从上面这两段都可以看到，有一个同步状态State来控制整体可重入的情况。State是Volatile修饰的，用于保证一定的可见性和有序性。
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2 private volatile int state;
接下来看State这个字段主要的过程：
State初始化的时候为0，表示没有任何线程持有锁。
当有线程持有该锁时，值就会在原来的基础上+1，同一个线程多次获得锁是，就会多次+1，这里就是可重入的概念。
解锁也是对这个字段-1，一直到0，此线程对锁释放。
**JUC中的应用场景：**除了上边ReentrantLock的可重入性的应用，AQS作为并发编程的框架，为很多其他同步工具提供了良好的解决方案。下面列出了JUC中的几种同步工具，大体介绍一下AQS的应用场景：
同步工具 同步工具与AQS的关联
ReentrantLock 使用AQS保存锁重复持有的次数。当一个线程获取锁时，ReentrantLock记录当前获得锁的线程标识，用于检测是否重复获取，以及错误线程试图解锁操作时异常情况的处理。
Semaphore 使用AQS同步状态来保存信号量的当前计数。tryRelease会增加计数，acquireShared会减少计数。
CountDownLatch 使用AQS同步状态来表示计数。计数为0时，所有的Acquire操作（CountDownLatch的await方法）才可以通过。
ReentrantReadWriteLock 使用AQS同步状态中的16位保存写锁持有的次数，剩下的16位用于保存读锁的持有次数。
ThreadPoolExecutor Worker利用AQS同步状态实现对独占线程变量的设置（tryAcquire和tryRelease）。
九、自定义同步工具
了解 AQS基本原理以后，按照上面所说的 AQS知识点，自己实现一个同步工具。
1 public class LeeLock {
2
3 private static class Sync extends AbstractQueuedSynchronizer {
4 @Override
5 protected boolean tryAcquire (int arg) {
6 return compareAndSetState(0, 1);
7 }
8
9 @Override
10 protected boolean tryRelease (int arg) {
11 setState(0);
12 return true;
13 }
14
15 @Override
16 protected boolean isHeldExclusively () {
17 return getState() == 1;
18 }
19 }
20
21 private Sync sync = new Sync();
22
23 public void lock () {
24 sync.acquire(1);
25 }
26
27 public void unlock () {
28 sync.release(1);
29 }
30 }
通过我们自己定义的Lock完成一定的同步功能。
1 public class LeeMain {
2
3 static int count = 0;
4 static LeeLock leeLock = new LeeLock();
5
6 public static void main (String[] args) throws InterruptedException {
7
8 Runnable runnable = new Runnable() {
9 @Override
10 public void run () {
11 try {
12 leeLock.lock();
13 for (int i = 0; i < 10000; i++) {
14 count++;
15 }
16 } catch (Exception e) {
17 e.printStackTrace();
18 } finally {
19 leeLock.unlock();
20 }
21
22 }
23 };
24 Thread thread1 = new Thread(runnable);
25 Thread thread2 = new Thread(runnable);
26 thread1.start();
27 thread2.start();
28 thread1.join();
29 thread2.join();
30 System.out.println(count);
31 }
32 }
上述代码每次运行结果都会是20000。通过简单的几行代码就能实现同步功能，这就是AQS的强大之处。
十、总结
我们日常开发中使用并发的场景太多，但是对并发内部的基本框架原理了解的人却不多。由于篇幅原因，本文仅介绍了可重入锁ReentrantLock的原理和AQS原理，希望能够成为大家了解AQS和ReentrantLock等同步器的“敲门砖”。
————————————————
版权声明：本文为CSDN博主「奋斗的小媛」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m0_37235955/article/details/116212423
951
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
