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

作者：程序员小航 2021-07-01 09:42:08开发 前端 分布式 Redis 分布Redis sorted set 有序集合数据结构：存放等待线程的顺序，分数 score 用来是式锁等待线程的超时时间戳。

[[408587]]

前言

在上一篇文章中已经分析过公平锁的源码加锁源码，并得出结论：

Redis 平锁排队Hash 数据结构：存放当前锁，Redis 加锁Key 就是锁，Hash 的分布 field 是加锁线程，Hash 的式锁 value 是 重入次数;

Redis List 数据结构：充当线程等待队列，新的源码等待线程会使用 rpush 命令放在队列右边;

Redis sorted set 有序集合数据结构：存放等待线程的顺序，分数 score 用来是平锁排队等待线程的超时时间戳。

现在看一下加锁失败被放到等待队列之后，加锁线程是分布如何处理的?

1排队等锁

源码入口：org.redisson.RedissonLock#lock(long, java.util.concurrent.TimeUnit, boolean)。

线程进入排队之后，式锁在 Java 代码中会 while (true) 一直循环调用 tryAcquire，源码尝试获取锁。平锁排队

最终还是加锁来到 RedissonFairLock#tryLockInnerAsync 方法中。

方便起见，重新贴一下 Lua 脚本，以及脚本的参数含义。

1. KEYS[1]：加锁的名字，anyLock;
2. KEYS[2]：加锁等待队列，redisson_lock_queue:{ anyLock};
3. KEYS[3]：等待队列中线程锁时间的 set 集合，redisson_lock_timeout:{ anyLock}，是按照锁的时间戳存放到集合中的;
4. ARGV[1]：锁超时时间 30000
5. ARGV[2]：UUID:ThreadId 组合 a3da2c83-b084-425c-a70f-5d9a08b37f31:1
6. ARGV[3]：threadWaitTime 默认 300000
7. ARGV[4]：currentTime 当前时间戳

源码分析

第一部分，while 循环：

1. 从等待队列 redisson_lock_queue:{ anyLock} 中获取第一个等待线程;
2. 从等待线程超时集合 redisson_lock_timeout:{ anyLock} 中获取第一个等待线程的分数;
3. 没有超时，直接结束，超时了，则直接移除。

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

第三部分，当前锁不是持锁线程，直接跳过。

第四部分，

直接返回当前锁还有多久到期。

当前 Redisson 版本为 3.15.6，不同版本的略有不同。

队列重排

这里不存在重新排序，因为官方认为这是一个 bug，重新进行了修复。

具体可以阅读：Justin Corpron 2019/5/10, 04:13 Fix timeout drift in RedissonFairLock

最大的变化就是增加了第四部分。

图仅仅代表两个版本的差别，并不是代表这个版本才修改。

2总结

当线程获取锁失败，进入到等待队列时，ttl != null，在 Java 代码中会不断尝试获取锁。

当锁不存在且当前线程是在等待队列头时，直接获得锁。这个排队的过程就是公平锁的提现。

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

 

责任编辑：武晓燕 来源： 程序员小航 Redisson分布式锁

(责任编辑：焦点)