ReentrantReadWriteLock默认读优先易致写饥饿，解决需三策：启用公平模式（new ReentrantReadWriteLock(true)）、严控读锁持有时间、设计写优先降级或数据结构分离。
ReentrantReadWriteLock 本身不直接解决写饥饿问题，它默认采用“读优先”策略，容易导致写线程长期等待。要避免写饥饿，核心是打破读线程持续霸占锁的局面，关键在于合理控制读锁持有时间、适时让写线程插队，并借助公平模式或主动干预机制。
启用公平模式（最直接有效）
ReentrantReadWriteLock 支持构造时传入 fair = true 参数，开启公平队列。此时线程按请求顺序排队，写线程不会被无限期推迟——只要有一个写请求在等待，后续新来的读线程就不能插队获取读锁（除非当前已有读锁且无写线程等待）。
- 公平模式下，锁的获取遵循 FIFO 原则，写线程最多等待前面已排队的线程执行完
- 注意：公平模式会带来一定性能开销（需维护队列、更多 CAS 操作），但对写操作实时性要求高的场景值得启用
- 示例：
new ReentrantReadWriteLock(true)
避免长时间持有读锁
写饥饿常源于读线程“一锁到底”——比如在读锁保护下执行 I/O、远程调用或复杂计算。这会让写线程一直卡在入口处。
- 读操作只包裹真正需要共享数据一致性的临界区，非必要逻辑（如日志、格式转换、网络发送）移出读锁范围
- 若读取后需做耗时处理，可先复制数据（如
new ArrayList(list)），再释放读锁进行后续操作 - 警惕“读锁内嵌套写锁尝试”（如 tryLock + 降级），这类逻辑易延长读锁占用，反而加剧饥饿
主动让写线程插队（写优先降级策略）
在业务逻辑允许的前提下，可设计“写提示”机制：当检测到写请求积压（例如连续 N 次读操作后未执行写），主动释放读锁并尝试获取写锁。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 用
writeLock.tryLock(0, TimeUnit.SECONDS)非阻塞试探——成功则执行写；失败也不阻塞，继续读流程 - 结合计数器或时间戳，在读操作中定期检查是否该“让位”，例如每 10 次读或 100ms 后尝试一次写锁抢占
- 适用于读多写少但写延迟敏感的场景（如配置热更新、状态快照落盘）
分离高频读与低频写的数据结构
从根本上减少锁竞争：把“被频繁读、偶尔写”的数据拆成两份——一份只读副本供读线程快速访问，另一份带锁的权威副本由写线程更新，再通过原子引用或 volatile 字段切换视图。
- 典型做法：用
AtomicReference包装不可变对象（如ImmutableList），写操作构建新实例后原子替换 - 读线程完全无锁，写线程仅需同步构建过程，规避了读写锁的所有排队问题
- 适合数据量不大、创建成本可控、读远大于写的场景（如路由表、白名单、配置快照）
不复杂但容易忽略：写饥饿不是锁本身的 bug，而是使用方式与业务节奏不匹配的表现。选对模式、管住读锁时长、必要时绕过锁，三者结合才能稳住读写平衡。
