ReentrantReadWriteLock基于AQS用一个int型state变量实现读写锁：高16位存读锁计数，低16位存写锁重入次数，通过位运算（如s>>>16取读态、s&0xFFFF取写态）和CAS原子更新，确保读写互斥与并发安全。

Java 中的 ReentrantReadWriteLock 基于 AQS 实现读写锁，其核心在于用一个 int 类型的 state 变量同时管理读锁与写锁的状态，通过高低位拆分（高 16 位表示读锁计数，低 16 位表示写锁重入次数）实现紧凑、无锁（CAS）的并发控制。

state 的高低位拆分逻辑

AQS 的 state 是 int（32 位），ReentrantReadWriteLock 将其划分为：

• 低 16 位（0~65535）：写锁状态 —— 表示当前写锁的重入次数。0 表示未加写锁；非 0 表示持有写锁且重入了对应次数。
• 高 16 位（0~65535）：读锁状态 —— 表示当前持有读锁的线程数（注意：不是所有读线程各自计数，而是累计的“读锁获取次数”，但实际通过 ThreadLocal 维护每个线程的独立重入数；高 16 位仅用于快速判断是否有读线程在持锁）。

这种拆分利用位运算高效隔离两类状态，避免额外字段或对象开销。例如：

• 写锁计数 = state & 0xFFFF（取低 16 位）
• 读锁计数 = state >>> 16（无符号右移 16 位，取高 16 位）
• 更新写锁：CAS 修改低 16 位，高位不变（如 state + 1）
• 更新读锁：CAS 修改高 16 位，需先左移再加（如 (readCount ）

读锁获取时的 CAS 策略

读锁允许多线程并发获取，但必须满足：无写锁占用（writeCount == 0）且不破坏写优先原则（即当前没有等待中的写线程）。获取过程关键点：

• 先读取当前 state，分离出读、写计数
• 检查是否可读：写锁为 0，且 AQS 队列中下一个等待节点不是独占（写）节点（防止写饥饿）
• 计算新 state：读计数 + 1 → 左移 16 位，加上原写计数
• 用 CAS 原子更新整个 state；失败则重试（自旋）
• 成功后，还会用 ThreadLocal 记录当前线程的读锁重入次数（因高 16 位是全局总和，无法区分线程）

写锁获取与读写互斥保障

写锁是独占的，获取前必须确保：state 全为 0（无读无写），或当前持有写锁的是本线程（支持重入）。具体逻辑：

javascript-typescript-typescript-scaffold

你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型

下载

• 读取 state，分离读/写计数
• 若写计数 > 0 且持有者不是当前线程 → 拒绝获取
• 若读计数 > 0 → 拒绝获取（有读线程在运行，不能插队写）
• 否则尝试 CAS：将低 16 位 + 1（state + 1），高位不变
• 成功则标记 ownerThread = 当前线程；失败则入队等待

该设计天然保证：写锁存在时读锁无法获取（因读锁检查 writeCount == 0），读锁存在时写锁无法获取（因写锁检查 readCount == 0），从而实现严格互斥。

为什么不用两个 volatile 变量？

看似用两个 int 更直观，但 AQS 要求状态变更必须是原子的（尤其读写锁升级/降级场景）。若读写状态分离：

• CAS 更新其中一个变量时，另一个可能被并发修改，导致状态不一致（如读锁+1 和写锁-1 无法原子完成）
• 无法用单次 CAS 实现「只有当无读无写时才允许写入」这类复合条件判断
• 增加内存占用与缓存行竞争（两个变量可能落在不同 cache line）

而单 state + 位拆分，配合一次 CAS 即可完成任意组合判断与更新，兼顾性能、原子性与空间效率。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南