登录
首页 >  文章 >  java教程

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

时间:2026-04-15 11:54:46 227浏览 收藏

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

怎么利用 ReentrantLock 的公平锁与非公平锁源码理解 AQS 对等待队列的调度差异

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学习网公众号了解相关技术文章。

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>