AQS位运算实现读写锁技巧解析

本文深入解析了如何巧妙利用AQS中32位state字段的位运算能力，通过将低16位用于记录写锁重入次数、高16位用于统计读锁持有线程数，实现轻量级、高性能的自定义读写锁——这种方案虽可行且高度灵活，却对设计严谨性提出严苛要求：必须严格依赖CAS原子操作（禁用setState）、精准定义位掩码语义，并妥善处理线程局部状态与竞争边界，堪称JVM并发编程中“在钢丝上跳舞”的经典实践。

直接用 AQS 的 state 做位运算实现读写分离，是可行的，但需谨慎设计——因为 AQS 本身不内置读写逻辑，必须由子类自行拆分 state 的 bit 位语义，并保证所有操作线程安全、无竞争歧义。核心思路是：将 32 位 int 的低 16 位用于记录“写锁持有次数”，高 16 位用于记录“读锁持有线程数”（或读重入总次数），通过位掩码和 CAS 实现原子读写状态变更。

state 位布局与语义定义

推荐采用经典拆分方式（兼容 JDK 中 ReentrantReadWriteLock 的设计思想）：

• 低 16 位（0–15）：表示写锁状态 —— state & 0xFFFF 值为 0：无写锁；值 > 0：当前线程持有写锁，数值即重入次数。
• 高 16 位（16–31）：表示读锁状态 —— (state >> 16) & 0xFFFF 值为 0：无读锁；值 > 0：当前有若干个读线程（或同一读线程多次重入）正在持有读锁。

注意：state 是 volatile int，所有读写都必须通过 compareAndSetState 完成，不可用 setState 直接赋值，否则破坏原子性。

关键操作的位运算实现

以下为 tryAcquire / tryRelease 等钩子方法中需完成的核心逻辑（以非公平读写锁为例）：

• 获取写锁（tryAcquire）： 先检查 state 是否为 0（无读无写）；或是否为当前线程已持有写锁（需额外维护 thread-local 写重入计数）； 若满足，用 CAS 将低 16 位 +1（如：expect = state, update = state + 1）。
• 获取读锁（tryAcquireShared）： 允许在无写锁（(state & 0xFFFF) == 0）前提下进入； 高 16 位加 1：计算新 state = state + (1 ，再 CAS 更新； 若失败（被其他线程抢先修改），需重试。
• 释放写锁（tryRelease）： 仅当当前线程是写锁持有者时才执行； 低 16 位减 1：update = state - 1，CAS 成功后判断是否完全释放（低 16 位归零）。
• 释放读锁（tryReleaseShared）： 高 16 位减 1：update = state - (1 ，CAS 更新； 注意：读锁释放不唤醒写线程的时机需结合队列头节点状态判断（避免写饥饿）。

必须配套实现的辅助机制

仅靠位运算是不够的，还需补充三项关键设计：

• 读线程身份识别： 读锁可被多个线程同时持有，但释放时需知道“哪个线程释放了几次”。建议用 ThreadLocal 记录当前线程的读重入次数，避免误减或漏减。
• 写优先策略控制： 若不加限制，持续读请求可能导致写线程长期饥饿。可在 tryAcquire 中增加判断：若队列中 head.next 是写线程节点，且当前无写锁但有等待写线程，则拒绝新读锁获取（即“写插队”）。
• 中断与超时支持： acquireSharedInterruptibly 和 tryAcquireSharedNanos 需在循环 CAS 前检查中断状态，并在阻塞前注册取消节点（waitStatus = CANCELLED）。

为什么不直接复用 ReentrantReadWriteLock

如果你的需求只是读写互斥+重入，它已高度优化且经过充分验证；但若需定制行为（如：读锁降级为写锁、带条件变量的读写分离、绑定资源配额的读写限流），则基于 AQS 自定义是合理选择。此时位运算 state 是最轻量、最可控的状态载体，比引入额外对象或 Map 结构更高效。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《AQS位运算实现读写锁技巧解析》文章吧，也可关注golang学习网公众号了解相关技术文章。