默认的加锁逻辑是非公平的。
在加锁失败时,线程会进入 while 循环,一直尝试获得锁,这时候是多线程进行竞争。就是说谁抢到就是谁的。
Redisson 提供了公平锁机制,使用方式如下:
RLock fairLock = redisson.getFairLock("anyLock");
// 最常见的使用方法
fairLock.lock();
下面一起看下公平锁是如何实现的?
相信小伙伴们看过前面的文章,已经轻车熟路了,直接定位到源码方法:RedissonFairLock#tryLockInnerAsync
。
好家伙,这一大块代码,我截图也截不完,咱们直接分析 lua 脚本。
PS:虽然咱不懂 lua,但是这一堆堆的 if else 咱们大概还是能看懂的。
因为 debug 发现 command == RedisCommands.EVAL_LONG
,所以直接看下面一部分。
这么长,连呼好几声好家伙!
先来看看参数都有啥?
anyLock
;redisson_lock_queue:{anyLock}
;redisson_lock_timeout:{anyLock}
,是按照锁的时间戳存放到集合中的;a3da2c83-b084-425c-a70f-5d9a08b37f31:1
;加锁队列和集合是含有大括号的字符串。{XXXX} 是指这个 key 仅使用 XXXX 用来计算 slot 的位置。
上面的 lua 脚本是分为几块的,咱们分别从不同的角度看下上面代码的执行。
第一部分,因为是首次加锁,所以等待队列为空,直接 跳出循环。这一部分执行结束。
第二部分:
执行完这里就 return
了。所以后面几部分就暂时不看了。
相当于下面两个命令(整个 lua 脚本都是原子的!):
> hset anyLock a3da2c83-b084-425c-a70f-5d9a08b37f31:1 1
> pexpire anyLock 30000
当 Thread1 加锁完成之后,此时 Thread2 来加锁。
Thread2 可以是本实例其他线程,也可以是其他实例的线程。
第一部分,虽然锁被 Thread1 占用了,但是等待队列是空的,直接跳出循环。
第二部分,锁存在,直接跳过。
第三部分,线程是否持锁,没有持锁,直接跳过。
第四部分,线程是否在等待队列中,Thread2 才来加锁,不在里面,直接跳过。
Thread2 最后会来到这里:
redisson_lock_queue:{anyLock}
中获取最后一个线程;ttl anyLock
;60000*5
;zadd KEYS[3] timeout ARGV[2]
这里使用 zadd 命令分别放置的是,redisson_lock_timeout:{anyLock}
,超时时间戳(1624612689520),线程(UUID2:Thread2)。
其中超时时间戳当分数,用来在有序集合中排序,表示加锁的顺序。
Thread1 占有了锁,Thread2 在等待,此时线程 3 来了。
获取 firstThreadId2 此时队列是有线程的是 UUID2:Thread2。
判断 firstThreadId2 的分数(超时时间戳)是不是小于当前时间戳:
第二、三、四部分都不满足条件。
Thread3 最后也会来到这里:
redisson_lock_queue:{anyLock}
中获取最后一个线程;60000*5
,在最后一个线程的超时时间上加上 300000 以及当前时间戳,就是 Thread3 的超时时间戳。本文主要总结了公平锁的加锁逻辑,这里涉及到比较多的 Redis 操作,做一下简要总结:
需要理解的就是这里会额外添加一个等待队列,以及有序集合。
对照着 Java 公平锁源码阅读,理解起来效果更好。
- <End /> -