本文深入分析了 Java 中的 ReentrantReadWriteLock 读写锁。基于 AQS 实现，利用 state 的高 16 位记录读锁数量，低 16 位记录写锁重入次数。支持读读共享、读写互斥。重点讲解了写锁的加锁释放流程及源码逻辑，以及读锁的重入优化策略（如 firstReader 和 cachedHoldCounter），解决了 ThreadLocal 内存泄漏问题，并阐述了读锁在 AQS 队列中的传播机制。
synchronized 和 ReentrantLock 都是互斥锁。
如果一个操作是读多写少，且需要保证线程安全，使用上述两种互斥锁效率会很低。
在这种情况下，可以使用 ReentrantReadWriteLock 读写锁去实现。
读读之间是不互斥的，可以并发执行。
但是如果涉及到了写操作，那么必须是互斥的操作。
static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
static ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
static ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
readLock.lock();
try {
System.out.println("子线程！");
try {
Thread.sleep(500000);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
readLock.unlock();
}
}).start();
Thread.sleep(1000);
writeLock.lock();
try {
System.out.println("主线程！");
} finally {
writeLock.unlock();
}
}
ReentrantReadWriteLock 还是基于 AQS 实现的，对 state 进行操作，拿到锁资源就去干活，如果没有拿到，依然去 AQS 队列中排队。
写锁重入：读写锁中的写锁的重入方式基本和 ReentrantLock 一致，没有什么区别，依然是对 state 进行 +1 操作即可，只要确认持有锁资源的线程是当前写锁线程即可。只不过之前 ReentrantLock 的重入次数是 state 的正数取值范围，但是读写锁中写锁范围就变小了。
读锁重入：因为读锁是共享锁。读锁在获取锁资源操作时，是要对 state 的高 16 位进行 +1 操作。因为读锁是共享锁，所以同一时间会有多个读线程持有读锁资源。这样一来，多个读操作在持有读锁时，无法确认每个线程读锁重入的次数。为了去记录读锁重入的次数，每个读操作的线程，都会有一个 ThreadLocal 记录锁重入的次数。
写锁的饥饿问题：读锁是共享锁，当有线程持有读锁资源时，再来一个线程想要获取读锁，直接对 state 修改即可。在读锁资源先被占用后，来了一个写锁资源，此时，大量的需要获取读锁的线程来请求锁资源，如果可以绕过写锁，直接拿资源，会造成写锁长时间无法获取到写锁资源。
读锁在拿到锁资源后，如果再有读线程需要获取读锁资源，需要去 AQS 队列排队。如果队列的前面需要写锁资源的线程，那么后续读线程是无法拿到锁资源的。持有读锁的线程，只会让写锁线程之前的读线程拿到锁资源。
（此处省略流程图）
写锁加锁流程
// 写锁加锁的入口
public void lock() {
sync.acquire(1);
}
public final void acquire(int arg) {
if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
// 读写锁的写锁实现
protected final boolean tryAcquire(int acquires) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到 state 的值
int c = getState();
// 得到 state 低 16 位的值
int w = exclusiveCount(c);
// 判断是否有线程持有着锁资源
if (c != 0) {
// 当前没有线程持有写锁，读写互斥，告辞。
// 有线程持有写锁，持有写锁的线程不是当前线程，不是锁重入，告辞。
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 当前线程持有写锁。锁重入。
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// 没有超过锁重入的次数，正常 +1
setState(c + acquires);
return true;
}
(writerShouldBlock() || !compareAndSetState(c, c + acquires))
;
setExclusiveOwnerThread(current);
;
}
释放的流程和 ReentrantLock 一致，只是在判断释放是否干净时，判断低 16 位的值。
// 写锁释放锁的 tryRelease 方法
protected final boolean tryRelease(int releases) {
// 判断当前持有写锁的线程是否是当前线程
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 获取 state - 1
int nextc = getState() - releases;
// 判断低 16 位结果是否为 0，如果为 0，free 设置为 true
boolean free = exclusiveCount(nextc) == 0;
if (free)
// 将持有锁的线程设置为 null
setExclusiveOwnerThread(null);
// 设置给 state
setState(nextc);
// 释放干净，返回 true。写锁有冲入，这里需要返回 false，不去释放排队的 Node
return free;
}
针对上述简单逻辑的源码分析
// 读锁加锁的方法入口
public final void acquireShared(int arg) {
// 竞争锁资源滴干活
if (tryAcquireShared(arg) < 0)
// 没拿到锁资源，去排队
doAcquireShared(arg);
}
// 读锁竞争锁资源的操作
protected final int tryAcquireShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到 state
int c = getState();
// 拿到 state 的低 16 位，判断 != 0，有写锁占用着锁资源
// 并且，当前占用锁资源的线程不是当前线程
if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
// 写锁被其他线程占用，无法获取读锁，直接返回 -1，去排队
return -1;
// 没有线程持有写锁、当前线程持有写锁
// 获取读锁的信息，state 的高 16 位。
int r = sharedCount(c);
// 公平锁：就查看队列是由有排队的，有排队的，直接告辞，进不去 if，后面也不用判断（没人排队继续走）
// 非公平锁：没有排队的，直接抢。有排队的，但是读锁其实不需要排队，如果出现这个情况，大部分是写锁资源刚刚释放，
// 后续 Node 还没有来记得拿到读锁资源，当前竞争的读线程，可以直接获取
if (!readerShouldBlock() &&
// 判断持有读锁的临界值是否达到 r < MAX_COUNT
r < MAX_COUNT &&
// CAS 修改 state，对高 16 位进行 +1
compareAndSetState(c, c + SHARED_UNIT)) {
// 省略部分代码！！！！
return ;
}
fullTryAcquireShared(current);
}
{
Node h, s;
(h = head) != &&
(s = h.next) != &&
!s.isShared() &&
s.thread != ;
}
\=============重入操作
前面阐述过，读锁为了记录锁重入的次数，需要让每个读线程用 ThreadLocal 存储重入次数
ReentrantReadWriteLock 对读锁重入做了一些优化操作
\============记录重入次数的核心
ReentrantReadWriteLock 在内部对 ThreadLocal 做了封装，基于 HoldCount 的对象存储重入次数，在内部有个 count 属性记录，而且每个线程都是自己的 ThreadLocalHoldCounter，所以可以直接对内部的 count 进行++操作。
\=============第一个获取读锁资源的重入次数记录方式
第一个拿到读锁资源的线程，不需要通过 ThreadLocal 存储，内部提供了两个属性来记录第一个拿到读锁资源线程的信息
内部提供了 firstReader 记录第一个拿到读锁资源的线程，firstReaderHoldCount 记录 firstReader 的锁重入次数
\==============最后一个获取读锁资源的重入次数记录方式
最后一个拿到读锁资源的线程，也会缓存他的重入次数，这样++起来更方便
基于 cachedHoldCounter 缓存最后一个拿到锁资源现行的重入次数
\==============最后一个获取读锁资源的重入次数记录方式
重入次数的流程执行方式：
1、判断当前线程是否是第一个拿到读锁资源的：如果是，直接将 firstReader 以及 firstReaderHoldCount 设置为当前线程的信息
2、判断当前线程是否是 firstReader：如果是，直接对 firstReaderHoldCount++ 即可。
3、跟 firstReader 没关系了，先获取 cachedHoldCounter，判断是否是当前线程。
3.1、如果不是，获取当前线程的重入次数，将 cachedHoldCounter 设置为当前线程。
3.2、如果是，判断当前重入次数是否为 0，重新设置当前线程的锁从入信息到 readHolds（ThreadLocal）中，算是初始化操作，重入次数是 0
3.3、前面两者最后都做 count++
上述逻辑源码分析
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread();
int c = getState();
if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
return -1;
int r = sharedCount(c);
if (!readerShouldBlock() && r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)) {
// ===============================================================
// 判断 r == 0，当前是第一个拿到读锁资源的线程
if (r == 0) {
// 将 firstReader 设置为当前线程
firstReader = current;
// 将 count 设置为 1
firstReaderHoldCount = 1;
}
// 判断当前线程是否是第一个获取读锁资源的线程
else if (firstReader == current) {
// 直接++。
firstReaderHoldCount++;
}
// 到这，就说明不是第一个获取读锁资源的线程
else {
// 那获取最后一个拿到读锁资源的线程
HoldCounter rh = cachedHoldCounter;
// 判断当前线程是否是最后一个拿到读锁资源的线程
if (rh == null || rh.tid != getThreadId(current))
// 如果不是，设置当前线程为 cachedHoldCounter
cachedHoldCounter = rh = readHolds.get();
// 当前线程是之前的 cacheHoldCounter
else (rh.count == )
readHolds.set(rh);
rh.count++;
}
;
}
fullTryAcquireShared(current);
}
// tryAcquireShard 方法中，如果没有拿到锁资源，走这个方法，尝试再次获取，逻辑跟上面基本一致。
final int fullTryAcquireShared(Thread current) {
// 声明当前线程的锁重入次数
HoldCounter rh = null;
// 死循环
for (;;) {
// 再次拿到 state
int c = getState();
// 当前如果有写锁在占用锁资源，并且不是当前线程，返回 -1，走排队策略
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
}
// 查看当前是否可以尝试竞争锁资源（公平锁和非公平锁的逻辑）
else if (readerShouldBlock()) {
// 无论公平还是非公平，只要进来，就代表要放到 AQS 队列中了，先做一波准备
// 在处理 ThreadLocal 的内存泄漏问题
if (firstReader == current) {
// 如果当前当前线程是之前的 firstReader，什么都不用做
} else {
// 第一次进来是 null。
if (rh == null) {
// 拿到最后一个获取读锁的线程
rh = cachedHoldCounter;
// 当前线程并不是 cachedHoldCounter，没到拿到
if (rh == null || rh.tid != getThreadId(current)) {
// 从自己的 ThreadLocal 中拿到重入计数器
rh = readHolds.get();
// 如果计数器为 0，说明之前没拿到过读锁资源
if (rh.count == 0)
// remove，避免内存泄漏
readHolds.remove();
}
}
(rh.count == )
-;
}
}
(sharedCount(c) == MAX_COUNT)
();
(compareAndSetState(c, c + SHARED_UNIT)) {
(sharedCount(c) == ) {
firstReader = current;
firstReaderHoldCount = ;
} (firstReader == current) {
firstReaderHoldCount++;
} {
(rh == )
rh = cachedHoldCounter;
(rh == || rh.tid != getThreadId(current))
rh = readHolds.get();
(rh.count == )
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh;
}
;
}
}
}
1、正常如果都是读线程来获取读锁资源，不需要使用到 AQS 队列的，直接 CAS 操作即可
2、如果写线程持有着写锁，这是读线程就需要进入到 AQS 队列排队，可能会有多个读线程在 AQS 中。
当写锁释放资源后，会唤醒 head 后面的读线程，当 head 后面的读线程拿到锁资源后，还需要查看 next 节点是否也是读线程在阻塞，如果是，直接唤醒
源码分析
// 读锁需要排队的操作
private void doAcquireShared(int arg) {
// 声明 Node，类型是共享锁，并且扔到 AQS 中排队
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
// 拿到上一个节点
final Node p = node.predecessor();
// 如果 prev 节点是 head，直接可以执行 tryAcquireShared
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
// 拿到读锁资源后，需要做的后续处理
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 找到 prev 有效节点，将状态设置为 -1，挂起当前线程
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private {
head;
setHead(node);
(propagate > || h == || h.waitStatus < || (h = head) == || h.waitStatus < ) {
node.next;
(s == || s.isShared())
doReleaseShared();
}
}
1、处理重入以及 state 的值 2、唤醒后续排队的 Node
源码分析
// 读锁释放锁流程
public final boolean releaseShared(int arg) {
// tryReleaseShared：处理 state 的值，以及可重入的内容
if (tryReleaseShared(arg)) {
// AQS 队列的事！
doReleaseShared();
return true;
}
return false;
}
// 1、处理重入问题 2、处理 state
protected final boolean tryReleaseShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 如果是 firstReader，直接干活，不需要 ThreadLocal
if (firstReader == current) {
assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
}
// 不是 firstReader，从 cachedHoldCounter 以及 ThreadLocal 处理
else {
// 如果是 cachedHoldCounter，正常--
HoldCounter rh = cachedHoldCounter;
// 如果不是 cachedHoldCounter，从自己的 ThreadLocal 中拿
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
// 如果为 1 或者更小，当前线程就释放干净了，直接 remove，避免 value 内存泄漏
(count <= ) {
readHolds.remove();
(count <= )
unmatchedUnlockException();
}
rh.count--;
}
(;;) {
getState();
c - SHARED_UNIT;
(compareAndSetState(c, nextc))
nextc == ;
}
}
{
(;;) {
head;
(h != && h != tail) {
h.waitStatus;
(ws == Node.SIGNAL) {
(!compareAndSetWaitStatus(h, Node.SIGNAL, ))
;
unparkSuccessor(h);
}
(ws == && !compareAndSetWaitStatus(h, , Node.PROPAGATE))
;
}
(h == head)
;
}
}
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online