ReentrantLock公平锁与非公平锁源码分析

本文深入剖析了ReentrantLock中公平锁与非公平锁的核心实现差异：非公平锁通过在lock()时优先CAS抢锁，牺牲一定公平性换取更低的线程挂起/唤醒开销和更高吞吐量，尤其适合短临锁场景，但也可能导致个别线程短暂饥饿；而公平锁则强制所有线程严格按FIFO顺序排队，借助hasQueuedPredecessors()在获取锁前多一次volatile读检查，确保绝对公平，却带来额外性能损耗；二者底层均依赖AQS队列，但调度逻辑的关键区别不在于队列结构，而在于tryAcquire的准入策略和unparkSuccessor的唤醒时机——看似微小的代码差异，实则是高并发下吞吐量与响应公平性之间的深刻权衡。

NonfairSync.lock() 为什么总先抢一次

非公平锁的 lock() 方法在进入等待队列前，会用 CAS 直接尝试修改 state 值为 1。成功就直接占有锁、设置 exclusiveOwnerThread；失败才走 acquire(1) 进入 AQS 标准流程。这意味着：哪怕队列里已有线程在等，新来的线程仍可能“插队”成功。

这种设计不是 bug，是明确的性能取舍——减少线程挂起/唤醒开销，尤其在锁持有时间短、竞争不激烈的场景下，吞吐量明显更高。

• 源码路径：NonfairSync.lock() → compareAndSetState(0, 1)
• 典型现象：高并发下，tryLock() 成功率比公平锁高，但个别线程可能连续几次都抢不到，出现短暂“饥饿”
• 注意：acquire(1) 内部调用的 tryAcquire 仍是非公平逻辑，不是“进队后再公平排队”

FairSync.tryAcquire() 如何强制排队

公平锁的 tryAcquire 在判断 state == 0 后，**多做了一步检查**：!hasQueuedPredecessors()。这个方法本质是判断当前线程是否排在同步队列 head 后第一个有效节点（即是否真正在队首），只有为 true 才允许获取锁。

换句话说：即使锁空闲，只要队列非空（哪怕只有一个线程在等），新线程也必须老老实实加到队尾，不能跳过前面的人。

• 关键代码：if (c == 0 && !hasQueuedPredecessors() && compareAndSetState(0, acquires))
• 代价：每次 lock() 都要读一次队列头尾指针，且 hasQueuedPredecessors() 是 volatile 读，比纯 CAS 开销略大
• 副作用：在锁争抢剧烈时，acquire 调用频次上升，AQS 队列节点创建和 CAS 自旋次数增加

waitStatus 和 unparkSuccessor 怎么体现调度差异

AQS 的 FIFO 队列本身对公平/非公平不做区分，真正起作用的是「谁被 unpark」以及「何时 unpark」。

unparkSuccessor(Node node) 总是从 node.next 开始向后找第一个 waitStatus 的节点唤醒。但在公平锁下，由于新线程从不插队，head 后第一个节点大概率就是等待最久的那个；而非公平锁下，刚唤醒的线程可能立刻又抢到锁，而队列中间的节点还在沉睡。

• 调试线索：打断点在 unparkSuccessor，观察每次唤醒的 Node.thread 是否符合预期顺序
• 注意：waitStatus = CANCELLED（值为 1）的节点会被跳过，所以队列中实际有效节点数 ≠ queue.size()
• 非公平锁的「唤醒即抢锁」行为，使得 shouldParkAfterFailedAcquire 中的 park 次数可能远少于公平锁

构造参数 false/true 对 sync 字段的直接影响

ReentrantLock 的构造函数只决定 sync 字段初始化为 FairSync 还是 NonfairSync 实例，后续所有加锁、释放、条件变量操作，都通过该实例的重写方法分发。

没有中间层切换逻辑，也没有运行时动态变更机制。一旦实例化，公平性就固定了。

• 默认构造：new ReentrantLock() → sync = new NonfairSync()
• 显式指定：new ReentrantLock(true) → sync = new FairSync()；new ReentrantLock(false) 仍是 NonfairSync
• 容易忽略的点：公平锁的「公平」仅作用于「尚未获得锁的线程」；已持有锁的线程重入时，不参与排队，直接 state++

公平锁的队列调度逻辑藏在 hasQueuedPredecessors() 里，而不是队列结构本身；非公平锁的“不公平”也不是完全随机，而是由「抢锁优先级高于排队」这一条规则驱动。真正影响性能的，往往不是锁本身，而是你是否让锁的调度策略匹配了业务线程的实际等待模式。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《ReentrantLock公平锁与非公平锁源码分析》文章吧，也可关注golang学习网公众号了解相关技术文章。