Java公平锁与非公平锁原理及性能对比

1. 锁机制基础与核心概念

在Java并发编程中，锁是控制多线程访问共享资源的核心机制。公平锁与非公平锁作为两种不同的锁获取策略，直接影响着线程调度的行为和系统整体性能。理解它们的区别需要先明确几个基础概念：

• 可重入锁（ReentrantLock）：Java中除synchronized外最常用的锁实现，允许线程重复获取已经持有的锁
• 同步队列（CLH队列）：维护等待锁的线程队列，决定了锁分配的先后顺序
• 线程调度开销：线程挂起和唤醒需要操作系统介入，会产生上下文切换的成本

公平性本质上解决的是"锁被释放时，应该分配给哪个线程"的问题。想象银行柜台办理业务：公平锁就像严格按取号顺序办理（先来先服务），非公平锁则像新来的客户可以插队与当前正在排队的客户竞争办理机会。

关键理解：公平性不是锁本身的属性，而是指锁获取策略的公平性。同一个ReentrantLock实例可以通过构造参数在两种模式间切换。

2. 公平锁实现原理深度解析

2.1 公平锁的工作机制

公平锁的核心实现体现在ReentrantLock.FairSync类中。当线程尝试获取锁时，会先检查同步队列中是否有等待线程：

protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (!hasQueuedPredecessors() && // 关键判断：检查是否有更早的等待线程 compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } // ... 重入逻辑省略 return false; }

hasQueuedPredecessors()方法会遍历CLH队列，确保当前线程是等待时间最长的。这种设计带来两个特点：

1. 绝对有序性：严格按照线程请求锁的顺序分配
2. 性能代价：每次获取锁都需要检查队列状态，增加CAS操作次数

2.2 公平锁的典型问题

在实际使用中，我们发现公平锁存在一些固有缺陷：

• 吞吐量下降：测试数据显示，在高竞争场景下，公平锁的吞吐量可能比非公平锁低40%以上
• 头部阻塞风险：如果队首线程被阻塞或执行缓慢，会拖累整个队列
• 上下文切换频繁：线程必须严格排队等待，导致更多的线程状态切换

一个典型的错误使用场景是在短任务中盲目使用公平锁。比如处理HTTP请求时，如果每个请求都等待公平锁，当QPS达到5000+时，系统吞吐量会急剧下降。

3. 非公平锁的实现与优势

3.1 非公平锁的工作流程

非公平锁的实现类NonfairSync直接尝试获取锁，不检查队列状态：

final void lock() { if (compareAndSetState(0, 1)) // 直接尝试抢锁 setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); }

这种设计带来了性能优势：

1. 减少CAS操作：成功抢锁的线程无需检查队列
2. 利用时间局部性：刚释放锁的线程再次获取概率高
3. 降低上下文切换：减少线程挂起/唤醒次数

3.2 非公平锁的适用场景

通过JMH基准测试对比，非公平锁在以下场景表现优异：

1. 锁持有时间短：当临界区执行时间<100μs时
2. 线程竞争适中：并发线程数在CPU核心数2-4倍时
3. 吞吐量优先：如消息队列的消费者处理

测试案例：一个订单处理系统使用非公平锁，TPS从1200提升到2100，但99线延迟从8ms增加到15ms。这种trade-off在多数互联网应用中是可接受的。

4. 对比分析与选型建议

4.1 性能对比实测数据

通过以下测试环境对比两种锁的表现（8核CPU，16GB内存）：

4.2 选型决策树

根据业务场景选择锁策略的决策路径：

1. 是否需要严格顺序保证？
   • 是 → 选择公平锁（如金融交易顺序处理）
   • 否 → 进入下一步
2. 临界区执行时间是否<1ms？
   • 是 → 优先非公平锁
   • 否 → 进入下一步
3. 线程竞争是否激烈（并发线程>CPU核心数×2）？
   • 是 → 考虑公平锁减少饥饿
   • 否 → 非公平锁

经验法则：默认使用非公平锁，仅在明确需要顺序保证或出现线程饥饿问题时才考虑公平锁。

5. 高级应用与问题排查

5.1 混合模式实践

在某些特殊场景下，可以采用混合策略。例如电商秒杀系统：

// 秒杀阶段使用非公平锁提高吞吐 private final ReentrantLock seckillLock = new ReentrantLock(false); // 订单创建使用公平锁保证顺序 private final ReentrantLock orderLock = new ReentrantLock(true);

5.2 常见问题排查指南

问题1：线程饥饿现象

• 表现：某些线程长时间获取不到锁
• 检查：使用JStack查看线程状态
• 解决：增加等待超时机制或改用公平锁

问题2：性能突然下降

• 检查：用Arthas监控锁竞争情况
• 可能原因：锁持有时间变长或并发突增
• 优化：缩短临界区或调整锁策略

问题3：死锁风险

• 预防：使用tryLock()设置超时时间
• 诊断：JConsole的线程死锁检测功能

6. 底层机制与JVM关系

6.1 AQS实现细节

两种锁的差异本质上是AbstractQueuedSynchronizer（AQS）的不同使用方式：

• 公平锁：严格遵循FIFO，通过hasQueuedPredecessors()实现
• 非公平锁：允许插队，体现在nonfairTryAcquire()方法中

AQS的CLH队列采用无锁CAS设计，这也是Java锁性能优于原生互斥量的关键。

6.2 与JVM线程调度的交互

锁策略会影响JVM的线程调度行为：

1. 公平锁导致更多线程进入BLOCKED状态
2. 非公平锁下RUNNABLE线程更多
3. 在NUMA架构下，非公平锁可能引发跨节点内存访问

通过-XX:+PrintSafepointStatistics可以观察锁与安全点的关系。

7. 最佳实践与性能调优

7.1 参数调优建议

1. 对于非公平锁，适当增加自旋次数：

   new ReentrantLock(false).tryLock(100, TimeUnit.MILLISECONDS);

2. 监控锁竞争情况：

   jcmd <pid> Thread.print

3. 考虑偏向锁优化：

   -XX:+UseBiasedLocking

7.2 替代方案比较

当锁成为性能瓶颈时，可考虑：

在JDK21中，虚拟线程的引入改变了锁竞争的格局。实测显示，在10,000个虚拟线程竞争非公平锁的场景下，吞吐量比平台线程高出5-8倍。