Java ReentrantReadWriteLock 写锁为什么会等待：公平策略、读者降临与线程饥饿

线上配置快照通常是读多写少：四个线程不断读，发布线程偶尔拿写锁更新。问题是写锁一等，读请求并没有自然消失，日志里会同时出现“写入延迟升高”和“读锁获取次数继续增加”。关键不在于把读锁全部改成互斥锁，而在于先判断锁的公平策略是否允许新读者插队。

先看清写线程到底在等什么

ReadWriteLock 维护一对关联锁：没有写者占用时，多个读者可以同时持有 read lock；write lock 则要求独占。Oracle 的 Java SE 25 文档也提醒，偏向读者可能无限延迟写者，偏向写者又会减少并发。

所以“写锁为什么会等待”有两个层次：已有读者还没释放，这是正常互斥；写线程已经排队后，新的读者还能否继续获得读锁，这是公平策略的边界。

用同一实验复现读者与写者的交错

下面的程序启动四个读线程，持续 220 毫秒反复获取 read lock；主线程等待读线程启动 20 毫秒后申请 write lock。readerAcquires 不是性能基准，它只用来证明读路径确实反复运行；真正关心的是写线程从申请到获锁经历了多久。

var lock = new ReentrantReadWriteLock(fair);
lock.readLock().lock();
try {
    readers.incrementAndGet();
    Thread.onSpinWait();
} finally {
    lock.readLock().unlock();
}

long begin = System.nanoTime();
lock.writeLock().lock();
long waitedMs = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - begin);

先运行 javac RwLockExperiment.java && java RwLockExperiment。本次截图的 fair=false 表示非公平构造；输出中的 value=1 证明写入动作已经完成。非公平策略下，读线程更容易在锁空档再次竞争；一次运行可能只等待几毫秒，也可能受到调度影响明显变长。这里不要把单次数字当成固定承诺，重点是观察读写竞争的关系。

公平策略改变的是排队边界，不是把写锁变成并发锁

把构造参数改为 true 后，本次截图的 fair=true 表示公平构造；输出中的 value=1 仍然证明写入动作已经完成。读写线程仍然需要同一把锁，写锁仍只能由一个线程持有。变化在于已有等待者会影响后来者的竞争机会：当写线程已经排队，后来读者不应无限地从旁边插入。

公平并不等于所有线程严格按创建顺序执行，也不等于延迟一定更低。它更像一个排队约束：牺牲一部分读路径的即时吞吐，换取写线程不会被持续到达的读者长期压住。

生产代码如何选择与复查

如果配置快照的写入必须在可接受窗口内完成，先用公平锁做小规模压测，再观察写锁等待分位数和读请求延迟。若写入只是低优先级刷新、读路径极短且吞吐更重要，可以评估非公平锁，但要把写等待上限纳入告警。

无论选择哪一种，都要保证每条路径使用 try/finally 释放锁。升级读锁为写锁不是这段实验的目标：读锁持有者直接申请写锁可能形成等待闭环，应该先释放读锁，再重新设计状态校验。

常见问题

公平锁能完全消除线程饥饿吗？

它能限制后来线程持续插队，但仍受线程调度、锁持有时间和系统负载影响，不能承诺固定延迟。

为什么 readerAcquires 越大不代表程序越好？

它只说明读线程获取过读锁的次数，读锁过度占用反而可能让写线程等待更久；应与写等待分位数一起看。

读锁可以直接升级成写锁吗？

不要把升级当成安全操作。先释放读锁再申请写锁时，必须重新检查数据版本或条件，避免校验结果已经过期。

把一次实验变成可执行的判断

这段实验确认了三个事实：读锁可以并发、写锁排他、公平策略影响等待者与后来者的竞争关系。实际接入前，把 writerWaitMs 换成真实指标，分别压测公平和非公平两种构造，再按写入时限、读延迟和锁持有时间做决定。