愛在花開的季節 发表于 2024-8-3 14:25:04

【源码阅读】Redisson lock源码

目录
底层原理
加锁机制
锁互斥机制
可重入锁机制
总结 
Redisson 加锁非常简单,还支持 redis 单实例、redis 哨兵、redis cluster、redis master-slave 等各种部署架构
RLock lock = redisson.getLock("cyk-test");
lock.lock();
lock.unlock(); 底层原理


https://img-blog.csdnimg.cn/img_convert/9552743dab48ad95d19590def7117801.webp?x-oss-process=image/format,png
加锁机制

废话不多说,直接看源码,下面的代码先不看,先看 tryAcquire 是怎样获取锁的
private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
      long threadId = Thread.currentThread().getId();
      Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
      // lock acquired
      if (ttl == null) {
            return;
      }

      CompletableFuture<RedissonLockEntry> future = subscribe(threadId);
      pubSub.timeout(future);
      RedissonLockEntry entry;
      if (interruptibly) {
            entry = commandExecutor.getInterrupted(future);
      } else {
            entry = commandExecutor.get(future);
      }
      ...
} 查看 tryAcquire 方法,点进去看发现调用了 tryAcquireAsync0 方法,这里 RFuture 继承自 java.util.concurrent.Future,表现这是一个异步的使命,get 方法会同步获取效果
private Long tryAcquire(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    return get(tryAcquireAsync0(waitTime, leaseTime, unit, threadId));
}

private RFuture<Long> tryAcquireAsync0(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    return getServiceManager().execute(() -> tryAcquireAsync(waitTime, leaseTime, unit, threadId));
} 查看 tryAcquireAsync 方法
    private RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
      RFuture<Long> ttlRemainingFuture;
      if (leaseTime > 0) {
            ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
      } else {
            ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime,
                  TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
      }
      ...
    } 查看 tryLockInnerAsync 方法
    <T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
      return commandExecutor.syncedEval(getRawName(), LongCodec.INSTANCE, command,
                "if ((redis.call('exists', KEYS) == 0) " +
                            "or (redis.call('hexists', KEYS, ARGV) == 1)) then " +
                        "redis.call('hincrby', KEYS, ARGV, 1); " +
                        "redis.call('pexpire', KEYS, ARGV); " +
                        "return nil; " +
                  "end; " +
                  "return redis.call('pttl', KEYS);",
                Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
    } 这是一段加锁的 lua 脚本,用于包管原子性,参数解释如下:


[*] KEYS 表现加锁的 key
[*] ARGV 表现锁 key 的默认超时时间
[*] ARGV 表现加锁的客户端 ID,由 UUID:线程 ID 构成
客户端在第一次加锁完成,会设置一个 key 为客户端 ID,value 为加锁次数的 hash 数据结构:

https://img-blog.csdnimg.cn/img_convert/847d97ca21dc5151baaef324a9e7dae7.webp?x-oss-process=image/format,png
现在知道了内部方法的逻辑,往回倒一步,重点看我加在代码中的注释
    private RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
      RFuture<Long> ttlRemainingFuture;
      if (leaseTime > 0) {
            ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
      } else {
            ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime,
                  TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
      }

      // 这里是定义了加锁Lua脚本的异步任务,通过CompletableFuture编排
      CompletionStage<Long> s = handleNoSync(threadId, ttlRemainingFuture);
      ttlRemainingFuture = new CompletableFutureWrapper<>(s);

      // 这个f依赖ttlRemainingFuture的结果,如果入参的leaseTime<=0会触发看门狗机制
      // 否则按照设置的过期时间来过期
      CompletionStage<Long> f = ttlRemainingFuture.thenApply(ttlRemaining -> {
            // lock acquired
            if (ttlRemaining == null) {
                if (leaseTime > 0) {
                  internalLockLeaseTime = unit.toMillis(leaseTime);
                } else {
                  scheduleExpirationRenewal(threadId);
                }
            }
            return ttlRemaining;
      });

      // 返回编排好的CompletableFuture
      return new CompletableFutureWrapper<>(f);
    } 把 RFuture 返回以后,就到了 get 方法阻塞获取方法这里
private Long tryAcquire(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    return get(tryAcquireAsync0(waitTime, leaseTime, unit, threadId));
}

private RFuture<Long> tryAcquireAsync0(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    return getServiceManager().execute(() -> tryAcquireAsync(waitTime, leaseTime, unit, threadId));
} 最后回到了这里
    private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
      long threadId = Thread.currentThread().getId();
      Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
      // lock acquired
      if (ttl == null) {
            return;
      }

      // 这里的 subscribe 就是 Redis 订阅解锁的 lua 脚本中的 publish
      CompletableFuture<RedissonLockEntry> future = subscribe(threadId);
      pubSub.timeout(future);
      RedissonLockEntry entry;
      if (interruptibly) {
            entry = commandExecutor.getInterrupted(future);
      } else {
            entry = commandExecutor.get(future);
      }
      ...
    } 接着看下面循环获取锁的逻辑
      try {
           while (true) {
                // 自旋尝试获取锁
               ttl = tryAcquire(-1, leaseTime, unit, threadId);
               // 看Lua脚本,ttl为null说明锁获取到了
               if (ttl == null) {
                   break;
             }

               // waiting for message
               if (ttl >= 0) {
                   try {
                       // 注意这里的tryAcquire和之前的tryAcquire不是同一个东西,这里是信号量的tryAcquire
                       // entry.getLatch()这里返回的是信号量,释放锁的代码会释放一个许可
                        // 如果没有可用的许可,会一直休眠直到超时时间 ttl ms
                       entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                 } catch (InterruptedException e) {
                       if (interruptibly) {
                           throw e;
                     }
                       entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                 }
             } else {
                   // 当 key 存在但没有设置剩余生存时间时,pttl返回 -1,会走到这个逻辑
                  // 我感觉正常流程走不到这个逻辑,因为当前线程无非是看到锁存在或者不存在
                  // 看到锁不存在等于加锁成功了,因为Lua脚本是原子性的
                  // 看到锁存在,默认也给了超时时间
                   // 这里就没有设置超时时间,一直等释放锁的许可
                   if (interruptibly) {
                       entry.getLatch().acquire();
                 } else {
                       entry.getLatch().acquireUninterruptibly();
                 }
             }
         }
     } finally {
           unsubscribe(entry, threadId);
     } 这里计划的奇妙之处就在于利用了消息订阅、信号量的机制,它不是无休止的盲等机制,也避免了不断的重试,而是检测到锁被释放才去尝试重新获取,这对 CPU 十分的友爱
锁互斥机制

此时如果客户端 2 来尝试加锁,同样走进 RedissonLock#lock 方法,会咋样呢?第一个 if 判断会实行 exists myLock,发现 myLock 这个锁 key 已经存在了。接着第二个 if 判断,判断一下,myLock 锁 key 的 hash 数据结构中,对应客户端 2 的 ID 的 key 的 value 为 1,也没有。最终会获取到 pttl myLock 返回的锁 key 的剩余生存时间,进入 while 循环,不停的尝试加锁
可重入锁机制

那如果客户端1都已经持有了这把锁了,效果可重入的加锁会怎么样呢?

https://img-blog.csdnimg.cn/img_convert/91e41a693d7863f1cf6396ebee0522ab.webp?x-oss-process=image/format,png
此时会实行可重入加锁的逻辑,走第二个 if 逻辑,对客户端 1 的加锁次数累加 1,此时 myLock 数据结构变为下面这样:

https://img-blog.csdnimg.cn/img_convert/284bcfd5dc9e82ea23f30954b860df8a.webp?x-oss-process=image/format,png
总结 


https://img-blog.csdnimg.cn/img_convert/aa82988afaa0ae1a0f8a89b285b178c7.png

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: 【源码阅读】Redisson lock源码