并发编程 —— 源码分析公平锁和非公平锁
前言
ReentrantLock 提供了公平锁和非公平锁,只需要在构造方法中使用一个 boolean
参数即可。默认非公平锁。
今天从源码层面看看区别和具体实现。
1. 类 UML 图

ReentrantLock
内部有一个抽象类 Sync
,继承了 AQS。
而公平锁的实现就是 FairSync
,非公平锁的实现就是 NodFairSync
。
两把锁的区别在于 lock
方法的实现。
2. 公平锁 lock 方法实现
final void lock() { acquire(1); }
调用的是 AQS 的acquire
方法,熟悉 AQS 的同学都知道,AQS 会回调子类的 tryAcquire
方法,看看公平锁的tryAcquire
实现。
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; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; }
说下逻辑:
- 获取 state 变量,如果是 0,说明锁可以获取。
- 判断 AQS 队列中是否有等待的线程,如果没有,就使用 CAS 尝试获取。获取成功后,将 CLH 的持有线程修改为当前线程。
- 重入锁逻辑。
- 如果失败,返回 false, AQS 会将这个线程放进队列,并挂起。
注意上面的第二步:判断 AQS 队列中是否有等待的线程。
这就是公平的体现。
再看看非公平锁的区别。
3. 非公平锁 lock 方法实现
final void lock() { if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); } protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); }
lock 方法就不同了,很冲动的一个方法,直接使用 CAS 获取锁,如果成功了,就设置锁的持有线程为自己。很快速。所以默认使用了非公平锁。
如果失败了,就调用 AQS 的 acquire
方法。当然,我们看的还是tryAcquire
方法,在上面的代码中,tryAcquire
方法调用了父类 Sync
的 nonfairTryAcquire
,为什么在父类中呢?
在 ReentrantLock
的 tryLock
方法中,也调用了该方法。因为这个方法是快速返回的。该方法不会让等待时间久的线程获取锁。符合 tryLock
的设计。
方法实现如下:
final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; }
该方法相比较公平锁的 tryAcquire
方法,少了一步判断 AQS 队列中是否有等待的线程的操作。
他要做的就是直接抢锁,不让给队列里那些等待时间长的。
抢不到再进入队列。等待他的前置节点唤醒他。这个过程是公平的。
4. 总结
ReentrantLock
中的公平锁和非公平锁的区别就在于:调用 lock
方法获取锁的时候 要不要判断 AQS 队列中是否有等待的线程
,公平锁为了让每一个线程都均衡的使用锁,就需要判断,如果有,让给他,非公平锁很霸道,不让不让就不让。
但如果失败了,进入队列了,进会按照 AQS 的逻辑来,整体顺序就是公平的。
还有个注意的地方就是:ReentrantLock
的 tryLock(无超时机制)
方法使用的非公平策略。符合他的设计。
而 tryLock(long timeout, TimeUnit unit)
方法则会根据 Sync 的具体实现来调用。不会冲动的调用 nonfairTryAcquire
方法。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试?测试工程师会被淘汰吗?