公平锁性能低于非公平锁,核心在于FIFO调度引发更高上下文切换(达133倍)、CPU缓存局部性破坏及锁空置时间更长;非公平锁支持直接CAS抢占,减少唤醒与调度开销,提升吞吐量。

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


















