非公平锁吞吐更高，因其tryacquire中省略hasqueuedpredecessors()检查，直接cas抢锁，避免队列探查、入队、park/unpark及上下文切换开销。
看 NonfairSync.tryAcquire 里那行没检查队列的 CAS
非公平锁吞吐高的最直接原因，就藏在 tryAcquire 方法开头：它拿到锁状态为 0 后，**不调用 hasQueuedPredecessors()**，而是立刻执行 compareAndSetState(0, acquires)。这意味着刚到的新线程不用排队、不休眠，直接抢——抢成功就进临界区，抢失败才老老实实入队。
对比公平锁的同位置逻辑：!hasQueuedPredecessors() && compareAndSetState(...)，多一次队列判空 + 队首比对，哪怕只是几个 CPU 指令，也卡在了关键路径上。
- 高频短临界区场景下，大量线程“刚来就抢中”，省掉了整个入队 + park + 唤醒流程
-
hasQueuedPredecessors()内部要遍历 CLH 队列头节点的前驱，不是零成本操作 - 没有 park 就没有用户态→内核态切换，避免了上下文切换的毫秒级延迟
为什么 hasQueuedPredecessors() 是公平锁的性能瓶颈
这个方法表面只判断“当前线程是否排在队首”，但底层要读取 AQS 的 head 和 tail 节点，并检查 head.next != null && head.next.thread != Thread.currentThread()。它本质是一次**内存可见性敏感的链表探查**，在高争用下容易引发缓存行竞争。
更关键的是：它把“能否抢锁”这个本可并行的动作，变成了一个需要协调队列状态的串行检查点。
- 多个线程同时调用该方法时，会频繁读取同一块 volatile 内存（
head），触发 CPU 缓存同步开销 - 即使队列为空，也要走完完整判断逻辑，无法像非公平锁那样“快路径直落”
- 公平锁的每次
lock()至少两次 volatile 读（state + head），而非公平锁在抢中时仅需一次
非公平锁不是永远不排队，而是“能抢则抢，抢不过再排”
很多人误以为非公平锁完全无视队列，其实不然。NonfairSync 在抢锁失败后，依然会走 AQS 标准的 acquire 流程：入队 → park → 等待唤醒。它的“非公平”只体现在**首次尝试阶段**。
这也解释了为什么非公平锁不会彻底饿死等待线程：一旦抢不到，它就和公平锁一样老实在队尾排队，后续唤醒仍是 FIFO。
- 饥饿只发生在“持续有新线程高频抵达+临界区极短”的极端组合下
- 实际业务中，只要临界区不是纳秒级，队列中的线程总有机会被唤醒
- 而公平锁的“绝对公平”代价是：每个线程都必须经历 park/unpark，哪怕它本可以立刻抢中
默认用非公平锁，不是因为“不公平更好”，而是因场景适配
ReentrantLock 默认构造函数走的是 new NonfairSync()，这不是设计偏好，而是基于真实负载的权衡结果。JVM 中的 synchronized 同样默认非公平，背后逻辑一致。
真正需要公平锁的场景极少：比如任务调度器要求严格按提交顺序执行，或金融系统中指令执行序不能错乱。其余绝大多数 Web 服务、缓存、计数等场景，非公平锁的吞吐优势压倒性胜出。
- 吞吐差异在高并发下可达 2–5 倍（《Java 并发编程实战》数据）
- 公平锁的额外开销集中在锁获取端；非公平锁把压力转移到了锁释放端（唤醒逻辑不变）
- 如果你真测出公平锁更快，大概率是测试未打满 CPU 或临界区过长，掩盖了 park 成本
真正容易被忽略的点是：非公平锁的“高吞吐”依赖于线程到达节奏与临界区耗时的匹配。如果临界区很长，新线程抢中的概率趋近于 0，它就退化成和公平锁差不多的行为——但此时你该优化的早不是锁类型，而是临界区本身。
