Java 并发编程：ReentrantLock 锁与 AQS

大家好，我是栗筝i，这篇文章是我的 “栗筝i 的 Java 技术栈” 专栏的第 030 篇文章，在 “栗筝i 的 Java 技术栈” 这个专栏中我会持续为大家更新 Java 技术相关全套技术栈内容。专栏的主要目标是已经有一定 Java 开发经验，并希望进一步完善自己对整个 Java 技术体系来充实自己的技术栈的同学。与此同时，本专栏的所有文章，也都会准备充足的代码示例和完善的知识点梳理，因此也十分适合零基础的小白和要准备工作面试的同学学习。当然，我也会在必要的时候进行相关技术深度的技术解读，相信即使是拥有多年 Java 开发经验的从业者和大佬们也会有所收获并找到乐趣。

–

在多线程编程中，锁机制是保证线程安全的核心技术之一。Java 提供了多种锁机制，其中 ReentrantLock 是一种灵活且功能丰富的可重入锁，具有公平锁、非公平锁等特性，能够替代传统的 synchronized 关键字来实现更复杂的并发控制。本文将深入探讨 ReentrantLock 的工作原理及其背后的关键组件——AbstractQueuedSynchronizer（AQS）。通过了解 AQS 的设计和实现，读者将掌握如何通过锁机制在高并发环境下确保数据的一致性和线程的安全性。

1、Lock 锁

1.1、为什么使用 Lock

synchronized 线程等待时间过长，获取锁的线程由于要等待 IO 或者其他原因（比如调用 sleep 方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，这将极大的影响程序执行效率。

synchronized 操作场景，如果多个线程都只是进行读操作，所以当一个线程在进行读操作时，其他线程只能等待无法进行读操作。

1.2、注意事项

也就是说 Lock 提供了比 synchronized 更多的功能。但是要注意以下几点

• Lock 不是 Java 语言内置的，synchronized 是 Java 语言的关键字，因此是内置特性。Lock 是一个类，通过这个类可以实现同步访问；
• Lock 和 synchronized 有一点非常大的不同，采用 synchronized 不需要用户去手动释放锁，当 synchronized 方法或者 synchronized 代码块执行完之后，系统会自动让线程释放对锁的占用；而 Lock 则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象。

1.3、ReentrantLock 和 synchronized

ReentrantLock 是 java.util.concurrent.locks 包中的一个类，是独占锁，为最后一个执行 lock 操作成功且为释放锁的线程锁拥有

ReentrantLock 是可重入的互斥锁，虽然具有与 synchronized 相同功能，但是会比 synchronized 更加灵活

ReentrantLock 使用代码实现了和 synchronized 一样的语义，包括可重入，保证内存可见性和解决竞态条件问题等。与 synchronized 相较之下：

• 便利性：Synchronized 用法更简洁，由编译器去保证锁的加锁和释放; ReenTrantLock 需要手动加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在 finally 中声明释放锁。
• 锁的细粒度和灵活度：ReenTrantLock 优于 Synchronized

此外，以下特点是 ReenTrantLock 独有：

• ReenTrantLock 可以指定是公平锁还是非公平锁; synchronized 只能是非公平锁。
• ReenTrantLock 提供了一个 Condition 类，用来实现唤醒特定的线程; synchronized 要么随机唤醒一个线程要么唤醒全部线程。
• ReenTrantLock 提供了一种能够中断等待锁的线程的机制。

2、ReentrantLock

ReentrantLock，它是一个 “可重入” 锁。

什么 是“可重入”？简单地讲就是：“同一个线程对于已经获得到的锁，可以多次继续申请到该锁的使用权”

正经地讲就是：假如访问一个资源 A 需要获得其锁 lock，如果之前没有其他线程获取该锁，那么当前线程就获锁成功，此时该线程对该锁后续所有“请求”都将立即得到“获锁成功”的返回，即同一个线程可以多次成功的获取到之前获得的锁。“可重入”可以解释成“同一个线程可多次获取”。

大致的特性

• 基本锁的特性：加锁、解锁

• ReentrantLock 的补充特性：可重入、公平、非公平

2.1、加锁、解锁

这两个方法在源码中加锁方法即为lock()，解锁方法即为unLock() ，实现如下：

//加锁
public void lock() {sync.lock();
}//释放锁
public void unlock() {sync.release(1);
}

从上述可以知道这两个方法实际上是操作了一个叫做 sync 的对象，调用该对象的 lock 和 release 操作来实现，sync 是什么东西？ReentrantLock 类的源码片段：

public class ReentrantLock implements Lock, java.io.Serializable {private static final long serialVersionUID = 7373984872572414699L;private final Sync sync;
}

ReentrantLock 实现了 Lock 接口，操作其成员变量 sync 这个 AQS 的子类,来完成锁的相关功能。而 sync 这个成员变量有 2 种形态：NonfairSync 和 FairSync，在源码中，只有在 2 个构造函数的地方对 sync 对象做了初始化。

/** 所有锁操作都是基于这个字段 */
private final Sync sync;
/*** 通过该构造函数创建额ReentrantLock是一个非公平锁*/
public ReentrantLock() {sync = new NonfairSync();
}
/*** 如果入参为true，则创建公平的ReentrantLock；* 否则，创建非公平锁*/
public ReentrantLock(boolean fair) {sync = fair ? new FairSync() : new NonfairSync();
}

这两个对象（NonfairSync 和 NonfairSync）也是 ReentrantLock 的内部类，FairSync 和 NonFairSync 在类结构上完全一样且均继承于 Sync。

ReentrantLock 的构造函数中，默认的无参构造函数将会把 Sync 对象创建为 NonfairSync 对象，这是一个“非公平锁”；而另一个构造函数 ReentrantLock(boolean fair) 传入参数为 true 时将会把 Sync 对象创建为“公平锁” FairSync

2.2、公平锁与非公平锁

FairSync 在 tryAquire 方法中，当判断到锁状态字段 state==0 时，不会立马将当前线程设置为该锁的占用线程，而是去判断是在此线程之前是否有其他线程在等待这个锁（执行 hasQueuedPredecessors() 方法），如果是的话，则该线程会加入到等待队列中，进行排队（FIFO，先进先出的排队形式）。这也就是为什么 FairSync 可以让线程之间公平获得该锁。

NoFairSync 的 tryAquire 方法中，没有判断是否有在此之前的排队线程，而是直接进行获锁操作，因此多个线程之间同时争用一把锁的时候，谁先获取到就变得随机了，很有可能线程 A 比线程 B 更早等待这把锁，但是 B 却获取到了锁，A 继续等待（这种现象叫做：线程饥饿）

到此，我们已经大致理解了 ReentrantLock 是如何做到不同线程如何“公平”和“非公平”获锁。

2.3、如何实现可重入

我们有提到加锁操作会对 state 字段进行 +1 操作

这里需要注意到 AQS 中很多内部变量的修饰符都是采用的 volital，然后配合 CAS 操作来保证 AQS 本身的线程安全（因为 AQS 自己线程安全,基于它的衍生类才能更好地保证线程安全）,这里的 state 字段就是 AQS 类中的一个用 volitale 修饰的 int 变量

state 字段初始化时,值为 0。表示目前没有任何线程持有该锁。当一个线程每次获得该锁时，值就会在原来的基础上加 1，多次获锁就会多次加 1（指同一个线程），这里就是可重入。因为可以同一个线程多次获锁，只是对这个字段的值在原来基础上加1; 相反 unlock 操作也就是解锁操作，实际是是调用 AQS 的 release 操作，而每执行一次这个操作，就会对 state 字段在原来的基础上减1，当 state==0 的 时候就表示当前线程已经完全释放了该锁。

3、抽象队列同步器 AQS

3.1、抽象队列同步器

AQS，即 AbstractQueuedSynchronizer，抽象队列同步器，它是是一个集同步状态管理、线程阻塞、线程释放及队列管理功能与一身的同步框架。其核心思想是当多个线程竞争资源时会将未成功竞争到资源的线程构造为 Node 节点放置到一个双向 FIFO 队列中。被放入到该队列中的线程会保持阻塞直至被前驱节点唤醒。值得注意的是该队列中只有队首节点有资格被唤醒竞争锁。

3.2、同步状态的处理

成员变量 state。用于表示锁现在的状态，用 volatile 修饰，保证内存一致性及其在多线程之间的可见性。同时所用对 state 的操作都是使用 CAS 进行的。state 为 0 表示没有任何线程持有这个锁，线程持有该锁后将 state 加 1，释放时减 1。多次持有释放则多次加减。

private volatile int state;

以 ReentrantLock 举例，请求锁时有三种可能：

1. 如果没有线程持有锁，则请求成功，当前线程直接获取到锁；
2. 如果当前线程已经持有锁，则使用 CAS 将 state 值加1，表示自己再次申请了锁，释放锁时减1。这就是可重入性的实现；
3. 如果由其他线程持有锁，那么将自己添加进等待队列

final void lock() {if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); //没有线程持有锁时，直接获取锁，对应情况1elseacquire(1);
}
public final void acquire(int arg) {if (!tryAcquire(arg) && //在此方法中会判断当前持有线程是否等于自己，对应情况2acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) //将自己加入队列中，对应情况3selfInterrupt();
}

此外，AQS 还为 state 提供了相关方法：getState、setState 以及保证原子性 compareAndSetState

3.3、FIFO队列的设计——AQS灵魂

对于整个 AQS 框架来说，队列的设计可以说重中之重。那么为什么 AQS 需要一个队列呢？

对于一个资源同步竞争框架来说，如何处理没有获取到锁的线程是非常重要的，比方说现在有 ABCD 四个线程同时竞争锁，其中线程 A 竞争成功了。那么剩下的线程 BCD 该咋办呢？

我们可以尝试试想下自己会如何解决：

1. 类似于 sync 的轻量级锁实现：CAS 使线程自旋等待，不断重新尝试获取锁。这样虽然可以满足需求，但是众多线程同时自旋等待实际上是对 CPU 资源的一种浪费，这么做不太合适。
2. 类似于 sync 的重量级锁实现：将线程挂起阻塞，等待锁释放时唤醒，再竞争获取。如果等待的线程比较多，同时被唤醒可能会发生“惊群”问题，也会产生大量的资源浪费。

上面两种方法的可行性其实都不太高，对于一个同步框架来说，当有多个线程尝试竞争资源时，我们并不希望所有的线程同时来竞争锁。而且更重要的是，能够有效的监控当前处于等待过程中的线程也十分必要。

这个时候借助 FIFO 队列（线程先入先出）管理线程，既可以有效的帮助开发者监控线程，同时也可以在一定程度上减少饥饿问题出现的概率。

3.3.1、Node 节点的设计

如果没竞争到锁，这时候就要进入等待队列。线程的 2 种等待模式：

• SHARED：表示线程以共享的模式等待锁（如 ReadLock）
• EXCLUSIVE：表示线程以互斥的模式等待锁（如 ReentrantLock），互斥就是一把锁只能由一个线程持有，不能同时存在多个线程使用同一个锁。

队列是默认有一个 head 节点的，并且不包含线程信息。

将线程添加进等待队列的情况下，addWaiter 会创建一个 Node，并添加到链表的末尾，Node 中持有当前线程的引用。同时还有一个成员变量 waitStatus，表示线程的等待状态，初始值为 0。线程在队列中的状态枚举：

• CANCELLED：值为 1，表示线程的获锁请求已经“取消”
• SIGNAL：值为 -1，表示该线程一切都准备好了,就等待锁空闲出来给我
• CONDITION：值为 -2，表示线程等待某一个条件（Condition）被满足
• PROPAGATE：值为 -3，当线程处在 SHARED 模式时，该字段才会被使用上

同时，加到链表末尾的操作使用了 CAS+死循环 的模式，很有代表性，拿出来看一看：

Node node = new Node(mode);
for (;;) {Node oldTail = tail;if (oldTail != null) {U.putObject(node, Node.PREV, oldTail);if (compareAndSetTail(oldTail, node)) {oldTail.next = node;return node;}} else {initializeSyncQueue();}
}

可以看到，在死循环里调用了 CAS 的方法。如果多个线程同时调用该方法，那么每次循环都只有一个线程执行成功，其他线程进入下一次循环，重新调用。N个线程就会循环N次。这样就在无锁的模式下实现了并发模型。

3.3.2、共享资源的竞争

如果此节点的上一个节点是头部节点，则再次尝试获取锁，获取到了就移除并返回。获取不到就进入下一步；

判断前一个节点的 waitStatus，

如果是 SINGAL，则返回 true，并调用 LockSupport.park() 将线程挂起；

如果是 CANCELLED，则将前一个节点移除；

如果是其他值，则将前一个节点的 waitStatus 标记为 SINGAL，进入下一次循环。

可以看到，一个线程最多有两次机会，还竞争不到就去挂起等待。

final boolean acquireQueued(final Node node, int arg) {try {boolean interrupted = false;for (;;) {final Node p = node.predecessor();if (p == head && tryAcquire(arg)) {setHead(node);p.next = null; // help GCreturn interrupted;}if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())interrupted = true;}} catch (Throwable t) {cancelAcquire(node);throw t;}
}

3.3.3、共享资源的释放

调用 tryRelease，此方法由子类实现。实现非常简单，如果当前线程是持有锁的线程，就将 state 减 1。减完后如果 state 大于 0，表示当前线程仍然持有锁，返回 false。如果等于 0，表示已经没有线程持有锁，返回 true，进入下一步；
如果头部节点的 waitStatus 不等于 0，则调用 LockSupport.unpark() 唤醒其下一个节点。头部节点的下一个节点就是等待队列中的第一个线程，这反映了 AQS 先进先出的特点。另外，即使是非公平锁，进入队列之后，还是得按顺序来。

public final boolean release(int arg) {if (tryRelease(arg)) { //将 state 减1Node h = head;if (h != null && h.waitStatus != 0)unparkSuccessor(h);return true;}return false;
}
private void unparkSuccessor(Node node) {int ws = node.waitStatus;if (ws < 0)node.compareAndSetWaitStatus(ws, 0);Node s = node.next;if (s == null || s.waitStatus > 0) {s = null;for (Node p = tail; p != node && p != null; p = p.prev)if (p.waitStatus <= 0)s = p;}if (s != null) //唤醒第一个等待的线程LockSupport.unpark(s.thread);
}