ReentrantLock(true)为公平锁，强制线程按等待顺序获取锁；ReentrantLock(false)为非公平锁，默认允许新线程抢占，吞吐高但可能引发饥饿，且公平性仅影响lock()，tryLock()始终非公平。
ReentrantLock(true) 和 ReentrantLock(false) 到底差在哪
公平锁和非公平锁的差别不在“能不能抢”，而在“要不要排队”。ReentrantLock(true) 强制线程按等待顺序获取锁，ReentrantLock(false)（默认）允许新来的线程直接尝试抢占——哪怕队列里有人等着。
这会导致两种截然不同的行为模式：公平锁吞吐低、延迟可预测；非公平锁吞吐高、但个别线程可能饿死。
- 公平锁适合对响应时间敏感、且持有锁时间极短的场景（比如高频小粒度同步）
- 非公平锁是绝大多数业务的合理默认：它减少了线程挂起/唤醒次数，CPU 缓存更友好
- 注意：
ReentrantLock的公平性只影响lock()，不影响tryLock()——后者永远是非公平的
怎么测出公平锁真的更慢
别用单线程测，也别只压 10 次。公平锁的性能代价主要体现在高并发争抢 + 锁持有时间短时的上下文切换放大效应。
一个靠谱的最小测试结构：
立即学习“Java免费学习笔记（深入）”；
for (int i = 0; i < threadCount; i++) {
new Thread(() -> {
for (int j = 0; j < iterationsPerThread; j++) {
lock.lock(); // 注意：这里必须用 lock()，不是 tryLock()
try {
// 做点轻量事，比如 count++，别 sleep 或 IO
} finally {
lock.unlock();
}
}
}).start();
}
- 线程数建议 ≥ 8，每线程迭代 ≥ 10000，否则调度噪声盖过差异
- 用
System.nanoTime()测总耗时，别信System.currentTimeMillis() - 实测中，非公平锁在 16 线程争抢下通常比公平锁快 2–5 倍；公平锁的 99% 延迟更集中，但平均延迟更高
公平锁不是“更安全”，反而容易暴露隐蔽 bug
很多人以为公平锁能避免死锁或活锁——其实它只是让问题更容易复现。
比如两个线程交叉持有锁 A/B 并尝试获取对方的锁，非公平锁可能因随机抢占“侥幸”绕过死锁；而公平锁会严格排队，大概率卡死在第一步。
- 公平锁会让“锁顺序依赖”类 bug 更稳定触发，调试时反而更难绕过去
- 如果业务逻辑本身没保证锁获取顺序，开公平锁只是把偶发 hang 变成必现 hang
-
ReentrantLock.isFair()返回 true 不代表当前没被插队——它只说明构造时传了true，不反映运行时状态
别在 Spring @Transactional 里手动配公平锁
Spring 的声明式事务底层用的是 DataSourceTransactionManager 或 JTA，和 ReentrantLock 完全无关。你在 service 方法里 new 一个 ReentrantLock(true)，既不会影响数据库事务隔离级别，也不会让@Transactional 更“公平”。
- @Transactional 控制的是数据库连接和事务传播，不是 JVM 线程调度
- 混合使用容易造成误解：比如认为“加了公平锁就能防止脏读”，其实完全不相关
- 真要控制并发访问 DB，该用
SELECT ... FOR UPDATE或应用层分布式锁，而不是本地 JVM 锁
