Java 中读写锁在写锁申请时的公平性是如何保障的

我们先明确一点：ReentrantReadWriteLock 的公平性是全局统一的——读锁和写锁都按照同一套规则办事。构造时传入 true 就是公平模式，严格遵循 FIFO 顺序；默认或传入 false 则是非公平模式，写线程可以插队。不存在“只对写锁公平、对读锁非公平”这种偏袒配置，这一点从设计上就决定了。

实际上，Java 中的读写锁并没有单独搞一套“写锁申请时的公平性保障”机制。它的公平性行为完全继承自底层 Sync 同步器，而该同步器的公平性由构造时指定的 fair 参数决定——对读锁和写锁一视同仁，没有例外。

写锁的公平性取决于整个锁的公平模式

ReentrantReadWriteLock 支持公平与非公平两种模式，但这个选择是全局性的：

• 创建时传入 true：启用公平模式 → 写锁（以及读锁）都严格遵循 FIFO 队列顺序
• 默认或传入 false：非公平模式 → 写线程可“插队”，即使队列中有等待线程，也优先尝试直接获取锁

换句话说，**不存在“仅对写锁公平、对读锁非公平”的配置**。写锁是否排队、是否被唤醒，完全由当前锁的整体公平策略控制。

公平模式下写锁如何被调度

在公平锁模式中，写锁申请的公平性通过 AQS 的等待队列（CLH 队列）实现：

• 当写线程请求锁失败，会以独占模式加入同步队列尾部
• 释放写锁时，AQS 只唤醒队列头部的第一个节点（无论它是读还是写线程）
• 若头节点是写线程，则它立即尝试获取写锁；若是读线程，则需满足“无其他写线程等待”等条件才能继续

关键点在于：**写线程不会被跳过**。只要它排在队列前面，且没有更高优先级的写操作干扰（如重入），就一定比后面到达的写线程更早获得锁。这保证了顺序的严密性。

非公平模式下写锁可能“插队”

非公平模式则给新来的写线程开了个“后门”——它们可以绕过队列，直接尝试抢占锁：

• 即使队列中已有多个读线程或写线程在等待，新写线程仍可调用 tryAcquire 尝试获取
• 若此时锁空闲，它就能立刻成功，导致队列中等待已久的写线程继续阻塞
• 这种行为提升了吞吐量，但也可能加剧写线程饥饿，尤其在读多写少场景下

如果你在追求极致吞吐量的场景中使用非公平模式，就得做好写线程被“插队”的心理准备。

注意：读写锁的公平性 ≠ 写优先

公平性只管“谁先来谁先得”，不区分读写类型。即使启用了公平模式：

• 如果队列头是读线程，且当前无写锁持有者，它会被唤醒并获取读锁
• 写线程必须等到所有排在它前面的线程（无论读写）都完成并释放资源后，才能轮到自己

所以，公平模式保障的是**整体请求顺序的公正性**，不是给写操作特殊优待。这一点常常被误解，值得特别留意。