## 概述


在高并发系统的设计中，如何高效地处理共享资源的访问是一个永恒的挑战。当多个线程频繁读取数据而很少修改时，使用传统的互斥锁（如 `synchronized` 或 `ReentrantLock`）会导致不必要的性能瓶颈——因为读操作本身是线程安全的，完全可以并发执行。为解决这一问题，Java 并发包（JUC）提供了 **`ReentrantReadWriteLock`**（可重入读写锁），它通过 **读写分离** 的策略，允许多个读线程同时访问，而写线程则独占资源，从而在保证数据一致性的前提下，极大提升了系统的并发吞吐量。

本文将带你深入 `ReentrantReadWriteLock` 的源码腹地，从其核心设计哲学、内部状态管理、队列机制，到公平/非公平模式的实现差异，并结合 **JDK 25** 引入的 **作用域值**（Scoped Values） 和 **结构化并发**（Structured Concurrency） 等革命性特性，探讨传统同步工具在虚拟线程时代的全新演进方向。

>**文章被收录于专栏**：[云时代Java开发：原理、实战与优化](https://cloud.tencent.com/developer/column/107394)


----

## 第一章：设计哲学——为何需要读写锁？


### 1.1 传统互斥锁的局限


在典型的缓存、配置中心或数据库连接池等场景中，**读多写少** 是普遍规律。例如：


- **缓存系统**：99% 的请求是读取缓存，仅 1% 是更新缓存；

- **配置管理**：应用启动后，配置几乎不变，但会被频繁读取。


若使用 `ReentrantLock`，即使所有线程都在读，也必须串行执行，造成严重的 **“读者饥饿”** 问题。

### 1.2 读写锁的核心思想


`ReentrantReadWriteLock` 的设计基于一个简单而强大的原则：


- **读-读不互斥**：多个读线程可以同时持有读锁；

- **读-写互斥**：读锁和写锁不能共存；

- **写-写互斥**：写锁是独占的。


这种 **“共享-独占”** 模型完美契合了 AQS（`AbstractQueuedSynchronizer`）的 **共享模式**（Shared Mode）与 **独占模式**（Exclusive Mode）。


----

## 第二章：源码全景——内部结构与状态编码


### 2.1 类继承体系


`ReentrantReadWriteLock` 本身是一个 **外观类**（Facade），其核心逻辑由内部类 `Sync` 实现：

```
public class ReentrantReadWriteLock
        implements ReadWriteLock, java.io.Serializable {
    private final Sync sync; // 核心同步器
    // ...
}
```

- **`Sync`**：继承自 `AbstractQueuedSynchronizer`（AQS），是真正的同步逻辑载体；

- **`ReadLock` / `WriteLock`**：两个内部类，分别实现了 `Lock` 接口，对外提供读/写锁 API。


### 2.2 状态编码：32位整数的精妙复用


AQS 的同步状态是一个 `int` 值（32位）。`ReentrantReadWriteLock` 巧妙地将其拆分为两部分：


- **高16位**（`0xFFFF0000`）：存储 **读锁的持有次数**；

- **低16位**（`0x0000FFFF`）：存储 **写锁的持有次数**（0或1，因写锁不可重入多次？不，实际可重入，但最大65535次）。


#### 关键常量定义


```
static final int SHARED_SHIFT   = 16;
static final int SHARED_UNIT    = (1 << SHARED_SHIFT); // 65536
static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1; // 65535
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1; // 0xFFFF

// 获取读锁计数
static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
// 获取写锁计数
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
```
>💡 **为什么这样设计？**
利用位运算，可以在单个 `int` 上原子地更新读/写状态，避免了使用两个独立字段带来的竞态条件。


### 2.3 读锁的线程计数：HoldCounter 与 ThreadLocal


由于允许多个读线程同时持有读锁，`ReentrantReadWriteLock` 需要记录 **每个读线程的重入次数**。它通过以下结构实现：

```
static final class HoldCounter {
    int count; // 重入次数
    final long tid = getThreadId(Thread.currentThread()); // 线程ID（非Thread对象，避免内存泄漏）
}

static final class ThreadLocalHoldCounter
    extends ThreadLocal<HoldCounter> {
    public HoldCounter initialValue() {
        return new HoldCounter();
    }
}
```

- **`HoldCounter`**：轻量级计数器，绑定到线程ID；

- **`ThreadLocalHoldCounter`**：每个线程私有的计数器，通过 `ThreadLocal` 管理。


>⚠️ **注意**：使用 `long tid` 而非 `Thread` 对象，是为了防止 `ThreadLocal` 内存泄漏。


----

## 第三章：核心流程深度剖析


### 3.1 读锁获取：`ReadLock.lock()`


```
public void lock() {
    sync.acquireShared(1);
}
```
最终调用 AQS 的 `acquireShared`，其核心是 `tryAcquireShared`：

#### `tryAcquireShared` 流程


```
protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    
    // 1. 如果有写锁，且不是当前线程持有，则失败
    if (exclusiveCount(c) != 0 &&
        getExclusiveOwnerThread() != current)
        return -1;
    
    // 2. 获取读锁计数
    int r = sharedCount(c);
    
    // 3. 尝试快速获取（无竞争时）
    if (!readerShouldBlock() && // 公平模式下需检查队列
        r < MAX_COUNT && 
        compareAndSetState(c, c + SHARED_UNIT)) {
        if (r == 0) { // 第一个读线程
            firstReader = current;
            firstReaderHoldCount = 1;
        } else if (firstReader == current) { // 第一个读线程重入
            firstReaderHoldCount++;
        } else { // 其他读线程
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                cachedHoldCounter = rh = readHolds.get();
            rh.count++;
        }
        return 1;
    }
    
    // 4. 失败则进入完整获取流程
    return fullTryAcquireShared(current);
}
```

- **`readerShouldBlock()`**：公平模式下，若队列头是写线程，则读线程需阻塞（避免写线程饥饿）；

- **`firstReader` 优化**：对第一个读线程的特殊处理，避免 `ThreadLocal` 开销；

- **`cachedHoldCounter`**：缓存最后一个成功获取读锁的线程计数器，提升性能。


### 3.2 写锁获取：`WriteLock.lock()`


```
public void lock() {
    sync.acquire(1);
}
```
调用 AQS 的 `acquire`，核心是 `tryAcquire`：

#### `tryAcquire` 流程


```
protected final boolean tryAcquire(int acquires) {
    Thread current = Thread.currentThread();
    int c = getState();
    int w = exclusiveCount(c);
    
    if (c != 0) {
        // 1. 有读锁或写锁
        if (w == 0 || current != getExclusiveOwnerThread())
            return false; // 有读锁，或写锁被其他线程持有
        if (w + exclusiveCount(acquires) > MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
    }
    
    // 2. 尝试快速获取
    if (writerShouldBlock() || // 公平模式下需检查队列
        !compareAndSetState(c, c + acquires))
        return false;
    
    setExclusiveOwnerThread(current); // 记录持有者（来自AOS）
    return true;
}
```

- **`writerShouldBlock()`**：公平模式下，若队列非空，则写线程需阻塞。


### 3.3 锁降级：从写锁到读锁


`ReentrantReadWriteLock` 支持 **锁降级**（Lock Downgrading）：

```
writeLock.lock();
try {
    // 修改数据
    data = newData;
    
    // 降级：先获取读锁，再释放写锁
    readLock.lock();
} finally {
    writeLock.unlock();
}
// 此时仍持有读锁
```

- **目的**：确保在释放写锁到获取读锁之间，数据不被其他写线程修改；

- **限制**：**不支持锁升级**（先读锁后写锁），因为这可能导致死锁。


----

## 第四章：公平 vs 非公平模式


`ReentrantReadWriteLock` 构造函数允许指定公平性：

```
public ReentrantReadWriteLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}
```
### 4.1 非公平模式（默认）


- **读锁**：可插队。即使队列中有等待的写线程，新来的读线程也可能直接获取锁；

- **写锁**：可插队。若当前无锁，新写线程可直接获取，无需排队。


>**优势**：高吞吐；**劣势**：可能导致写线程饥饿。


### 4.2 公平模式


- **读锁**：若队列头是写线程，则读线程必须阻塞（`readerShouldBlock` 返回 `true`）；

- **写锁**：若队列非空，则写线程必须入队等待（`writerShouldBlock` 返回 `true`）。


>**优势**：避免饥饿，保证 FIFO；**劣势**：吞吐量略低。


----

## 第五章：JDK 25 时代的挑战与演进


JDK 25 作为最新的长期支持（LTS）版本，引入了 **作用域值**（Scoped Values, JEP 506） 和 **结构化并发**（Structured Concurrency, JEP 505） 两大革命性特性。这些特性深刻改变了并发编程的范式，对 `ReentrantReadWriteLock` 这样的传统同步工具提出了新的挑战与机遇。

### 5.1 作用域值（Scoped Values）对 ThreadLocal 的替代


`ReentrantReadWriteLock` 内部依赖 `ThreadLocal` 来存储每个读线程的 `HoldCounter`。然而，在 **虚拟线程**（Virtual Threads） 和 **结构化并发** 的时代，`ThreadLocal` 的弊端被无限放大：


- **内存泄漏**：线程池中的平台线程被复用，`ThreadLocal` 值可能跨任务污染；

- **性能开销**：海量虚拟线程导致 `ThreadLocalMap` 规模爆炸。


**JDK 25 的解决方案**：`ScopedValue`

```
// JDK 25 中，ReentrantReadWriteLock 的内部实现可能会演进为：
private static final ScopedValue<HoldCounter> READ_HOLD_COUNTER = ScopedValue.newInstance();

// 在获取读锁时
ScopedValue.where(READ_HOLD_COUNTER, new HoldCounter()).run(() -> {
    // 执行临界区代码
    // HoldCounter 在作用域结束后自动清理，无内存泄漏风险
});
```

- **优势**：作用域绑定、自动清理、与虚拟线程完美契合；

- **影响**：未来的 `ReentrantReadWriteLock` 实现可能会重构其内部计数器管理，以利用 `ScopedValue`。


### 5.2 结构化并发（Structured Concurrency）下的锁管理


结构化并发通过 `StructuredTaskScope` 强制子任务与父作用域共生死，这要求资源管理（包括锁）必须是 **确定性的** 和 **可组合的**。

**传统模式的问题**：

```
// 传统方式，容易忘记 unlock
readLock.lock();
try {
    // ... 
} finally {
    readLock.unlock(); // 必须手动释放
}
```
**JDK 25 的演进方向**：提供 **作用域感知的锁API**。

```
// 未来可能的API（概念性）
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var result = scope.fork(() -> {
        // 使用新的、与结构化并发集成的锁API
        return withReadLock(readLock, () -> {
            return computeResult();
        });
    }).get();
}
// 锁在作用域结束时自动释放，永不泄漏
```

- **目标**：将锁的生命周期与结构化并发的作用域绑定，从根本上杜绝资源泄漏。


### 5.3 可观测性增强


JDK 25 强调 **可观测性**（Observability）。未来的 `ReentrantReadWriteLock` 可能会：


- **集成 JFR**（Java Flight Recorder）：自动记录锁竞争、持有时间等事件；

- **暴露 Metrics**：通过 `java.lang.management` 提供 MBean，便于监控。


----

## 结语：读写分离的永恒智慧


`ReentrantReadWriteLock` 以其精妙的状态编码、高效的队列管理、灵活的公平策略，成为 Java 并发工具箱中不可或缺的利器。它不仅是 Doug Lea “**Simple, Correct, Fast**” 工程哲学的又一杰作，更是无数高并发系统背后的无名英雄。

在 **JDK 25** 引领的 **云原生**、**虚拟线程** 与 **结构化并发** 交织的新时代，`ReentrantReadWriteLock` 的核心思想——**在保证一致性的前提下最大化并发**——依然闪耀着不朽的光芒。而它的实现细节，正随着 `ScopedValue` 和 `StructuredTaskScope` 等新范式的普及，不断演进，以适应更复杂、更智能、更安全的并发未来。

>**你如何看待传统同步工具在结构化并发时代的角色？它们会被完全取代，还是作为底层基石继续存在？欢迎在评论区分享你的洞见！如果觉得本文助你深入理解 `ReentrantReadWriteLock`，记得点赞、收藏，并转发给团队伙伴——一起构建更强大的并发系统！**

在高并发系统的设计中，如何高效地处理共享资源的访问是一个永恒的挑战。当多个线程频繁读取数据而很少修改时，使用传统的互斥锁（如 synchronized 或 ReentrantLock）会导致不必要的性能瓶颈——因为读操作本身是线程安全的，完全可以并发执行。为解决这一问题，Java 并发包（JUC）提供了 ReentrantReadWriteLock（可重入读写锁），它通过 读写分离 的策略，允许多个读线程同时访问，而写线程则独占资源，从而在保证数据一致性的前提下，极大提升了系统的并发吞吐量。

Java源码详解：深入Java并发之ReentrantReadWriteLock全景式解析——读写分离的精妙艺术与云原生时代的演进（JDK 25版）

在高并发系统的设计中，如何高效地处理共享资源的访问是一个永恒的挑战。当多个线程频繁读取数据而很少修改时，使用传统的互斥锁（如 synchronized 或 ReentrantLock）会导致不必要的性能瓶颈——因为读操作本身是线程安全的，完全可以并发执行。为解决这一问题，Java 并发包（JUC）提供了 ReentrantReadWriteLock（可重入读写锁），它通过 读写分离 的策略，允许多

编程语言

架构设计

后端

Java ReentrantReadWriteLock 通过读写分离策略解决高并发场景下读多写少的性能瓶颈，允许多线程并发读取而写操作独占。本文深度解析其状态编码、公平/非公平模式实现，并探讨JDK25中ScopedValues与结构化并发对传统锁机制的革新影响，助力开发者优化高并发系统设计。

数据库连接池

数据一致性

数据库

云原生

Java

2026采购季 | AI焕新·智启新局

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Java源码详解：深入Java并发之ReentrantReadWriteLock全景式解析——读写分离的精妙艺术与云原生时代的演进（JDK 25版）-腾讯云开发者社区-腾讯云

Java源码详解：深入Java并发之ReentrantReadWriteLock全景式解析——读写分离的精妙艺术与云原生时代的演进（JDK 25版）

Java源码详解：深入Java并发之ReentrantReadWriteLock全景式解析——读写分离的精妙艺术与云原生时代的演进（JDK 25版）

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐