reentrantlock默认使用非公平锁，因其在高并发下吞吐量更高：非公平锁直接cas抢锁，跳过aqs队列操作；公平锁需先检查队首线程并触发内存屏障和上下文切换，实测吞吐可低至非公平锁的1/10。
公平锁在 ReentrantLock 中导致频繁上下文切换，核心原因是它强制线程严格按 FIFO 顺序排队等待，每次释放锁后必须唤醒队列头的线程，而不能让刚到达的新线程“插队”获取锁。
公平锁必须严格遵循等待队列顺序
公平锁内部使用 FairSync 实现，每次调用 tryAcquire 前，都会检查当前线程是否是 AQS 同步队列中排在最前面的等待者（即 !hasQueuedPredecessors() 成立）。只有满足该条件，才允许尝试 CAS 获取锁。这意味着：
- 即使锁刚被释放、没有竞争，也不会直接交给新来的线程；
- 必须先唤醒并调度队列头部的阻塞线程，哪怕它刚被挂起几毫秒；
- 线程从
BLOCKED→ 被唤醒 → 抢占 CPU → 执行临界区 → 释放锁 → 再次阻塞，整个过程反复触发内核态调度。
非公平锁能跳过队列直接抢占
非公平锁（NonfairSync）在 lock() 方法中第一步就是尝试直接 CAS 获取锁。只要锁空闲，无论是否有线程在队列里等待，新线程都能立刻拿到锁——这避免了唤醒、调度、上下文保存/恢复等开销。典型场景下：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 高并发写入时，多个线程几乎同时释放锁，新请求线程大概率“撞上”空闲锁状态；
- 无需排队、不唤醒沉睡线程，CPU 时间片更集中，吞吐量明显更高；
- 代价是：队列尾部的线程可能连续多次被“插队”，产生饥饿风险。
频繁切换的实际表现
在压测或高争用场景中，开启公平锁后常观察到：
-
CPU 上下文切换次数陡增（可通过
pidstat -w或 JFR 查看）； - 线程状态在
RUNNABLE↔BLOCKED↔WAITING之间高频震荡； - 平均延迟上升，尤其当队列较长时，尾部线程等待时间呈线性增长；
- JVM GC 日志中出现更多因线程调度引发的
ThreadState变更记录。
不是所有场景都该避开公平锁
公平性牺牲性能，但换来了可预测的响应边界。适合：
- 对延迟敏感且要求最大等待时间可控的系统（如实时交易指令分发）；
- 低并发但强顺序依赖的逻辑（如配额扣减、唯一序列生成）；
- 调试阶段为复现竞态问题，临时启用公平锁降低不确定性。
实际选型时，优先用非公平锁；仅当实测确认存在严重饥饿且影响业务 SLA，再谨慎启用公平锁，并配合监控验证切换成本。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
