公平锁性能低于非公平锁，核心在于FIFO调度引发更高上下文切换（达133倍）、CPU缓存局部性破坏及锁空置时间更长；非公平锁支持直接CAS抢占，减少唤醒与调度开销，提升吞吐量。
公平锁性能通常低于非公平锁，核心原因在于调度策略引发的额外开销——主要是线程上下文切换更频繁、CPU缓存局部性被破坏、以及锁空置时间更长。
上下文切换开销显著增加
公平锁强制按 FIFO 顺序唤醒等待队列头部线程。每次释放锁后，必须唤醒队列首节点，即使该线程尚未准备好执行，也会触发一次完整的上下文切换。实测数据显示：在相同并发压力下，公平锁的线程切换次数可达非公平锁的 133 倍，耗时为其 94.3 倍。
- 非公平锁释放后，若恰好有新线程立即请求，可直接 CAS 抢占，无需唤醒操作
- 公平锁则必须走“释放→唤醒队首→队首线程调度→执行”完整链路，中间至少两次切换
CPU 缓存与执行连续性被削弱
刚释放锁的线程往往仍驻留在 CPU 核心上，其数据和指令缓存热度尚存。非公平锁允许它在锁释放后立刻重入，复用已有缓存状态；而公平锁会把机会让给队列中可能远在其他核上休眠的线程，导致：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 新唤醒线程需重新加载锁状态、临界区变量到本地缓存
- 缓存行失效（cache invalidation）增多，总线争用加剧
- 执行路径中断，流水线清空成本上升
锁空置时间更长，资源利用率下降
公平锁要求新请求线程无条件排队，哪怕锁刚刚释放、当前无任何线程持有——它仍要先入队再等唤醒。这造成锁在释放与下一次获取之间出现明显空窗期。
立即学习“Java免费学习笔记（深入）”；
- 非公平锁在此刻允许“抢入”，锁几乎无缝流转
- 公平锁则需完成入队 + 唤醒 + 调度三步，空置时间拉长，吞吐量自然受限
- 多核环境下，队列维护本身（如 CLH 队列的 volatile 写）也带来可观内存屏障开销
不是不能用，而是代价明确
公平锁牺牲性能换来了确定性：避免饥饿、行为可预测、调试友好。但它不适用于锁持有时间短、竞争激烈、吞吐优先的场景。JDK 默认采用非公平模式，正是基于真实业务负载下的综合权衡。
