做并发编程的同学应该都听过大名鼎鼎的 ReadWriteLock 读写锁。它在“读多写少”的场景里几乎成了标准答案网上讲用法的文章一抓一大把但讲实现原理的往往只是围绕 AQS 状态位一句话带过。这篇文我把读写锁的源码拆开来看从 state 高 16 位低 16 位的划分到写锁读锁各自的获取释放流程再到锁降级这种高阶用法尽量把实现原理里那些“为什么这样设计”讲透。如果你是第一次接触读写锁不用担心看不懂我会带过必要的 AQS 基础如果你已经在项目里用过它可以直接跳到第 3 节和第 4 节看源码细节和高阶用法。这个内容能帮你搞定两类人一类是面试官问“ReadWriteLock 实现原理”的候选人另一类是团队里想把并发这块写明白的开发者。1. 读写锁到底解决了什么问题1.1 互斥锁的“一刀切”困境假设我们有一个缓存 Map多线程读偶尔写。用 synchronized 或者 ReentrantLock 保护它逻辑上是没问题的但性能上有点憋屈——明明两个线程都在读同一个 key谁也不改数据彼此之间完全不会干扰却还要排队等锁。这就是互斥锁的痛点它把所有访问都当成“可能改数据”来处理读操作之间互相阻塞白白浪费了并发能力。数据库很早就意识到这个问题所以有共享锁和排他锁的概念。Java 里的 ReadWriteLock 也是同样的思路把操作分成两类读操作之间可以并行写操作必须独占。1.2 读写分离的三条铁律读写锁的行为可以归纳成三条规则这三条规则是理解和验证所有后续代码的基础读锁与读锁共享多个线程可以同时持有读锁。读锁与写锁互斥一旦有线程持有了写锁所有读线程都不能进入反过来只要有读锁被持有写线程也不能进入。写锁与写锁互斥写锁是独占锁同一时间最多一个线程持有。本质上读写锁是在“数据一致性”和“并发度”之间做了一个权衡。它没有对读操作做任何隔离因为读不会破坏数据但它严格要求所有写操作串行化并且写操作不能被读操作“覆盖”。1.3 天生适合读写锁的典型场景读多写少、且数据量不大、不希望引入外部缓存组件的情况下ReadWriteLock 是很顺手的选择。几个我实际用过的场景配置中心客户端配置变更频率很低但每个请求可能都要读配置。本地缓存key 固定的一批热点数据定时或事件触发全量刷新。权限元数据内存表启动时加载运行期极少更新但查询路径上被高频访问。连接池状态统计维护每个连接的状态读写比例悬殊。这类场景的共同点是写操作极少但每次写操作都必须在原子性上把关。读写锁正好能压低锁竞争的开销。反过来那些写操作频繁的业务场景比如日志批量写入、计数器累加读写锁的优势就体现不出来甚至因为状态计算复杂而比互斥锁更慢。这一点后面第 5 节还会展开聊。2. 一个 int 拆两半状态变量的精妙设计2.1 为什么一把锁需要两个状态很多人第一次看读写锁源码时会有个疑问ReentrantReadWriteLock 内部到底怎么区分当前是读模式还是写模式答案是它根本没有用两个独立的变量而是把 AQS 里的一个 int 类型的 state 字段拆成了两半。在 ReentrantReadWriteLock 的 Sync 内部类里有一段经典的常量定义static final int SHARED_SHIFT 16; static final int SHARED_UNIT (1 SHARED_SHIFT); static final int MAX_COUNT (1 SHARED_SHIFT) - 1; static final int EXCLUSIVE_MASK (1 SHARED_SHIFT) - 1; /** 低 16 位写锁的重入次数 */ static int exclusiveCount(int c) { return c EXCLUSIVE_MASK; } /** 高 16 位读锁的持有次数所有线程加总 */ static int sharedCount(int c) { return c SHARED_SHIFT; }int 是 32 位这里的高 16 位专门统计读锁持有数量低 16 位专门统计写锁重入次数。用一个 int 而非两个字段核心原因和 AQS 的 CAS 机制有关CAS 只能针对单个 int 变量做原子更新。如果读计数和写计数分开两个变量就无法在一次 CAS 里同时判断并更新“当前无锁”这个整体状态会出现读到一半状态的竞态窗口。把两者塞进同一个 int一次 CAS 就能保证读写状态的一致可见。2.2 状态值的语义速查理解了这个设计之后判断锁状态就变得很直接。state 0锁完全空闲。低 16 位 0有写线程持有了写锁或同一写线程重入多次对应的值就是写锁重入次数。高 16 位 0有 N 个线程持有读锁对应的值就是所有读锁持有次数的总和。注意读锁的计数是所有线程持有读锁次数的累加每个线程自己重入了几次由另一个叫 HoldCounter 的数据结构单独记录。写锁的计数则只属于当前持锁线程因为它本来就是独占的。这两个“计数维度”的不同后面看读锁代码时会反复遇到。2.3 公平与非公平模式下的线程排队ReentrantReadWriteLock 的构造器允许传入公平标志默认非公平。公平与非公平主要体现在 Sync 的子类里如何实现 writerShouldBlock() 和 readerShouldBlock() 这两个方法。公平模式下两个方法都会调用 hasQueuedPredecessors()只要等待队列里有比自己更早的线程就不去抢锁老老实实排队。非公平的写锁writerShouldBlock() 直接返回 false意思是写线程可以无视队列直接尝试 CAS 抢锁。非公平的读锁则比较微妙readerShouldBlock() 不是一昧放行它会检查等待队列的头部队列是否是写锁线程。假如队首有写线程在等锁读线程不会插队抢锁——这是 JDK 为缓解写线程饥饿做的一个很重要的设计后面第 5 节还会再提。3. 写锁和读锁的获取释放源码级拆解这一节我们直接进源码。ReentrantReadWriteLock 的 ReadLock 和 WriteLock 都是通过内部 Sync继承 AbstractQueuedSynchronizer来实现的写锁走独占模式读锁走共享模式。3.1 写锁获取tryAcquire 逐行拆解写锁的入口是WriteLock.lock()最终会调用Sync.tryAcquire(int acquires)protected final boolean tryAcquire(int acquires) { Thread current Thread.currentThread(); int c getState(); int w exclusiveCount(c); // 低 16 位写锁重入次数 if (c ! 0) { // 状态非空说明锁被占用 if (w 0 || current ! getExclusiveOwnerThread()) { return false; } if (w exclusiveCount(acquires) MAX_COUNT) { throw new Error(Maximum lock count exceeded); } setState(c acquires); // 写锁重入低 16 位 acquires return true; } if (writerShouldBlock() || !compareAndSetState(c, c acquires)) { return false; } setExclusiveOwnerThread(current); return true; }这里的逻辑分成两大块。第一块如果 c ! 0说明当前已经有锁被占用。此时有两种可能有读锁被占用写锁计数为 0或者有写锁被其他线程持有。无论哪种情况新来的写线程都不能通过直接返回 false。唯一能通行的例外是当前线程本来就持有写锁这种可重入场景直接把低 16 位加上 acquires 即可。第二块如果 c 0说明整个锁是空闲的。这时要先看 writerShouldBlock() 是否要求排队如果不要求排队就用 CAS 把 state 从 0 改成低 16 位为 1。抢锁成功后把 AQS 的 exclusiveOwnerThread 设置为当前线程。一个我在阅读时常被问到的细节写锁重入为什么是“c acquires”而不是“c 1 16”其实这里加在低 16 位上叠加到低 16 位本质上就是在给低 16 位加 acquires。而如果累加成 65536就会溢出到高 16 位这就是为什么前面要对 MAX_COUNT 做保护。3.2 写锁释放tryRelease写锁释放的入口是WriteLock.unlock()最终调用tryRelease(int releases)protected final boolean tryRelease(int releases) { if (!isHeldExclusively()) { throw new IllegalMonitorStateException(); } int nextc getState() - releases; boolean free exclusiveCount(nextc) 0; if (free) { setExclusiveOwnerThread(null); } setState(nextc); return free; }释放写锁前必须先校验“当前线程就是持锁线程”不然一个线程替另一个线程释放锁状态就乱套了。nextc 是 state 减去 releases 之后的值如果低 16 位已经归零说明写锁完全释放至少在写锁维度已经不再被占用这时候把 exclusiveOwnerThread 置为 null并返回 trueAQS 会借此唤醒等待队列里的下一个线程。写锁释放后state 可能仍然不为 0因为可能存在读锁计数。举个例子某线程持有写锁并进行了锁降级先获取读锁再释放写锁state 的低 16 位归零但高 16 位还保留着读锁计数。这种情况下锁没有被完全释放读线程可以继续共享。3.3 读锁获取tryAcquireShared读锁的入口是ReadLock.lock()它走的是共享模式调用tryAcquireShared(int unused)。这个方法比写锁复杂不少因为读锁要维护“所有线程加总的读锁计数”同时还要用 ThreadLocal 记录“当前线程自己的重入次数”。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)) { // 第一把读锁、重入、以及共享计数维护 if (r 0) { firstReader current; firstReaderHoldCount 1; } else if (firstReader current) { firstReaderHoldCount; } else { HoldCounter rh cachedHoldCounter; ... } return 1; } return fullTryAcquireShared(current); }第一步先判断写锁状态。如果写锁已经被占有并且占有着不是当前线程读线程直接失败返回 -1进入 AQS 的同步队列等待。这里允许“当前持有写锁的线程再去获取读锁”这正是锁降级能实现的前提。第二步尝试共享读锁。如果当前没有写锁竞争且有资格进入共享读模式就用 CAS 把 state 增加一个 SHARED_UNIT 常量也就是让高 16 位加 1。CAS 成功之后需要记录这台线程的读锁重入情况。源码里用了 firstReader 和 cachedHoldCounter 两个优化手段典型的做法是用 ThreadLocal 维护 HoldCounter记录每个线程自己的重入次数避免释放读锁时分不清是谁的锁。如果 CAS 失败或者 readerShouldBlock() 判定当前线程需要排队就会进入 fullTryAcquireShared 自旋循环反复尝试更新读锁计数。这个循环的设计是为了处理“读锁重入 CAS 竞争 队列调度”交织的复杂情况。一个需要特别留意的点读锁的 SHARED_UNIT 是 1 16所以每获取一把读锁state 高 16 位加 1最多支持 65535 把读锁同时持有。虽然实际场景不太可能打到这个上限但极端情况下代码 bug 导致读锁疯狂重入会触发 MAX_COUNT 保护抛 Error。3.4 读锁释放tryReleaseShared读锁释放同样比写锁复杂因为它是“大家共享”的锁每个线程都只能释放自己持有的那一份。释放期间要自己维护的计数减掉再去修改 state 的高 16 位protected final boolean tryReleaseShared(int unused) { Thread current Thread.currentThread(); if (firstReader current) { if (firstReaderHoldCount 1) { firstReader null; } else { firstReaderHoldCount--; } } else { HoldCounter rh cachedHoldCounter; if (rh null || rh.tid ! getThreadId(current)) { rh readHolds.get(); } int count rh.count; if (count 1) { readHolds.remove(); if (count 0) { throw unmatchedUnlockException(); } } --rh.count; } for (;;) { int c getState(); int nextc c - SHARED_UNIT; if (compareAndSetState(c, nextc)) { return nextc 0; } } }读锁释放时先扣减当前线程自己的重入计数如果扣到 0 就把 ThreadLocal 里的记录移除防止内存泄漏。然后再用 CAS 循环更新全局 state减去一个 SHARED_UNIT。只有当 state 变成 0读写锁都完全释放时才返回 true触发后继线程唤醒。这里有一个很容易踩的坑释放读锁时如果当前线程并没有持有读锁JDK 会抛出UnmatchedUnlockException在 JDK 8 里是IllegalMonitorStateException表现就是“锁被非法释放”。这和写锁释放前检查 isHeldExclusively 是同一个道理只是读锁检查的是 ThreadLocal 记录。4. 锁降级唯一的“向下兼容”通道4.1 锁降级到底解决什么问题锁降级是指线程先持有写锁在写锁尚未释放时获取读锁然后再释放写锁。最终状态是线程还持有着读锁。为什么需要这个操作看一个典型的缓存刷新场景。线程 A 持有了写锁准备更新缓存。更新完数据之后如果不直接降级而是先释放写锁再加读锁中间会有一个瞬间写锁已经释放但读锁还没拿到。在这个窗口期其他写线程可以抢到写锁把刚更新的数据又改掉导致线程 A 后面读到的数据和它刚刚写入的数据不一致。锁降级就是在这个窗口期前先拿一把读锁再放写锁保证当前线程从写锁切换到读锁的过程是连续的中间不会有其他写操作插入。4.2 标准写法演示Java 官方文档里给过一个典型的 Cache 示例我平时也基本照这个模板写class CachedData { Object data; volatile boolean cacheValid; final ReentrantReadWriteLock rwl new ReentrantReadWriteLock(); void processCachedData() { rwl.readLock().lock(); if (!cacheValid) { // 必须先释放读锁才能获取写锁 rwl.readLock().unlock(); rwl.writeLock().lock(); try { // 双检锁防止其他线程已经写完 if (!cacheValid) { data loadData(); cacheValid true; } // 锁降级在持有写锁时获取读锁 rwl.readLock().lock(); } finally { // 释放写锁但还持有读锁 rwl.writeLock().unlock(); } } try { use(data); } finally { rwl.readLock().unlock(); } } }这个流程里最关键的一步是rwl.readLock().lock()放在rwl.writeLock().unlock()之前。先加读锁再放写锁才能保证当前线程始终握有一把锁数据不会在中间暴露给其他写线程。实际使用中你会发现这段代码还挺绕的外层先拿读锁判断缓存无效后再换成写锁写完又降级回读锁。这也是锁降级最容易被面试官追问的地方——他可能先问你“你写过锁降级吗”再让你现场写这个流程。4.3 为什么不能反过来“锁升级”锁升级是指线程先持有读锁再尝试获取写锁。这在 ReentrantReadWriteLock 里是直接禁止的一旦执行线程就会阻塞严重的会形成死锁。原因其实很直白。假设线程 A 和线程 B 都持有读锁A 想升级成写锁它必须等待所有读锁释放。但 B 还握着读锁B 的代码可能也在等待某一个资源。A 不能释放自己的读锁去等写锁吗如果 A 释放了读锁去排队等写锁它仍然要等 B 释放读锁才算完而 B 如果也走到升级写锁的逻辑两个人互相等待死锁就出现了。就算只有一个读线程尝试升级在 JDK 的实现里也不会成功因为 tryAcquire 判断有读锁存在时就会返回 false让读线程进入等待队列。这个等待永远等不醒因为自己还握着一把读锁。所以只要在代码里出现“先 readLock().lock() 后 writeLock().lock()”的顺序基本就是给自己挖坑。规范的做法永远是读完先释放读锁再去抢写锁写完如果需要再降级回读锁。5. 排坑实录我用读写锁踩过的 5 个坑5.1 锁饥饿读线程太多写线程等不到锁非公平模式下读写锁有一个天然问题如果读线程源源不断进来写线程可能长期拿不到锁。虽然 JDK 在 readerShouldBlock() 里做了部分保护会在等待队列头部有写线程时阻止新的读锁插队但如果读锁请求本身密集且持续写线程仍然可能等待较长时间。我在一个配置刷新场景里就踩过类似的坑。某个接口读配置的并发量很大每次配置更新时需要拿到写锁。上线后有一段时间配置更新延迟特别明显排查看线程 dump 才发现有个写线程在等待队列里蹲了快 3 秒。后来把锁换成公平模式写线程的等待时间就稳定下来了。公平模式会牺牲一部分读并发性因为所有线程都必须按队列顺序获取锁。如果业务要求写操作不能被读流量“饿死”公平模式是更稳妥的选择如果写操作极少且优先级不高非公平模式的吞吐量会更好。5.2 重入次数的上限65535 这个幽灵由于 int 高 16 位和低 16 位最多各表示 65535读写锁的重入次数和读锁总持有次数都有限制。在一个写循环里反复重入写锁或者通过递归调用叠加读锁达到上限后会抛Error。虽然正常业务很难触发但递归代码是一个高危场景尤其是递归加锁还伴随回调很容易在极端路径上把重入次数堆爆。避免办法是加锁时尽量“平铺”不要在递归里不加节制地 lock。如果确实需要递归读可以考虑在递归入口判断是否已经持有锁避免每一层都加一把。5.3 读多写少不是唯一标准锁粒度更重要读写锁并不是“读多写少就一定比互斥锁快”。我后来做过一组对比测试同一个数据结构读线程 80%、写线程 20%用 ReentrantReadWriteLock 并不比 ReentrantLock 有显著优势甚至因为内部维护 HoldCounter 的成本在低并发下还略慢。真正拉开差距的是读写比在 9:1 以上、且持锁时间较长的场景。锁粒度也很关键。不要图省事用一个读写锁保护一个大容器把不相关的读写操作也串行化。读锁是共享的这把锁保护的数据范围越大读线程之间“伪共享”的概率就越高。遇到高并发读、低并发写的场景先想想能不能用 ConcurrentHashMap、CopyOnWriteArrayList 这类并发容器替代真到需要自定义复合操作时再用读写锁。5.4 死锁排查从 dump 里看出端倪读写锁的死锁比普通互斥锁难排查一些因为它有共享语义。我常用的手段是jstack pid抓线程 dump搜索java.util.concurrent.locks.ReentrantReadWriteLock相关的堆栈重点看线程状态是不是WAITING (parking)以及 lock 对象上的 owner 信息。对于锁升级导致的死锁dump 通常会显示线程 A 持有读锁正等待写锁线程 B 也持有读锁正等待写锁。两个线程都不会释放读锁写锁永远无法获取。看到这种画面基本可以确定代码里写死了“读锁内再抢写锁”的逻辑。5.5 和其他锁的选型对比很多人在选型时还会把 StampedLock 拉进来对比这里给出我常用的判断表特性ReentrantReadWriteLockStampedLockReentrantLock读读共享支持支持乐观读无竞争时更快不支持写写互斥支持支持支持可重入支持不支持支持锁降级支持支持返回 stamp 后可转换不适用API 复杂度低高容易用错低适用场景读多写少、需要重入读写比极高、可接受复杂代码通用互斥StampedLock 的乐观读模式在无竞争时吞吐量确实高但它的不可重入和 API 误用风险也很明显。我在生产代码里默认不加考虑除非经过压测确认性能瓶颈确实在锁上且代码团队对这个锁足够熟悉。6. 尾声一些经验性总结最后分享一点个人体会。我在一个内部配置中心组件里用过读写锁最开始的实现很 naive——每次读配置都先拿读锁每次全量刷新先拿写锁。后来压测发现在高并发读场景下读锁本身的开销也不小反复加锁、释放锁反而影响了吞吐。后来我把配置内容改成不可变对象用 volatile 引用发布读路径完全无锁只有在全量刷新时才加写锁。这个改造之后读性能提升了一个量级。这个例子想说明的是读写锁不是银弹它只是比“一刀切互斥”更精细一些的工具。真正优雅的并发设计是尽可能把共享可变数据变成不可变数据让读路径根本不需要锁当不得不用锁时再去选择合适的锁类型和锁粒度。ReadWriteLock 的核心价值在于它把“读多写少”这一常见场景的并发潜力释放了出来而理解它的实现原理能帮你更准确地判断它什么时候适用什么时候该换一种方案。