非公平锁吞吐量更高，因其省略公平锁的hasqueuedpredecessors()队列检查，直接cas抢锁，避免volatile读开销、缓存竞争及park/unpark上下文切换，仅抢失败时才入队等待。

非公平锁吞吐量更高，核心在于它绕过了公平锁中那个关键的队列前置检查——hasQueuedPredecessors()。这个方法看似轻量，实则在高并发下成了性能瓶颈。

抢占逻辑差异：一上来就抢 vs 先查队列再试

非公平锁的 lock() 方法第一步就是直接 CAS 尝试抢锁：
– 如果 state == 0，立刻执行 compareAndSetState(0, 1)，成功就持有锁，不进队、不挂起、不切换上下文；
– 失败才走标准 AQS 流程：入队 → park → 等待唤醒。

公平锁则不同：
– 即使 state == 0，也必须先调用 hasQueuedPredecessors()；
– 该方法会读取 AQS 的 head/tail 节点，判断队列是否为空、自己是否排在队首；
– 只有返回 false（即无人排队或自己是队首）时，才允许后续 CAS。

变量访问开销：volatile 读与缓存竞争

hasQueuedPredecessors() 不是零成本操作：
– 它至少触发两次 volatile 读：一次读 state，一次读 head 节点；
– 在多核 CPU 上，频繁读同一 volatile 地址会引发缓存行同步（cache line invalidation），加剧总线争用；
– 即使队列为空，也要完整走完链表探查逻辑，无法像非公平锁那样“快路径直落”。

而非公平锁在抢中场景下，仅需一次 volatile 写（CAS 修改 state），完全避开队列结构访问。

线程状态变化：省掉 park/unpark 就省掉毫秒级延迟

公平锁强制所有新请求线程都经历完整等待流程：
– 新建 Node 实例；
– CAS 更新 tail 指针；
– 设置前驱节点 waitStatus = SIGNAL；
– 调用 LockSupport.park() 进入 WAITING 状态。

这些步骤带来明显开销：
– 用户态到内核态切换（上下文切换耗时通常在微秒至毫秒级）；
– 频繁内存分配增加 GC 压力；
– 线程唤醒依赖 head.next 链表遍历，还可能跳过 CANCELLED 节点。

非公平锁在锁刚释放瞬间，常被下一个线程直接抢中，整个过程停留在用户态、无阻塞、无调度介入。

实际表现：不是永远不排队，而是“能抢则抢”

非公平锁并非无视队列秩序：
– 抢失败后，依然乖乖入队、按 FIFO 被唤醒；
– 饥饿只发生在极端场景：临界区极短 + 新线程持续高频抵达；
– 正常业务中，只要临界区超过几十纳秒，队列中的线程基本都能获得执行机会。

而公平锁的“绝对公平”代价是：每个线程无论是否能立即执行，都必须走一遍 park/unpark，把本可并行的锁获取动作，硬生生串行化到队列状态上。