登录
首页 >  文章 >  java教程

如何通过 AQS 的独占模式源码剖析 ReentrantLock 实现非公平竞争的抢占逻辑

时间:2026-05-03 13:18:46 345浏览 收藏

本篇文章给大家分享《如何通过 AQS 的独占模式源码剖析 ReentrantLock 实现非公平竞争的抢占逻辑》,覆盖了文章的常见基础知识,其实一个语言的全部知识点一篇文章是不可能说完的,但希望通过这些问题,让读者对自己的掌握程度有一定的认识(B 数),从而弥补自己的不足,更好的掌握它。

非公平锁的lock()方法先通过CAS直接抢占锁,成功则立即持有,失败才入队;其核心是跳过队列检查、允许插队,吞吐量更高但可能引发饥饿。

如何通过 AQS 的独占模式源码剖析 ReentrantLock 实现非公平竞争的抢占逻辑

非公平锁的 lock() 方法直接 CAS 抢占

ReentrantLock 默认构造时创建的是 NonfairSync 实例,它的 lock() 方法第一行就体现“非公平”本质:不查队列、不等顺序,直接 compareAndSetState(0, 1) 尝试把锁状态从空闲改为已占用。

这个操作成功,就立刻调用 setExclusiveOwnerThread(Thread.currentThread()),把当前线程设为持有者,整个加锁过程结束——连 AQS 的排队逻辑都绕过了。

常见错误现象是误以为“调用了 lock() 就一定进队列”,其实只要没有竞争,非公平锁根本不会触发 acquire(1) 流程;只有 CAS 失败时才走标准排队路径。

  • 场景:低并发或锁刚释放后立即有新线程来抢,大概率命中 CAS 成功
  • 参数差异:state 初始为 0,CAS 目标值固定为 1,不依赖队列长度或前驱节点状态
  • 性能影响:避免了入队、唤醒、上下文切换开销,吞吐量比公平锁高 10%–30%,实测在 Contended Lock 场景下尤为明显

nonfairTryAcquire() 允许插队重试

当线程在 acquire(1) 中调用 tryAcquire() 时,NonfairSync 委托给 nonfairTryAcquire(int)。它和公平锁的 tryAcquire() 最大区别在于:即使 AQS 队列里已有等待线程,只要 state == 0,它仍会再次尝试 CAS 抢占。

也就是说,一个刚到达的线程,可能在队列里排第三,却因为此时锁恰好被释放(state 回到 0),直接抢走——把原本该轮到的队首线程“插队”了。

  • 容易踩的坑:以为“进了 acquire() 就老老实实排队”,其实 nonfairTryAcquire() 在每次循环中都会无条件重试抢占
  • 关键判断只有两个:if (c == 0)else if (current == getExclusiveOwnerThread()),前者不检查 hasQueuedPredecessors()
  • 兼容性注意:JDK 8–21 所有版本行为一致,但某些定制 JVM(如 Zing)可能对 CAS 失败后退避策略做微调

公平锁的 hasQueuedPredecessors() 是分水岭

对比来看,FairSync.tryAcquire() 开头就调用 hasQueuedPredecessors(),这个方法返回 true 当且仅当:队列非空 **且** 队首后继节点不是当前线程(即存在更早排队者)。

一旦返回 true,哪怕 state == 0,它也直接返回 false,强制当前线程进队——这就是“公平”的代码落点。

NonfairSync 完全跳过这步检查,所以它的抢占逻辑既发生在 lock() 入口,也藏在每次 acquireQueued 循环的 tryAcquire() 调用里。

  • 调试技巧:在 nonfairTryAcquire 中加断点,观察 getState()hasQueuedPredecessors() 返回值,能直观看到插队时机
  • 不要混淆:队列是否为空(head == tail)≠ 是否有前驱,hasQueuedPredecessors() 看的是 head.next != null && head.next.thread != current

为什么默认非公平?关键在 acquireQueued 的自旋设计

acquireQueued() 是 AQS 独占模式的核心循环体,它在 park 前会反复调用 tryAcquire()。对非公平锁来说,这就意味着:一个已在队列中的线程,在被 unpark 唤醒后,第一件事不是谦让,而是再抢一次。

这种“唤醒即抢占”的设计,配合入口处的初始 CAS,构成了两层非公平保障:未入队时抢,入队后唤醒还抢。

真正容易被忽略的复杂点是:这种逻辑在高竞争下会导致部分线程长期得不到调度(饥饿风险),但 JDK 工程师权衡后认为,实际业务中线程调度器本身就有时间片机制兜底,且吞吐收益远大于理论饥饿概率。

今天关于《如何通过 AQS 的独占模式源码剖析 ReentrantLock 实现非公平竞争的抢占逻辑》的内容介绍就到此结束,如果有什么疑问或者建议,可以在golang学习网公众号下多多回复交流;文中若有不正之处,也希望回复留言以告知!

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