精尽 Redisson 源码分析 —— 可重入分布式锁 ReentrantLock
1. 概述
在 Redisson 中，提供了 8 种分布锁的实现，具体我们可以在 《Redisson 文档 —— 分布式锁和同步器》 中看到。绝大数情况下，我们使用可重入锁（Reentrant Lock）就够了，对应到就是 org.redisson.RedissonLock 类，具体的使用示例可以看看 《芋道 Spring Boot Redis 入门》 的「6.2 Redis 分布式锁」小节 。
在 《精尽 Redis 面试题》 的问题中，我们在聊到“如何使用 Redis 实现分布式锁？”这个题目中，提到了需要考虑的 7 个方面，这里我们再来重复看下：
-
1、正确的获得锁
set 指令附带 nx 参数，保证有且只有一个进程获得到。
-
2、正确的释放锁
使用 Lua 脚本，比对锁持有的是不是自己。如果是，则进行删除来释放。
-
3、超时的自动释放锁
set 指令附带 expire 参数，通过过期机制来实现超时释放。
-
4、未获得到锁的等待机制
sleep 或者基于 Redis 的订阅 Pub/Sub 机制。
一些业务场景，可能需要支持获得不到锁，直接返回 false ，不等待。
-
5、【可选】锁的重入性
通过 ThreadLocal 记录是第几次获得相同的锁。
1）有且第一次计数为 1 && 获得锁时，才向 Redis 发起获得锁的操作。
2）有且计数为 0 && 释放锁时，才向 Redis 发起释放锁的操作。 -
6、锁超时的处理
一般情况下，可以考虑告警 + 后台线程自动续锁的超时时间。通过这样的机制，保证有且仅有一个线程，正在持有锁。
-
7、Redis 分布式锁丢失问题
具体看「方案二：Redlock」。
RedissonLock 实现了前 6 点，而第 7 点需要通过 org.redisson.RedissonRedLock 来实现，这个话题，我们后面在聊。
2. 整体一览
我们来看看 Redisson 锁相关的整体类图，如下：
RLock 接口
- org.redisson.api.RLockAsync ，定义了异步操作的接口。
- org.redisson.api.RLock ，继承 RLockAsync 的基础上，定义了同步操作的接口。比较有意思的是，RLock 同时实现继承 JDK 的
java.util.concurrent.locks.Lock接口，从而符合 Java 的 Lock 的标准。 - 本文的主角 RedissonLock ，实现 RLock 接口，提供可重入的分布式锁实现。
RLockAsync 和 RLock 定义的接口，差别就在于同步和异步，所以我们就只看看 RLock 接口。代码如下：
String getName(); // 锁定相关的接口方法，还有部分在 Lock 接口上 void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException; void lock(long leaseTime, TimeUnit unit); boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException; // 解锁相关的接口方法，还有部分在 Lock 接口上 boolean forceUnlock(); // 其它非关键方法 boolean isLocked(); boolean isHeldByThread(long threadId); boolean isHeldByCurrentThread(); int getHoldCount(); long remainTimeToLive(); |
3. Lua 脚本
在我们看具体的代码实现，我们先来看核心的使用到的 Lua 脚本，方便我们后续更好的理解 RedissonLock 的实现。
3.1 tryLockInnerAsync
#tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand 方法，实现加锁逻辑，并且支持可重入性。代码如下：
FROM 《慢谈 Redis 实现分布式锁 以及 Redisson 源码解析》
加锁流程图
// RedissonLock.java 1: |
-
<2>处，根据传入的leaseTime+unit参数，设置到internalLockLeaseTime属性上，表示锁的时长。代码如下：// RedissonLock.java /** * 锁的时长 */ protected long internalLockLeaseTime; public RedissonLock(CommandAsyncExecutor commandExecutor, String name) { // ... 省略其它代码 this.internalLockLeaseTime = commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(); }- 默认情况下，
internalLockLeaseTime属性，使用 Lock 的 WatchDog 的超时时长30 * 1000毫秒。默认的值，当且仅当我们未显示传入锁的时长时，才有用。例如说，稍后我们会看到的#lock()等等方法中。 - 有一点，我们要特别注意，
internalLockLeaseTime是 RedissonLock 的成员变量，并且也未声明volatile修饰，所以跨线程使用同一个 RedissonLock 对象，可能会存在internalLockLeaseTime读取不到最新值的情况。
- 默认情况下，
-
还是熟悉的配方，通过 Lua 脚本实现。具体传入的参数，朋友看下第 16 和 17 行的代码，对应的
KEYS和ARGV。KEYS[1]：调用#getName()方法获得分布式锁的名字。稍后，我们会看到分布式锁在 Redis 使用是以KEYS[1]分布式锁为 KEY ，VALUE 为 HASH 类型。ARGV[1]：锁的时长。-
ARGV[2]：调用#getLockName(threadId)方法，获得的锁名。该名字，用于表示该分布式锁正在被哪个进程的线程所持有。代码如下：// RedissonLock.java /** * ID ，就是 {@link ConnectionManager#getId()} */ final String id; protected String getLockName(long threadId) { return id + ":" + threadId; }- 可能描述看起来不是很好理解，我们来看一个获取到分布式锁的示例：
分布式锁的示例
- 可能描述看起来不是很好理解，我们来看一个获取到分布式锁的示例：
- 第 4 至 15 行：Lua 脚本，一共分成 3 种情况，已经添加了完整的注释。
不同于我们在市面上看到的 Redis 通过 SET 命令带上 NX 和 EXPIRE 的方式实现获得分布式锁，RedissonLock 提供重入性，所以需要 Lua 脚本来实现。当然，实际上，也可以通过 ThreadLocal 来实现重入性的技术。
3.2 unlockInnerAsync
#unlockInnerAsync(long threadId) 方法，实现解锁逻辑，并且支持可重入性。代码如下：
FROM 《慢谈 Redis 实现分布式锁 以及 Redisson 源码解析》
解锁流程图
// RedissonLock.java 1: protected RFuture |
-
具体传入的参数，朋友看下第 16 和 17 行的代码，对应的
KEYS和ARGV。KEYS[1]：调用#getName()方法获得分布式锁的名字。-
KEYS[2]：调用#getChannelName()方法，该分布式锁对应的 Channel 名。因为 RedissonLock 释放锁时，会通过该 Channel 来 Publish 一条消息，通知其它可能在阻塞等待这条消息的客户端。代码如下：// RedissonLock.java String getChannelName() { return prefixName("redisson_lock__channel", getName()); }- 通过 Redis Pub/Sub 机制，实现未获得到锁的等待机制。
- 每个分布式锁，对应一个其独有的 Channel 。
ARGV[1]：解锁消息 LockPubSub.UNLOCK_MESSAGE 。通过收到这条消息，其它等待锁的客户端，会重新发起获得锁的请求。具体的，我们在下文来一起瞅瞅。ARGV[2]：锁的时长。ARGV[3]：调用#getLockName(threadId)方法，获得的锁名。
- 第 3 至 15 行：Lua 脚本，还是分成 3 种情况。
不同于我们在市面上看到的 Redis 通过 Lua 脚本的方式实现释放分布式锁，一共有 2 点：
- 1、要实现可重入性，所以只有在计数为 0 时，才会真正释放锁。
- 2、要实现客户端的等待通知，所以在释放锁时，Publish 一条释放锁的消息。
3.3 forceUnlockAsync
#forceUnlockAsync() 方法，实现强制解锁逻辑。代码如下：
// RedissonLock.java @Override public RFuture |
- 比较简单，分成 2 种情况。
代码处理的比较细致，Redis DEL 成功，才 PUBLISH 发布释放锁的消息，避免错误通知客户端。
3.4 renewExpirationAsync
#renewExpirationAsync(long threadId) 方法，实现续锁逻辑。
我们先来看下 《Redisson 文档 —— 分布式锁和同步器》 ，有一段奇怪的说明：
RLock lock = redisson.getLock("anyLock");
// 最常见的使用方法
lock.lock();
|
大家都知道，如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改 Config.lockWatchdogTimeout 来另行指定。
在使用 RedissonLock#lock() 方法，我们要求持续持有锁，直到手动释放。但是实际上，我们有一个隐藏条件，如果 Java 进程挂掉时，需要自动释放。那么，如果实现 RedissonLock#lock() 时，设置过期 Redis 为无限大，或者不过期都不合适。那么 RedissonLock 是怎么实现的呢？RedissonLock 先获得一个 internalLockLeaseTime 的分布式锁，然后每 internalLockLeaseTime / 3 时间，定时调用 #renewExpirationAsync(long threadId) 方法，进行续租。这样，在 Java 进程异常 Crash 掉后，能够保证最多 internalLockLeaseTime 时间后，分布式锁自动释放。
略骚略巧妙~不过为了实现这样的功能，RedissonLock 的整体逻辑，又复杂了一丢丢。
下面，还是先让我们看下具体的 #renewExpirationAsync(long threadId) 方法的代码，如下：
// RedissonLock.java protected RFuture |
- 比较简单，分成 2 种情况。
至此，我们看完了 Lua 脚本部分，其实基本也大体知道 RedissonLock 是如何实现加锁、接锁的逻辑。但是，复杂的逻辑，还在下面。
4. LockPubSub
在开始研究真正的加锁和解锁的调用之前，我们先看看和其相关的客户端订阅解锁消息，从而实现在持有锁的客户端释放锁时，等待锁的客户端能够快速的去调用加锁逻辑。
org.redisson.pubsub.LockPubSub ，继承 PublishSubscribe 抽象类，实现 Lock 相关消息的订阅。代码如下：
// LockPubSub.java public class LockPubSub extends PublishSubscribe |
-
在
#createEntry(RPromise方法，会创建 org.redisson.RedissonLockEntry 对象。代码如下：newPromise) // RedissonLockEntry.java public class RedissonLockEntry implements PubSubEntry
{ /** * 计数器 * * 每次发起订阅，则计数器 + 1 * 每次取消订阅，则计数器 - 1 。当减少到 0 时，才正常取消订阅。 */ private int counter; /** * 信号量，用于实现 RedissonLock 阻塞等待的通知 */ private final Semaphore latch; private final RPromise promise; /** * 监听器们 */ private final ConcurrentLinkedQueue listeners = new ConcurrentLinkedQueue (); public RedissonLockEntry(RPromise promise) { super(); this.latch = new Semaphore(0); this.promise = promise; } @Override public void aquire() { counter++; } @Override public int release() { return --counter; } @Override public RPromise getPromise() { return promise; } public void addListener(Runnable listener) { listeners.add(listener); } public boolean removeListener(Runnable listener) { return listeners.remove(listener); } public ConcurrentLinkedQueue getListeners() { return listeners; } public Semaphore getLatch() { return latch; } } - 虽然代码比较多，我们重点来看
latch和listeners属性。 latch属性：信号量，用于实现 RedissonLock 阻塞等待的通知。在我们下面看到同步加锁的逻辑，会看到通过它来实现阻塞等待。listeners属性：监听器，实现订阅到锁的释放消息，从而再次发起获得锁。当然，这里的 Runnable 对象肯定无法体现，具体我们后面看看#tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture或者subscribeFuture, RPromise result, long currentThreadId) #lockAsync(long leaseTime, TimeUnit unit, RFuture方法，就可以看到方法内部会创建具体的 Runnable 实现类，实现再次发起获得锁的逻辑。subscribeFuture, RPromise result, long currentThreadId)
- 虽然代码比较多，我们重点来看
- 在
#onMessage(RedissonLockEntry value, Long message)方法中，在接收到释放锁的消息后，会执行listeners的回调，以及latch的时候放。
当然，单单看 LockPubSub 类。LockPubSub 更多的是实现了锁释放消息的监听，以及回调监听器，释放信号量。真正的逻辑，还是要看监听器的逻辑，以及 RedissonLock 是怎么实现信号量的。
另外，在 RedissonLock 中，提供如下几个方法，发起和取消订阅。代码如下：
// RedissonLock.java
/**
* Sub Entry 名字
*/
final String entryName;
protected final LockPubSub pubSub;
public RedissonLock(CommandAsyncExecutor commandExecutor, String name) {
// ... 省略其他无关
this.entryName = id + ":" + name;
this.pubSub = commandExecutor.getConnectionManager().getSubscribeService().getLockPubSub();
}
/**
* 获得线程对应的 RedissonLockEntry 对象
*
* @param threadId 线程编号
* @return RedissonLockEntry 对象
*/
protected RedissonLockEntry getEntry(long threadId) {
return pubSub.getEntry(getEntryName());
}
/**
* 异步发起订阅
*
* @param threadId 线程编号
* @return RFuture 对象
*/
protected RFuture |
5. tryLockAsync
#tryLockAsync(long waitTime, TimeUnit unit) 方法，异步加锁，并返回是否成功。代码如下：
// RedissonLock.java @Override public RFuture |
- 最终都调用
#tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long currentThreadId)方法，真正实现异步加锁的逻辑。
#tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long currentThreadId) 方法，代码如下：
// RedissonLock.java 1: @Override 2: public RFuture |
- 整体逻辑是，获得分布锁。如果获取失败，则发起 Redis Pub/Sub 订阅，等待释放锁的消息，从而再次发起获得分布式锁。
- 第 11 行：调用
#tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId)方法，执行异步获得锁。 - 第 13 至 17 行：如果发生异常，则通过
result通知异常。 - 第 19 至 26 行：如果
ttl为空，说明获得到锁了，则通过result通知获得锁成功。这里，在第 23 至 24 行有个小细节，看下注释。 - 第 41 行：声明
futureRef变量，用于设置第 65 至 81 行创建的定时任务。 -
第 65 至 82 行：如果创建 SUBSCRIBE 订阅的 Future
subscribeFuture未完成，创建定时任务 FuturescheduledFuture。因为subscribeFuture是异步的，而存在一个情况，可能subscribeFuture未完成时，等待获得锁已经超时，所以通过scheduledFuture来实现超时通知。- 第 80 行：记录
futureRef为scheduledFuture。 - 第 71 行：兜底判断
subscribeFuture未完成。 - 第 73 行：进行取消
subscribeFuture。 -
第 75 行：调用
#trySuccessFalse(long currentThreadId, RPromise方法，通知获得锁失败。代码如下：result) // RedissonLock.java protected RFuture
acquireFailedAsync(long threadId) { return RedissonPromise.newSucceededFuture(null); } private void trySuccessFalse(long currentThreadId, RPromise result) { acquireFailedAsync(currentThreadId).onComplete((res, e) -> { if (e == null) { // 通知获得锁失败 result.trySuccess(false); } else { // 通知异常 result.tryFailure(e); } }); } - x
- 第 80 行：记录
-
第 43 至 63 行：创建 SUBSCRIBE 订阅的 Future
subscribeFuture。通过订阅释放锁的消息，从而实现等待锁释放的客户端，快速抢占加锁。- 第 46 至 50 行：如果发生异常，则通过
result通知异常。 - 第 52 至 55 行：如果创建定时任务 Future
scheduledFuture，则进行取消。 - 第 57 至 59 行：减掉已经等待的时间。
-
第 62 行：调用
#tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture方法，再次执行异步获得锁。详细解析，见 「5.2 更强的 tryLockAsync」 小节。subscribeFuture, RPromise result, long currentThreadId
- 第 46 至 50 行：如果发生异常，则通过
感叹，想要写好全异步的代码，实际是非常困难的，Spring Webflux 反应式框架，想要推广在编写业务逻辑，基本可能性是为零。当然，Webflux 乃至反应式编程，更加适合推广在基础组件中。
5.1 tryAcquireAsync
#tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId) 方法，执行异步获得锁。代码如下：
// RedissonLock.java private |
- 一共分成两种情况，是否锁有时长。
<1>处，leaseTime != -1，意味着锁设置了时长，则调用 「3.1 #tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommandcommand)」 方法，直接获得分布式锁。 <2>处，锁未设置了时长，所以先调用 「3.1 #tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommandcommand)」 方法，获得 Lock WatchDog 的锁超时时长的分布式锁，然后在回调中，再调用 #scheduleExpirationRenewal(long threadId)方法，创建定时任务，定时调用 「3.4 renewExpirationAsync」 续锁。详细解析，见 TODO 。
5.2 更强的 tryLockAsync
#tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture 方法，更强的异步加锁。主要强在 2 点：
- 1、增加监听锁释放的消息的监听器，从而实现等待锁的客户端快速抢占锁的逻辑。
- 2、增加锁超时自动释放，没有锁释放消息的处理。
整体代码如下：
// RedissonLock.java 1: private void tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture |
- 第 2 至 46 行：和 「5. tryLockAsync」 基本一致，就不重复哔哔了。
- 第 52 行：调用
#getEntry(long threadId)方法，获得当前线程对应的 RedissonLockEntry 对象。 - 第 53 至 55 行：尝试获得
entry中的信号量，如果获得成功，说明 SUBSCRIBE 已经收到释放锁的消息，则调用 「5.2 ##tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuturesubscribeFuture, RPromise result, long currentThreadId)」 方法，直接立马再次去获得锁。 - 第 58 行：创建 AtomicBoolean 变量
executed，用于标记下面创建的listener是否执行。 - 第 60 行：声明
futureRef变量，用于设置第 87 至 104 行创建的定时任务。因为极端情况下，可能不存在释放锁的消息，例如说锁自动超时释放，所以需要改定时任务，在获得到锁的超时后，主动去抢下。- 第 82 至 85 行：计算定时任务的延迟时间时间。如果剩余时间小于锁的超时时间，则使用剩余时间。
- 第 87 行：通过
executed变量，判断listener未执行。 - 第 103 行： 记录
futureRef为scheduledFuture。 - 第 92 行：移除
listener从 RedissonLockEntry 中。避免，可能存在的并发执行。 - 第 98 行：调用 「5.2 ##tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture
subscribeFuture, RPromise result, long currentThreadId)」 方法，再次去获得锁。 - 这个定时任务，真的处理的是细节中的细节。之前思考获得分布式失败客户端的等待通知，只考虑了 Redis Pub/Sub 机制来实现，没有想到如果没有 PUBLISH 消息的场景。这块的逻辑，算是看 RedissonLock 最大的收获吧。
- 第 62 至 79 行：创建监听器
listener，用于在 RedissonLockEntry 的回调，就是我们看到的 PublishSubscribe 监听到释放锁的消息，进行回调。- 第 79 行：添加
listener到 RedissonLockEntry 中。 - 第 65 行：通过
executed标记已经执行。 - 第 66 至 69 行：如果有定时任务的 Future ，则进行取消。
- 第 71 至 74 行：减掉已经等待的时间。
- 第 76 行：调用 「5.2 ##tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture
subscribeFuture, RPromise result, long currentThreadId)」 方法，再次去获得锁。
- 第 79 行：添加
至此，RedissonLock 加锁的逻辑我们已经全部看完。
5.3 遗漏的 tryLockAsync
还有两个重载的 #tryLockAsync(...) 方法，它们是未设置锁定时长的两个。代码如下：
// RedissonLock.java @Override public RFuture |
- 最终都调用
#tryAcquireOnceAsync(long leaseTime, TimeUnit unit, long threadId)方法，真正实现异步加锁的逻辑。
#tryAcquireOnceAsync(long leaseTime, TimeUnit unit, long threadId) 方法，真正实现异步加锁的逻辑。代码如下：
// RedissonLock.java private RFuture |
- 看到这个方法，是不是发现很熟悉，和 「5.1 tryAcquireAsync」 基本一模一样。差别在于它的返回的结果是
RFuture。 - 有一点要特别注意，因为本小节我们看到的两个
#tryLockAsync(...)方法，是尝试去加锁。如果加锁失败，则返回false即可，所以不会像我们在 「5.1 tryLockAsync」 方法，无限重试直到等待超时（超过waitTime）。
6. tryLock
#tryLock(long waitTime, long leaseTime, TimeUnit unit) 方法，同步加锁，并返回是否成功。。代码如下：
// RedissonLock.java
@Override
public boolean tryLock(long waitTime, TimeUnit unit) throws InterruptedException {
return tryLock(waitTime, -1, unit);
}
1: @Override
2: public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
3: long time = unit.toMillis(waitTime);
4: long current = System.currentTimeMillis();
5: long threadId = Thread.currentThread().getId();
6: // 同步获加锁
7: Long ttl = tryAcquire(leaseTime, unit, threadId);
8: // lock acquired
9: // 加锁成功，直接返回 true 加锁成功
10: if (ttl == null) {
11: return true;
12: }
13:
14: // 减掉已经等待的时间
15: time -= System.currentTimeMillis() - current;
16: // 如果无剩余等待的时间，则返回 false 加锁失败
17: if (time <= 0) {
18: acquireFailed(threadId);
19: return false;
20: }
21:
22: // 记录新的当前时间
23: current = System.currentTimeMillis();
24: // 创建 SUBSCRIBE 订阅的 Future
25: RFuture |
-
第 7 行：调用
#tryAcquire(long leaseTime, TimeUnit unit, long threadId)方法，同步加锁。代码如下：// RedissonLock.java private Long tryAcquire(long leaseTime, TimeUnit unit, long threadId) { return get(tryAcquireAsync(leaseTime, unit, threadId)); }- 该方法内部，调用的就是 「5.1 #tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId)」 方法。
-
第 8 至 12 行：加锁成功，直接返回
true加锁成功。 - 第 15 行：减掉已经等待的时间。
- 第 17 至 20 行：如果无剩余等待的时间，则返回
false加锁失败。 - 第 25 行：调用
#subscribe(long threadId)方法，创建 SUBSCRIBE 订阅的 FuturesubscribeFuture。 - 【重要差异点】第 27 至 41 行：调用
#await(subscribeFuture, time, TimeUnit.MILLISECONDS)方法，阻塞等待订阅发起成功，因为subscribeFuture是异步的，需要这一步转同步。如果发生超时，则就会进入第 28 至 37 行的取消逻辑，并在第 38 至 40 行返回false加锁失败。 - 第 52 至 89 行：反复重试，直到成功加锁返回
true，或者超时返回false。- 第 54 至 73 行：重试一波第 6 至 20 行的逻辑。
- 【重要差异点】第 75 至 80 行：通过 RedissonLockEntry 的信号量，阻塞等待锁的释放消息，或者
ttl/time超时（例如说，锁的自动超时释放）。- 相比 「5.2 #tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture
subscribeFuture, RPromise result, long currentThreadId)」 方法，它把信号量的等待和定时任务的等待融合在一起了。 - 等待完成后，如果无剩余时间，在第 82 至 88 行的逻辑中，返回
false加锁失败。 - 等待完成后，如果有剩余时间，在第 56 行：获得重新同步获得锁。
- 相比 「5.2 #tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture
- 第 92 行：调用
#unsubscribe(RFuture方法，小细节，需要最终取消 SUBSCRIBE 订阅。future, long threadId)
7. lockAsync
#lockAsync(long leaseTime, TimeUnit unit, long currentThreadId) 方法，异步加锁，无需返回是否成功。代码如下：
// RedissonLock.java
@Override
public RFuture |
- 第 6 行：调用 「5.1 #tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId)」 方法，执行异步获得锁。
- 第 7 至 35 行：又是熟悉的配方，在回调中，处理响应的加锁结果。差异就在第 34 行，见 「7.1 更强的 lockAsync」 的详细解析。
7.1 更强的 lockAsync
实际上，#lockAsync(long leaseTime, TimeUnit unit, RFuture 方法，和 「5.2 更强的 tryLockAsync」 是基本一致的。那么为什么不直接重用呢？注意，这个方法不需要考虑等待超时，有一种“劳资有钱，必须拿到锁”。
代码如下：
// RedissonLock.java private void lockAsync(long leaseTime, TimeUnit unit, RFuture |
- 更加熟悉的配方，全程无需处理等待锁超时的逻辑。
8. lock
#tryLock(long waitTime, long leaseTime, TimeUnit unit) 方法，同步加锁，无需返回是否成功。代码如下：
// RedissonLock.java
@Override
public void lock() {
try {
lock(-1, null, false);
} catch (InterruptedException e) {
throw new IllegalStateException();
}
}
@Override
public void lock(long leaseTime, TimeUnit unit) {
try {
lock(leaseTime, unit, false);
} catch (InterruptedException e) {
throw new IllegalStateException();
}
}
@Override
public void lockInterruptibly() throws InterruptedException {
lock(-1, null, true);
}
@Override
public void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException {
lock(leaseTime, unit, true);
}
1: private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
2: long threadId = Thread.currentThread().getId();
3: // 同步获加锁
4: Long ttl = tryAcquire(leaseTime, unit, threadId);
5: // lock acquired
6: // 加锁成功，直接返回
7: if (ttl == null) {
8: return;
9: }
10:
11: // 创建 SUBSCRIBE 订阅的 Future
12: RFuture |
- 太过熟悉，就不哔哔了。
至此，加锁的几种组合排列，我们就已经看完了。 是不是有一种加锁的 Lua 脚本蛮简单的，调用 Lua 脚本实现阻塞等待的逻辑，细节还是蛮多的。
9. unlockAsync
#unlockAsync(long threadId) 方法，异步解锁。代码如下：
// RedissonLock.java
@Override
public RFuture |
- 第 7 行：调用 3.2 #unlockAsync(long threadId) 方法，执行解锁逻辑。
- 第 10 至 15 行：如果发生异常，并通过
result通知异常。 - 第 17 至 23 行：解锁的线程不对，则创建 IllegalMonitorStateException 异常，并通过
result通知异常。 这里，仔细回忆下解锁 Lua 脚本的返回值。嘿嘿。 - 第 26 行：调用
#cancelExpirationRenewal(long threadId)方法，取消定期过期。TODO - 第 29 行：通知
result解锁成功。
10. unlock
#unlock() 方法，同步解锁。代码如下：
// RedissonLock.java
@Override
public void unlock() {
try {
get(unlockAsync(Thread.currentThread().getId()));
} catch (RedisException e) {
if (e.getCause() instanceof IllegalMonitorStateException) {
throw (IllegalMonitorStateException) e.getCause();
} else {
throw e;
}
}
}
|
- 简单，基于 「9. #unlockAsync(long threadId)」 方法实现。
11. forceUnlock
#forceUnlock() 方法，强制解锁。代码如下：
// RedissonLock.java
@Override
public boolean forceUnlock() { // 同步
return get(forceUnlockAsync());
}
@Override
public RFuture |
- 无论是同步还是异步的强制解锁，都是基于 「3.3 #forceUnlockAsync()」 方法实现。
12. ExpirationEntry
本小节，我们来看看在 「3.4 renewExpirationAsync」 中，提到的续锁的功能。
首先，我们来看看 ExpirationEntry 类。它是 RedissonLock 的内部类，记录续租任务的信息。代码如下：
// RedissonLock.java
public static class ExpirationEntry {
/**
* 线程与计数器的映射
*
* KEY：线程编号
* VALUE：计数
*/
private final Map |
- 可能粗略这么一看，有种然并卵的感觉，不要着急。我们下面接着看。
- 在 RedissonLock 的类中，有个
EXPIRATION_RENEWAL_MAP静态属性，如下：// RedissonLock.java /** * ExpirationEntry 的映射 * * key ：{@link #entryName} */ private static final ConcurrentMap
12.1 scheduleExpirationRenewal
#scheduleExpirationRenewal() 方法，发起续锁的定时任务。代码如下：
// RedissonLock.java
1: private void scheduleExpirationRenewal(long threadId) {
2: // 创建 ExpirationEntry 对象
3: ExpirationEntry entry = new ExpirationEntry();
4: // 添加到 EXPIRATION_RENEWAL_MAP 中
5: ExpirationEntry oldEntry = EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);
6: // 添加线程编号到 ExpirationEntry 中
7: if (oldEntry != null) {
8: oldEntry.addThreadId(threadId);
9: } else {
10: entry.addThreadId(threadId);
11: // 创建定时任务，用于续锁
12: renewExpiration();
13: }
14: }
15:
16: private void renewExpiration() {
17: // 获得 ExpirationEntry 队形，从 EXPIRATION_RENEWAL_MAP 中
18: ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName());
19: if (ee == null) { // 如果不存在，返回
20: return;
21: }
22:
23: // 创建 Timeout 定时任务，实现定时续锁
24: Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
25:
26: @Override
27: public void run(Timeout timeout) throws Exception {
28: // 获得 ExpirationEntry 对象
29: ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
30: if (ent == null) { // 如果不存在，返回
31: return;
32: }
33: // 获得 threadId 编号
34: Long threadId = ent.getFirstThreadId();
35: if (threadId == null) { // 如果不存在，则返回
36: return;
37: }
38:
39: // 执行续锁
40: RFuture |
- 第 2 至 10 行：创建 ExpirationEntry 对象，并添加到
EXPIRATION_RENEWAL_MAP中，之后添加线程编号到 ExpirationEntry 中。 - 第 12 行：当且仅当
entryName对应的 ExpirationEntry 对象首次创建时，才会调用#renewExpiration()方法，创建定时任务，用于续锁。- 【重要】第 23 至 56 行：创建 Timeout 定时任务，定时每
internalLockLeaseTime / 3秒执行一次续锁。 - 第 40 行：会调用 「3.4 #renewExpirationAsync(long threadId) 方法」 方法，执行续锁。
- 第 42 至 46 行：如果发生异常，则打印异常日志，并返回。此时，就不会在定时续租了。
- 【重要】第 48 至 52 行：如果续锁成功，则调用
#renewExpiration()方法，重新发起定时任务。
- 【重要】第 23 至 56 行：创建 Timeout 定时任务，定时每
- 第 59 行：设置定时任务到 ExpirationEntry 中。
12.2 cancelExpirationRenewal
#cancelExpirationRenewal(Long threadId) 方法，取消定时任务。代码如下：
// RedissonLock.java
void cancelExpirationRenewal(Long threadId) {
// 获得 ExpirationEntry 对象
ExpirationEntry task = EXPIRATION_RENEWAL_MAP.get(getEntryName());
if (task == null) { // 如果不存在，返回
return;
}
// 从 ExpirationEntry 中，移除线程编号
if (threadId != null) {
task.removeThreadId(threadId);
}
// 如果 ExpirationEntry 的所有线程被清空
if (threadId == null || task.hasNoThreads()) {
// 取消定时任务
task.getTimeout().cancel();
// 从 EXPIRATION_RENEWAL_MAP 中移除
EXPIRATION_RENEWAL_MAP.remove(getEntryName());
}
}
|
- 当且仅当
entryName对应的EXPIRATION_RENEWAL_MAP的 ExpirationEntry 对象，所有线程都被移除后，会取消定时任务。
13. 其它方法
代码如下：
// RedissonLock.java
@Override
public Condition newCondition() {
// TODO implement
throw new UnsupportedOperationException();
}
@Override
public boolean isLocked() {
return isExists();
}
@Override
public RFuture |