如果你在开发高并发应用时曾经遇到过这样的场景一个热点数据被频繁读取但偶尔需要更新。你信心满满地使用了标准的读写锁却发现写线程像被“饿死”了一样永远等不到执行的机会——因为读锁源源不断地被获取写线程的请求被无限期地推迟。这不是代码逻辑错误而是标准读写锁设计上的一个经典缺陷写者饥饿。今天要深入探讨的FairRWLock就是为了解决这个“公平性”痛点而生的。它不是一个全新的锁而是一种对传统读写锁的增强设计思想与实现。其核心目标非常明确在保证读写锁高性能的同时引入公平性确保写请求不会被无限期地延迟从而避免写者饥饿提升系统的整体响应性和数据新鲜度。这篇文章不会停留在概念复述上。我们将从“写者饥饿”这个真实的生产问题切入拆解FairRWLock的核心原理特别是其“票号”排队机制并用 Java 代码实现一个简易但完整的公平读写锁。你会看到公平性的引入并非没有代价它是在吞吐量和延迟之间做出的一个关键权衡。对于读多写少但写操作时效性要求高的场景如缓存更新、配置热加载、排行榜刷新FairRWLock是一个值得深入理解和应用的利器。1. 这篇文章真正要解决的问题写者饥饿与系统响应性为什么我们要专门讨论一个“公平”的读写锁因为标准读写锁如 Java 的ReentrantReadWriteLock在非公平模式下在极端场景下会导致严重的业务问题。想象一个电商商品详情页的缓存场景。99% 的请求是查询读1% 的请求是管理员更新商品信息写。使用非公平读写锁时由于读锁是共享的可以同时被多个线程持有。在超高并发读请求下读锁可能被持续持有写线程申请写锁时会发现有读锁未被释放于是它必须等待。然而在它等待的过程中新的读请求可能源源不断地到来并成功获取读锁因为读锁之间不互斥导致写线程等待队列前的读锁永远清空不了。这就是写者饥饿。带来的后果是什么数据更新延迟商品价格改了但用户看到的还是旧价格直到某个“幸运”的流量间隙。系统状态滞后配置中心推送了新配置服务端却迟迟无法生效。用户体验割裂在社交应用中用户发布了新动态其好友却要很久才能刷到。FairRWLock要解决的正是这个“公平性”问题。它确保锁的申请按照一个相对公平的顺序如 FIFO来处理即使你是写锁只要你先申请就不会被后申请的读锁无限插队。这牺牲了一点绝对吞吐量但换来了更可预测的延迟和更好的系统行为。对于后端开发者、中间件研发和任何构建高并发数据访问组件的工程师来说理解并能在合适场景应用FairRWLock是优化系统稳定性的重要一环。2. 基础概念与核心原理从读写锁到公平排队在深入FairRWLock之前我们需要统一几个核心概念。读写锁将访问共享资源的线程分为两类读者只读取数据不修改。多个读者可以同时访问资源。写者会修改数据。写者必须独占访问资源即同时只能有一个写者且当写者持有锁时不能有任何读者。这种设计显著提升了纯读场景的并发度。Java 中的ReentrantReadWriteLock是其典型实现。公平 vs 非公平非公平锁线程申请锁时可以“插队”尝试直接获取而不管等待队列中是否有其他线程正在等待。这能提高吞吐量但可能导致饥饿。公平锁锁严格按照请求到达的顺序FIFO来授予。这避免了饥饿但增加了上下文切换开销可能降低吞吐。写者饥饿在非公平的读写锁中由于读锁可共享且获取频繁写锁可能因为始终有读锁存在而长期无法获取导致写线程无限期等待。那么FairRWLock是如何实现公平的呢其核心是一种“票号”或“序列”排队机制。我们来看一个经典的设计思路全局序列号维护一个全局递增的nextSeq原子变量。取号每个线程无论是读是写在申请锁时先获取一个唯一的、递增的序列号mySeq。排队等待线程不会直接去竞争锁而是等待直到“叫到自己的号”。叫号条件一个线程可以获取锁的条件是所有比它序号小的线程都已经“完成工作”释放了锁。区分读写在判断“完成工作”时需要根据锁类型进行精细控制对于读锁允许序号相邻的多个读线程同时获取锁共享。对于写锁必须严格等待前一个序号无论读写的线程释放锁后才能获取独占。这种机制本质上是将锁的竞争转化为对一个序列号的等待严格保证了 FIFO 顺序从而实现了公平。java.util.concurrent.locks.ReentrantReadWriteLock在其公平模式new ReentrantReadWriteLock(true)下内部就采用了类似的复杂队列管理来实现公平性。3. 环境准备与前置条件为了彻底理解并实践FairRWLock我们将使用 Java 进行原理演示和简易实现。你需要准备以下环境JDK版本 8 或以上本文代码基于 JDK 8 的语法和并发包。建议使用 JDK 11 或 17 等 LTS 版本以获得更好的性能和支持。IDE任何你熟悉的 Java IDE如 IntelliJ IDEA, Eclipse 或 VS Code with Java extensions。构建工具Maven 或 Gradle可选用于管理依赖但本文示例仅需标准库。基础知识需要对 Java 并发编程有基本了解包括synchronized、ReentrantLock、ReentrantReadWriteLock、AtomicInteger、volatile等概念。本文的重点是原理和核心实现因此不会引入额外的第三方库。所有代码都基于java.util.concurrent包。4. 核心流程拆解FairRWLock 的工作步骤让我们把FairRWLock的运作分解为几个关键步骤这有助于我们后续编写代码。4.1 锁状态定义我们需要跟踪两种状态当前服务到的序列号(servingSeq)表示已经可以获取锁的最大序号。当前持有锁的读者数量(readerCount)因为读锁是共享的可能有多个读者同时持有。4.2 读锁获取流程线程调用readLock().lock()。获取一个全局唯一的申请序号mySeq通过原子递增计数器。循环检查条件如果mySeq servingSeq说明还没轮到自己线程通过LockSupport.park()或条件变量等待。当mySeq servingSeq时线程成功“入围”。此时它需要和相邻序号的线程协调如果相邻的也是读请求它们可以一起获取锁并递增readerCount。但需要小心处理读/写交替的情况。一个简单的公平实现是即使自己是读者也必须等待前一个序号可能是写者完全释放锁后才能获取。然后它可以获取读锁并将servingSeq递增唤醒下一个等待线程。在实际设计中为了允许连续的读者批量获取逻辑会更复杂。一种常见做法是使用一个“队列节点”对象来代表每个等待线程节点中记录其序号和锁类型读/写。4.3 写锁获取流程线程调用writeLock().lock()。同样获取申请序号mySeq。循环等待直到mySeq servingSeq。由于写锁是独占的它必须额外等待readerCount 0确保没有读者持有锁。条件满足后获取写锁并将servingSeq递增唤醒下一个等待线程。4.4 锁释放流程读锁释放减少readerCount。如果readerCount减到 0并且有写者在等待即servingSeq对应的线程是写者则可能需要唤醒该写者。但在严格的票号机制下释放锁本身通常不直接唤醒而是由获取锁的线程在成功获取后递增servingSeq并唤醒下一个。写锁释放直接递增servingSeq并唤醒下一个等待线程。可以看到整个机制的核心是servingSeq的推进和线程在各自序号上的等待。这保证了严格的 FIFO 顺序。5. 完整示例与代码实现一个简易的 FairRWLock下面我们将实现一个简化版的FairRWLock。这个实现旨在清晰展示“票号公平”的核心思想它并非生产级缺少可重入、中断处理等高级特性但足以让你理解其骨架。我们将创建一个FairReadWriteLock类它内部维护一个等待队列的虚拟表示通过序号和条件变量。import java.util.concurrent.atomic.AtomicInteger; import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; /** * 一个简易的、演示公平性原理的读写锁实现。 * 注意此实现为教学目的简化未实现可重入、锁降级等特性不适用于生产环境。 */ public class FairReadWriteLock { // 全局序列号生成器 private final AtomicInteger nextSeq new AtomicInteger(0); // 当前正在服务的序列号 private int servingSeq 0; // 当前持有读锁的线程数量 private int readerCount 0; // 保护内部状态的主锁 private final Lock stateLock new ReentrantLock(true); // 使用一个公平锁来保护内部状态 // 条件变量用于线程等待 private final Condition condition stateLock.newCondition(); // 读锁和写锁的实例 private final ReadLock readLock new ReadLock(); private final WriteLock writeLock new WriteLock(); public Lock readLock() { return readLock; } public Lock writeLock() { return writeLock; } /** * 内部读锁实现 */ private class ReadLock implements Lock { Override public void lock() { stateLock.lock(); try { int mySeq nextSeq.getAndIncrement(); // 取号 // 等待轮到自己并且没有写锁持有实际上在servingSeq机制下前一个如果是写它释放后才会递增servingSeq while (mySeq ! servingSeq) { condition.await(); } // 成功获取读锁 readerCount; // 关键作为读者获取锁后需要尝试推进 servingSeq。 // 但推进的条件是下一个等待者不能是可与当前读者共享锁的读者。 // 简化处理我们假设每次获取锁后都尝试唤醒下一个。更复杂的实现需要检查下一个等待者的类型。 // 这里我们采用一个简单策略读者获取后立即增加 servingSeq 以允许下一个线程尝试。 // 注意这可能会破坏严格的“读者并发”但在简单公平模型中这确保了前进。 servingSeq; condition.signalAll(); // 唤醒所有让下一个线程检查条件 } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 throw new RuntimeException(Interrupted while acquiring read lock, e); } finally { stateLock.unlock(); } } Override public void unlock() { stateLock.lock(); try { readerCount--; if (readerCount 0) { // 所有读者都释放了可以唤醒等待的写者如果有 // 在我们的简单模型中唤醒由 lock() 方法中的 signalAll 处理 condition.signalAll(); } } finally { stateLock.unlock(); } } // 以下方法为了接口兼容简化实现非重点 Override public void lockInterruptibly() throws InterruptedException { lock(); } Override public boolean tryLock() { return false; } Override public boolean tryLock(long time, java.util.concurrent.TimeUnit unit) { return false; } Override public Condition newCondition() { return null; } } /** * 内部写锁实现 */ private class WriteLock implements Lock { Override public void lock() { stateLock.lock(); try { int mySeq nextSeq.getAndIncrement(); // 取号 // 等待轮到自己并且没有活跃的读者 while (mySeq ! servingSeq || readerCount 0) { condition.await(); } // 成功获取写锁此时 readerCount 保证为 0 // servingSeq 在获取写锁时不需要立即增加因为写锁独占。 // 但为了模型一致我们也可以在获取后增加。这里选择在释放时增加。 // 获取写锁后servingSeq 不应该变直到释放。 } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(Interrupted while acquiring write lock, e); } finally { stateLock.unlock(); } } Override public void unlock() { stateLock.lock(); try { // 释放写锁推进服务号 servingSeq; condition.signalAll(); // 唤醒下一个等待线程 } finally { stateLock.unlock(); } } // 以下方法简化实现非重点 Override public void lockInterruptibly() throws InterruptedException { lock(); } Override public boolean tryLock() { return false; } Override public boolean tryLock(long time, java.util.concurrent.TimeUnit unit) { return false; } Override public Condition newCondition() { return null; } } }代码关键点解释状态保护所有对servingSeq、readerCount的修改都通过一个内部的stateLock一个公平的ReentrantLock来保护确保线程安全。取号与等待nextSeq是原子整数用于分发全局唯一的申请序号。线程在lock()时首先取号 (mySeq)。公平等待循环while (mySeq ! servingSeq)是公平性的核心。线程必须等待直到自己的序号被“服务到”。对于写锁额外增加了readerCount 0的条件。服务号推进这是最微妙的部分。在读锁的lock()中我们采用了一种简化策略读者获取锁后立即增加servingSeq并唤醒所有等待者。这保证了队列前进但可能让本可以并发的读者串行化因为下一个读者需要重新循环判断。更高效的实现需要维护一个队列来区分读写并允许连续的读者一起获取锁。在写锁的unlock()中我们增加servingSeq。唤醒机制使用condition.signalAll()进行广播唤醒。被唤醒的线程会重新检查自己的while条件符合条件的则成功获取锁。这里使用signalAll()是为了简化生产实现中为了性能会使用signal()精确唤醒队首线程。这个简易实现清晰地展示了“票号公平”的骨架但它的性能不是最优的因为它让许多读者也进行了不必要的串行化。接下来我们看一个更接近生产思路的优化版本关键设计。6. 运行结果与效果验证模拟写者饥饿与公平解救为了验证我们的FairReadWriteLock是否能解决写者饥饿我们编写一个测试程序。同时我们也会用 Java 标准的ReentrantReadWriteLock在非公平模式下运行作为对比。首先我们创建一个共享资源和一个测试任务。import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; public class FairRWLockDemo { static class SharedResource { private int value 0; // 使用我们自制的公平锁 private final FairReadWriteLock customLock new FairReadWriteLock(); // 使用JDK标准的非公平读写锁作为对比 private final ReadWriteLock jdkUnfairLock new ReentrantReadWriteLock(false); public void readWithCustomLock(String threadName) { Lock lock customLock.readLock(); lock.lock(); try { System.out.println(System.currentTimeMillis() - threadName 读取: value); Thread.sleep(50); // 模拟读取耗时 } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } public void writeWithCustomLock(String threadName, int newValue) { Lock lock customLock.writeLock(); lock.lock(); try { value newValue; System.out.println(System.currentTimeMillis() - threadName 写入: value); Thread.sleep(100); // 模拟写入耗时 } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } public void readWithJdkLock(String threadName) { Lock lock jdkUnfairLock.readLock(); lock.lock(); try { System.out.println(System.currentTimeMillis() - threadName [JDK] 读取: value); Thread.sleep(50); } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } public void writeWithJdkLock(String threadName, int newValue) { Lock lock jdkUnfairLock.writeLock(); lock.lock(); try { value newValue; System.out.println(System.currentTimeMillis() - threadName [JDK] 写入: value); Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } } public static void main(String[] args) throws InterruptedException { SharedResource resource new SharedResource(); System.out.println( 测试1: 使用自定义 FairReadWriteLock (模拟公平性) ); // 启动一个写线程 W1它会在开始时尝试写入 Thread writer1 new Thread(() - resource.writeWithCustomLock(W1, 1), Writer-1); // 启动多个读线程它们会持续读取尝试“饿死”写线程 for (int i 0; i 5; i) { final int id i; new Thread(() - { for (int j 0; j 3; j) { resource.readWithCustomLock(R id); } }, Reader- i).start(); } // 稍后启动写线程观察它是否被饿死 Thread.sleep(10); writer1.start(); // 等待所有线程结束 Thread.sleep(2000); System.out.println(\n 测试2: 使用 JDK ReentrantReadWriteLock (非公平模式) ); // 重置资源 resource new SharedResource(); // 同样先启动大量读线程 for (int i 0; i 5; i) { final int id i; new Thread(() - { for (int j 0; j 5; j) { // 读更多次增加饥饿概率 resource.readWithJdkLock(R id); } }, JDK-Reader- i).start(); } // 写线程稍后启动 Thread writer2 new Thread(() - resource.writeWithJdkLock(W2, 2), JDK-Writer-2); Thread.sleep(50); writer2.start(); // 等待足够时间观察输出 Thread.sleep(3000); } }如何运行与观察结果将FairReadWriteLock类和FairRWLockDemo类放在同一个包下编译并运行FairRWLockDemo的main方法。观察控制台输出时间戳有助于观察顺序测试1 (自定义公平锁)你会看到尽管有多个读线程先启动并不断读取但写线程W1的“写入”操作很可能在某个时间点得以执行而不是永远被推迟。这是因为我们的简易公平锁强制了某种程度的 FIFO 顺序。注意由于我们的简易实现让读者也部分串行化写者的等待时间可能相对可预测。测试2 (JDK 非公平锁)你可能会观察到读线程[JDK] 读取的输出连续出现非常多条而写线程[JDK] 写入的输出被推迟到很后面甚至可能在所有读操作结束后才出现。这演示了写者饥饿现象。在高并发下这种延迟会非常明显。结果验证要点成功的公平锁实现应能保证写请求在有限时间内得到响应而不是被无限推迟。由于线程调度和休眠时间的不确定性单次运行可能无法完美复现极端饥饿但多次运行或增加读线程数量/循环次数趋势会很明显。我们的简易FairReadWriteLock在公平性上有效但性能并非最优。JDK 的ReentrantReadWriteLock(true)提供了工业级的、性能更好的公平实现。7. 常见问题与排查思路在理解和实现公平读写锁时你可能会遇到以下问题问题现象可能原因排查方式解决方案死锁程序卡住无任何输出。1. 锁获取与释放不成对。2. 在lock()和unlock()之间抛出了异常导致锁未释放。3. 公平锁实现中servingSeq推进逻辑错误导致没有线程能满足获取条件。1. 检查每个lock()是否都有对应的unlock()并放在finally块中。2. 添加详细日志打印每个线程的mySeq和servingSeq。3. 使用 jstack 或 IDE 调试器查看线程转储分析所有线程的等待状态。1. 严格遵循tryLock-finally unlock模式。2. 确保servingSeq的递增发生在锁释放或成功获取后且逻辑覆盖所有分支。3. 考虑使用更成熟的并发库如 JDK 自带锁。性能远差于非公平锁1. 公平锁强制 FIFO增加了上下文切换。2. 简易实现中使用了signalAll()导致不必要的唤醒风暴。3. 锁粒度太粗保护整个状态的stateLock竞争激烈。1. 进行基准测试 (JMH)对比公平与非公平模式下的吞吐量。2. 使用性能分析工具 (如 Async Profiler) 查看热点是否大量时间花在await()/signalAll()上。1.仅在需要避免饥饿的场景使用公平锁。2. 优化为使用signal()只唤醒队列头部的合适线程。3. 参考ReentrantReadWriteLock.FairSync使用 CLH 队列变体减少竞争。写锁获取后读锁完全无法获取这是正常行为。写锁是独占的。问题可能在于写锁持有时间过长阻塞了所有读请求。检查写锁临界区内的代码是否执行了耗时操作如 IO、网络调用。优化写操作逻辑缩短持有写锁的时间。考虑使用锁降级如果支持或 Copy-On-Write 等模式。“公平”只是近似公平并非绝对时间顺序线程调度、signal()唤醒的延迟可能导致后申请的线程先被调度执行。但锁的授予顺序servingSeq是严格 FIFO 的。理解“公平”指的是锁分配顺序的公平而非操作系统线程调度的公平。这是预期行为。如果需要更严格的控制可能需要结合其他同步机制但这通常是不必要的。自定义锁不支持可重入简易实现未记录锁的持有者同一线程重复获取锁会导致死锁。线程尝试重入时被自己阻塞。实现中增加ThreadLocal或一个Map来记录重入次数。对于生产环境直接使用ReentrantReadWriteLock。8. 最佳实践与工程建议理解了FairRWLock的原理和实现后如何在项目中做出正确选择和应用优先使用标准库在绝大多数情况下不要自己实现读写锁。Java 的java.util.concurrent.locks.ReentrantReadWriteLock已经提供了经过充分测试、性能优异的公平和非公平实现。通过构造函数new ReentrantReadWriteLock(true)即可获取公平锁。明确使用场景公平锁不是默认选择。请仔细评估使用公平锁的场景写操作虽然不频繁但时效性要求极高不能被延迟。例如金融交易系统中的风控规则更新、实时竞价系统中的底价更新。使用非公平锁的场景读多写少且写操作延迟稍高可以接受。这是默认且性能更高的选择适用于大多数缓存、元数据查询等场景。监控与度量在生产系统中使用锁时务必监控锁等待时间特别是写锁的等待时间。如果写锁平均等待时间持续增长可能是饥饿或系统过载的信号。锁持有时间分析读锁和写锁的持有时间优化临界区代码。线程转储定期或在高延迟时采集线程转储检查是否有大量线程阻塞在锁获取上。考虑更高级的并发结构读写锁并非万能。根据具体场景可能有更好的选择StampedLockJDK 8 引入提供了乐观读模式在读多写少且读冲突不高的场景下性能可能更好。但它不是可重入的且 API 更复杂。并发容器ConcurrentHashMap、CopyOnWriteArrayList等内部使用了更精细的并发控制可能完全避免你显式使用读写锁。无锁编程对于极高性能要求可以考虑Atomic变量、LongAdder或Disruptor等无锁结构。避免在锁中执行阻塞操作绝对不要在持有锁尤其是写锁时进行网络调用、数据库查询或任何可能长时间阻塞的操作。这会将性能瓶颈放大到整个系统。锁降级的谨慎使用ReentrantReadWriteLock支持锁降级先获取写锁再获取读锁然后释放写锁。这在需要先修改后保证一致性读取的场景有用但逻辑容易出错需仔细设计。测试与压测在集成公平锁后必须进行严格的压力测试和并发测试。验证在模拟的“读风暴”下写请求的延迟是否仍在可接受范围内。同时对比与非公平模式的吞吐量差异评估性能代价是否值得。9. 总结与后续学习方向FairRWLock的核心价值在于它提供了一种权衡用一部分潜在的吞吐量换取更公平的调度和更可预测的写延迟。它解决了高并发场景下一个隐蔽却可能致命的问题——写者饥饿。通过本文你应该已经掌握了问题根源理解了标准非公平读写锁在极端读多写少场景下为何会导致写者饥饿。核心原理掌握了通过“全局序列号”和“服务号”来实现 FIFO 公平排队的基本思想。简易实现动手实现了一个演示性质的公平读写锁虽然性能不高但揭示了核心状态机和协调逻辑。对比验证通过测试程序直观看到了公平锁与非公平锁在写延迟上的差异。工程实践知道了在真实项目中何时该用公平锁以及更重要的——优先使用成熟的标准库实现。如果你想继续深入建议从以下几个方向学习深入 JDK 源码阅读ReentrantReadWriteLock.FairSync和NonfairSync的源码这是学习高级并发编程的绝佳材料。看 Doug Lea 大师是如何通过一个 AQS 队列优雅地管理这两种策略的。研究其他公平锁变体例如有的公平锁实现允许“读者组”一起获取锁即连续的读者可以共享这需要在队列节点中记录类型并实现更复杂的唤醒逻辑。探索无锁替代方案了解StampedLock的乐观读和如何用它来替代读写锁并理解其适用边界。性能基准测试使用 JMH 对公平锁、非公平锁、StampedLock在不同读写比例下的性能进行量化测试形成你自己的数据决策依据。并发工具的选型永远是业务场景、数据一致性和性能之间权衡的艺术。FairRWLock只是工具箱中的一件利器知其然并知其所以然才能在复杂的系统设计中做出最合适的选择。
