ReentrantLock公平锁与非公平锁源码分析
时间:2026-04-15 11:54:46 227浏览 收藏
本文深入剖析了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学习网公众号了解相关技术文章。
-
501 收藏
-
501 收藏
-
501 收藏
-
501 收藏
-
501 收藏
-
147 收藏
-
262 收藏
-
115 收藏
-
276 收藏
-
453 收藏
-
414 收藏
-
300 收藏
-
340 收藏
-
267 收藏
-
469 收藏
-
463 收藏
-
486 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习