非公平锁的lock()方法先通过CAS直接抢占锁，成功则立即持有，失败才入队；其核心是跳过队列检查、允许插队，吞吐量更高但可能引发饥饿。
非公平锁的 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 工程师权衡后认为，实际业务中线程调度器本身就有时间片机制兜底，且吞吐收益远大于理论饥饿概率。
