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

ReentrantReadWriteLock的公平性是全局的，读锁和写锁均遵循同一公平策略：构造时传入true启用公平模式（FIFO顺序），否则为非公平模式（写线程可插队）；不存在仅对写锁公平的配置。

Java 中的读写锁（ReentrantReadWriteLock）本身不直接提供“写锁申请时的公平性保障”这一独立机制，它的公平性行为完全继承自其底层使用的 Sync 同步器——而该同步器的公平性由构造时指定的 fair 参数决定，**对读锁和写锁一视同仁**。

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

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

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

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

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

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

立即学习“Java免费学习笔记（深入）”；

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

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

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

非公平模式允许新来的写线程绕过队列，直接尝试抢占锁：

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

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

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

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

所以，公平模式保障的是**整体请求顺序的公正性**，不是给写操作特殊优待。