公平锁与非公平锁区别及性能对比

ReentrantLock的公平锁与非公平锁核心差异在于线程获取锁的调度策略：公平锁强制FIFO排队，保障响应可预测但吞吐低、易暴露锁顺序缺陷；非公平锁允许新线程抢占，显著提升高并发下的性能（实测快2–5倍），减少上下文切换开销，是多数业务更优默认选择——但需谨记，其公平性仅作用于lock()方法，tryLock()永远非公平，且该机制仅约束JVM内线程竞争，与数据库事务、分布式场景完全无关，误用公平锁不仅无法解决脏读或死锁根本问题，反而可能将偶发问题固化为必现故障。

ReentrantLock(true) 和 ReentrantLock(false) 到底差在哪

公平锁和非公平锁的差别不在“能不能抢”，而在“要不要排队”。ReentrantLock(true) 强制线程按等待顺序获取锁，ReentrantLock(false)（默认）允许新来的线程直接尝试抢占——哪怕队列里有人等着。

这会导致两种截然不同的行为模式：公平锁吞吐低、延迟可预测；非公平锁吞吐高、但个别线程可能饿死。

• 公平锁适合对响应时间敏感、且持有锁时间极短的场景（比如高频小粒度同步）
• 非公平锁是绝大多数业务的合理默认：它减少了线程挂起/唤醒次数，CPU 缓存更友好
• 注意：ReentrantLock 的公平性只影响 lock()，不影响 tryLock() ——后者永远是非公平的

怎么测出公平锁真的更慢

别用单线程测，也别只压 10 次。公平锁的性能代价主要体现在高并发争抢 + 锁持有时间短时的上下文切换放大效应。

一个靠谱的最小测试结构：

for (int i = 0; i  {
        for (int j = 0; j 

• 线程数建议 ≥ 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 锁

公平锁和非公平锁的选择，本质是在“确定性”和“效率”之间做权衡。但这个权衡的前提是你清楚锁的边界——它只管本 JVM 内的线程，不管数据库、RPC、缓存或用户请求。一不小心，就拿错工具去拧螺丝。

终于介绍完啦！小伙伴们，这篇关于《公平锁与非公平锁区别及性能对比》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！