ReadWriteLock 的读锁是共享锁，允许多个线程在无写锁时并发获取并执行读操作，基于 AQS 高 16 位计数实现零竞争；但写锁存在时新读请求被阻塞，且读锁不可升级为写锁。
ReadWriteLock 的读锁本质上是共享锁，允许多个线程同时持有，这是它提升并发性能的关键设计。
读锁的共享机制如何工作
读锁不排斥其他读线程——只要没有线程持有写锁，任意数量的线程都可以成功获取读锁并并发执行读操作。这种共享性基于底层 AQS（AbstractQueuedSynchronizer）的状态位管理：读锁使用高16位记录持有读锁的线程数，支持可重入和计数，而非互斥抢占。
- 多个读线程调用 readLock().lock() 时，只要写锁未被占用，全部能立即成功返回
- 读锁之间无等待、无阻塞，真正实现“零竞争”读取
- 即使已有 100 个线程在读，第 101 个读线程仍可即时进入，无需排队
共享的前提条件：写锁空闲
读锁的共享不是无条件的。它的生效严格依赖于“当前无写锁被任何线程持有”。一旦有线程成功获取写锁，所有后续尝试获取读锁的线程都会被阻塞，直到写锁释放。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 写锁具有更高优先级，会“插队”中断读锁的连续获取
- 若写锁已在队列中等待，新来的读线程在公平模式下必须排队；非公平模式下可能短暂“插队”，但最终仍需等待写锁完成
- 正在执行读操作的线程不会被强制中断，但新读请求会在写锁存在时挂起
共享性带来的实际效果
在典型缓存、配置读取等场景中，读锁共享直接转化为吞吐量提升。例如一个高频查询的用户配置服务，100 个并发读请求可全部并行处理，而传统 synchronized 或 ReentrantLock 会让它们串行排队。
立即学习“Java免费学习笔记（深入）”；
- 避免了纯互斥锁造成的“读-读竞争”，消除不必要的上下文切换
- 读操作耗时越长，共享优势越明显（比如含 I/O 或计算的读逻辑）
- 注意：共享仅限于读锁本身，不意味着共享变量自动线程安全——仍需保证被读数据的可见性（如 volatile 或锁内更新）
共享性的边界与限制
读锁虽共享，但并非万能。它不支持升级为写锁，也不能绕过写锁独占原则。共享性只解决“读不互斥”，不解决“读写冲突”。
- 持有读锁的线程不能直接调用 writeLock().lock() —— 这会导致死锁
- 若需“先读后写”，应先释放读锁，再申请写锁（中间可能被其他写线程抢占）
- 锁降级（写锁 → 读锁）是允许的，用于保障写后立即读的数据可见性，但这属于写线程主动让渡，不是读锁的共享延伸
