Redisson 分布式锁源码之公平锁加锁-云智核

Redisson 分布式锁源码之公平锁加锁

发布时间：2025-11-05 15:45:32 来源：云智核作者：应用开发

默认的分布加锁逻辑是非公平的。

在加锁失败时，式锁线程会进入 while 循环，源码一直尝试获得锁，平锁这时候是加锁多线程进行竞争。就是分布说谁抢到就是谁的。

Redisson 提供了公平锁机制，式锁使用方式如下：

下面一起看下公平锁是如何实现的?

相信小伙伴们看过前面的文章，已经轻车熟路了，平锁直接定位到源码方法：RedissonFairLock#tryLockInnerAsync。加锁

好家伙，分布这一大块代码，式锁我截图也截不完，源码咱们直接分析 lua 脚本。平锁

PS：虽然咱不懂 lua，加锁但是这一堆堆的 if else 咱们大概还是能看懂的。

因为 debug 发现 command == RedisCommands.EVAL_LONG，所以直接看下面一部分。

这么长，网站模板连呼好几声好家伙!

先来看看参数都有啥?

加锁队列和集合是含有大括号的字符串。{XXXX} 是指这个 key 仅使用 XXXX 用来计算 slot 的位置。

上面的 lua 脚本是分为几块的，咱们分别从不同的角度看下上面代码的执行。

首次加锁(Thread1)

第一部分，因为是首次加锁，所以等待队列为空，直接跳出循环。这一部分执行结束。

第二部分：

执行完这里就 return 了。所以后面几部分就暂时不看了。

相当于下面两个命令(整个 lua 脚本都是原子的!)：

Thread2 加锁

当 Thread1 加锁完成之后，此时 Thread2 来加锁。

Thread2 可以是本实例其他线程，也可以是其他实例的线程。

第一部分，虽然锁被 Thread1 占用了，但是等待队列是空的，直接跳出循环。

第二部分，锁存在，直接跳过。

第三部分，线程是否持锁，没有持锁，直接跳过。b2b供应网

第四部分，线程是否在等待队列中，Thread2 才来加锁，不在里面，直接跳过。

Thread2 最后会来到这里：

zadd KEYS[3] timeout ARGV[2]

这里使用 zadd 命令分别放置的是，redisson_lock_timeout:{anyLock}，超时时间戳(1624612689520)，线程(UUID2:Thread2)。

其中超时时间戳当分数，用来在有序集合中排序，表示加锁的顺序。

Thread3 加锁

Thread1 占有了锁，Thread2 在等待，此时线程 3 来了。

获取 firstThreadId2 此时队列是有线程的是 UUID2:Thread2。

判断 firstThreadId2 的分数(超时时间戳)是不是小于当前时间戳：

小于等于则说明超时了，移除 firstThreadId2;

大于，则会进入后续判断。

第二、三、四部分都不满足条件。

Thread3 最后也会来到这里：

本文主要总结了公平锁的加锁逻辑，这里涉及到比较多的 Redis 操作，做一下简要总结：

需要理解的就是这里会额外添加一个等待队列，以及有序集合。

本文转载自微信公众号「程序员小航」，可以通过以下二维码关注。转载本文请联系程序员小航公众号。

随便看看