ReentrantLock(true)是公平锁，按调用lock()顺序排队；false（默认）是非公平锁，允许新线程插队抢占。前者避免饥饿但吞吐低，后者性能高，适用于大多数场景。
ReentrantLock(true) 和 ReentrantLock(false) 到底差在哪
差在「线程抢锁时要不要插队」——true 是公平锁，谁先调用 lock() 谁排队等；false（默认）是非公平锁，新来的线程可以立刻尝试抢占，哪怕队列里有人等着。
这不是理论区别，是真实影响吞吐和响应的行为差异：
- 公平锁：避免饥饿，但上下文切换多、整体吞吐低；适合锁持有时间长、且对响应顺序敏感的场景（比如资源分配器）
- 非公平锁：允许“插队”，减少了线程挂起/唤醒开销，吞吐高；绝大多数业务场景更合适
- 注意：
ReentrantLock的公平性只约束「未持有锁时的获取行为」，重入（同一个线程反复lock()）永远被允许，跟公平性无关
为什么 new ReentrantLock() 默认是非公平的
因为性能。JVM 线程调度本身就不保证 FIFO，强行维护公平队列要额外 CAS 操作和 volatile 读写，每次 lock() 都得多走几步判断队列头。
实测中，在高并发争抢下，非公平锁吞吐量通常比公平锁高 2–10 倍，尤其在锁持有时间短（比如只是更新一个计数器）时更明显。
- 非公平锁可能让等待很久的线程一直得不到机会（饥饿），但实际中除非极端负载+长持有，很少发生
- 公平锁的「公平」仅限于 AQS 队列内的等待者，不包括正在执行
compareAndSetState抢锁的线程 - 构造时没传参数，就是
new ReentrantLock(false)，别误以为是「自动选择」
公平锁无法解决所有排队问题
它只管「谁该获得锁」，不管「谁该被唤醒」或「锁释放后谁接上」——这些由 AQS 内部的 unparkSuccessor 控制，而该方法在公平/非公平模式下行为一致：总是唤醒队列头节点。
常见误解：
- 认为公平锁能让线程按
lock()调用时间精确排序 → 实际受 JVM 调度、CAS 成败、内存可见性影响，只能保证「大致先后」 - 在 synchronized 上套 ReentrantLock 公平锁想「升级控制力」→ 没用，synchronized 无公平选项，两者锁对象也不互通
- 把公平锁当线程优先级调控手段 → 完全无关，优先级由 OS 调度器决定，JVM 不暴露干预接口
什么时候真该用 ReentrantLock(true)
只有当你观察到明确的饥饿现象，且能确认是锁竞争导致，并排除了其他瓶颈（如 GC、IO 阻塞、CPU 争抢），才考虑切换。
典型信号：
- 监控发现某线程在
WAITING状态停留远超均值（比如 >5 秒），且堆栈固定在AbstractQueuedSynchronizer$ConditionObject.await - 业务逻辑要求严格 FIFO：例如订单号生成器必须按请求到达顺序分配递增 ID
- 压测中非公平锁下 P99 响应时间抖动剧烈，而公平锁能收窄分布（需对比验证，不是默认成立）
切记：换公平锁前先看是不是锁粒度太大、持有时间太长，或者根本该用无锁结构（如 AtomicInteger）——这才是更常被忽略的优化点。
