AQS独占模式解析：ReentrantLock非公平锁实现原理

本文深入剖析了ReentrantLock中非公平锁的核心实现原理，揭示其通过两层CAS抢占机制（lock()入口直接尝试+acquireQueued唤醒后再次抢）跳过队列检查、允许新线程“插队”获取锁的本质，从而在低竞争或锁刚释放等场景下显著减少入队、唤醒和上下文切换开销，带来10%–30%的吞吐量提升；同时指出其虽存在理论饥饿风险，但JDK团队基于实际调度器保障与性能权衡，将非公平模式设为默认——读懂这段代码，你就真正理解了高并发下“效率优先”的工程取舍。

非公平锁的 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学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！