Java 中读写锁在写锁申请时的公平性是如何保障的
我们先明确一点：ReentrantReadWriteLock 的公平性是全局统一的——读锁和写锁都按照同一套规则办事。构造时传入 true 就是公平模式，严格遵循 FIFO 顺序；默认或传入 false 则是非公平模式，写线程可以插队。不存在“只对写锁公平、对读锁非公平”这种偏袒配置，这一点从设计上
我们先明确一点：ReentrantReadWriteLock 的公平性是全局统一的——读锁和写锁都按照同一套规则办事。构造时传入 true 就是公平模式，严格遵循 FIFO 顺序；默认或传入 false 则是非公平模式，写线程可以插队。不存在“只对写锁公平、对读锁非公平”这种偏袒配置，这一点从设计上就决定了。
实际上，Java 中的读写锁并没有单独搞一套“写锁申请时的公平性保障”机制。它的公平性行为完全继承自底层 Sync 同步器，而该同步器的公平性由构造时指定的 fair 参数决定——对读锁和写锁一视同仁，没有例外。
写锁的公平性取决于整个锁的公平模式
ReentrantReadWriteLock 支持公平与非公平两种模式，但这个选择是全局性的：
- 创建时传入
true：启用公平模式 → 写锁（以及读锁）都严格遵循 FIFO 队列顺序 - 默认或传入
false：非公平模式 → 写线程可“插队”，即使队列中有等待线程，也优先尝试直接获取锁
换句话说，**不存在“仅对写锁公平、对读锁非公平”的配置**。写锁是否排队、是否被唤醒，完全由当前锁的整体公平策略控制。
公平模式下写锁如何被调度
在公平锁模式中，写锁申请的公平性通过 AQS 的等待队列（CLH 队列）实现：
- 当写线程请求锁失败，会以独占模式加入同步队列尾部
- 释放写锁时，AQS 只唤醒队列头部的第一个节点（无论它是读还是写线程）
- 若头节点是写线程，则它立即尝试获取写锁；若是读线程，则需满足“无其他写线程等待”等条件才能继续
关键点在于：**写线程不会被跳过**。只要它排在队列前面，且没有更高优先级的写操作干扰（如重入），就一定比后面到达的写线程更早获得锁。这保证了顺序的严密性。
非公平模式下写锁可能“插队”
非公平模式则给新来的写线程开了个“后门”——它们可以绕过队列，直接尝试抢占锁：
- 即使队列中已有多个读线程或写线程在等待，新写线程仍可调用
tryAcquire尝试获取 - 若此时锁空闲，它就能立刻成功，导致队列中等待已久的写线程继续阻塞
- 这种行为提升了吞吐量，但也可能加剧写线程饥饿，尤其在读多写少场景下
如果你在追求极致吞吐量的场景中使用非公平模式，就得做好写线程被“插队”的心理准备。
注意：读写锁的公平性 ≠ 写优先
公平性只管“谁先来谁先得”，不区分读写类型。即使启用了公平模式：
- 如果队列头是读线程，且当前无写锁持有者，它会被唤醒并获取读锁
- 写线程必须等到所有排在它前面的线程（无论读写）都完成并释放资源后，才能轮到自己
所以，公平模式保障的是**整体请求顺序的公正性**，不是给写操作特殊优待。这一点常常被误解，值得特别留意。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
AirBuddy 3 是面向 macOS 的蓝牙外设增强工具，可集中查看 AirPods、Beats 与苹果设备电量，提供快速连接、播放控制、电量提醒、桌面小组件和多台 Mac 外设接力等功能。
AirServer macOS版可把 Mac 转换为无线投屏接收端，通过 AirPlay 或 Google Cast 接收手机、平板和电脑画面，并支持多设备同时连接、高清镜像及会话录制，适合家庭娱乐、课堂教学、会议演示和应用展示。
Autodesk Maya 是面向影视、电视、动画和游戏行业的专业三维制作软件，集多边形与 NURBS 建模、角色绑定、关键帧和动作捕捉动画、Bifrost 特效模拟、材质开发及 Arnold 渲染于一体，
AirServer Windows版可把电脑变成AirPlay、Google Cast和Miracast无线投屏接收端，适合会议演示、课堂教学及家庭大屏分享。发送设备通常无需另装客户端，并可同时接收和智能排列多个镜像会话。