stampedlock 默认写锁非公平，易导致写线程饥饿；需通过退避策略、读操作分级、writepending 信号化或读写分离架构主动防控。
StampedLock 本身不直接解决写线程饥饿问题，它默认的写锁是“非公平”的——新来的写线程可能插队成功，导致已有等待的写线程长期得不到执行。要防止写饥饿，必须主动干预调度逻辑，不能依赖 StampedLock 默认行为。
理解写饥饿的真实成因
在极端高并发下，大量读线程持续调用 tryOptimisticRead 或 readLock，会不断刷新乐观读戳记或持有读锁；此时若有写线程反复尝试 writeLock 却总被新到的读线程“截胡”，就形成写饥饿。这不是锁缺陷，而是读优先策略的自然结果。
启用写锁公平性控制（关键手段）
StampedLock 没有内置公平开关，但可通过“写锁抢占抑制”模拟类公平行为：在写线程获取锁失败时，主动让出 CPU 并短暂退避，降低插队概率。
- 使用
Thread.onSpinWait()（Java 9+）或短时Thread.yield()配合自旋计数，避免无意义空转 - 对连续失败次数设限（如 10 次），超限时改用阻塞式
writeLockInterruptibly()，确保最终一定能进入 - 避免单纯
Thread.sleep(1)—— 毫秒级休眠在高并发下开销过大且不可控
读操作分级 + 写请求信号化
将读分为“轻量乐观读”和“重量悲观读”，减少长时读锁占用；同时为写操作引入显式等待信号，打破读-写的无限循环。
- 只对极短、确定无修改的场景用
tryOptimisticRead+ 校验，其余读操作统一走readLock/unlockRead，并严格控制持有时长 - 维护一个 volatile boolean
writePending标志位，写线程在首次尝试失败时置为 true；读线程在获取读锁前检查该标志，若为 true 则主动放弃或降级为重试间隔更长的策略 - 写线程成功获取锁后立即清空标志，保证信号及时收敛
替代方案：读写分离 + 时间片轮转（适用于特定场景）
当业务允许微小延迟（如毫秒级），可绕过锁竞争，改用“双缓冲+版本号”结构：
- 维护两个数据副本 A 和 B，加一个原子整数 version 表示当前有效副本
- 写线程始终修改非活跃副本，完成后 CAS 切换 version；读线程仅做 volatile 读，零锁开销
- 配合 LMAX Disruptor 或 RingBuffer 实现无锁批量写入，从根本上消除写线程排队
StampedLock 的价值在于低开销读性能，而非调度公平性。防写饥饿不是调用某个方法就能解决，而是需要结合退避策略、读行为约束和必要时的架构让步。真正压测中，往往发现适度放宽读一致性要求，比死磕锁公平更有效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
