面试时遇到『看门狗』脖子上挂着『时间轮』，我就问你怕不怕？

有读者来问了：老哥，看门狗介绍一下呗。面试的时候被问到了，没有回答上来。

听到这个问题我脑海里首先浮现出了几个问题：

你面试被问到，没有答上来，然后呢？
面试结束之后你没有进行面试的复盘吗？
对于自己没有回答上来的问题，没有去进行探索吗？

甚至你都忘记了当时你的面试题，只是看到我文章的时候，突然想起：哦，这题我之前遇到过，没有解决。

这个方式是不对的，朋友。

一次面试是一场技术的交锋，所以面试之后的复盘非常非常的重要，面试结束后的第一件事情就应该是回顾整个面试过程，看看在整个面试的过程中，哪些地方是自己知道但是没有说清楚的，哪些地方是自己应该知道但是确实不知道，需要去提升的。

然后立刻、马上、当即在手机标签或者随身笔记上记录下复盘后自己的总结出来的关键点。

这些关键点可以是表现的好的地方，但是更多的应该是需要提升的地方。

也许你也在网上看到过这个套路：面试的过程中有几个问题没有回答上来，最后面试官说你先回去等通知吧。于是面试结束后，你对于没有回答上来的问题进行了学习，然后把自己的学习总结发给面试官。面试官一看，哟，这小伙可以啊，学习能力还不错。

然后就真的通知你准备进行下一轮面试吧。

这招我没用过，但是这个套路，传递的思想就是：在自己领域范围内，不懂的问题，遇到了，你得主动去解决。

面试后的复盘，非常的重要。

复盘过程中的想法形成文字，保留下来，非常非常的重要。

形成文字了，还可以分享出去，帮助后来人。

好了，既然读者问了这个问题，我就稍微扩展一下，把我自己知道的都分享一下。

先看示例代码

Redisson 分布式锁可能大多数朋友都用过。先上个代码给大家看看是怎么用的。

看到这几行代码，你先别往下看，你先想一想，和你自己造的轮子比起来有什么非常明显不一样的地方？

我给大家分享一下我第一次用 Redission 做分布式锁的时候遇到的两个非常直观的疑问吧。

value去哪里了？
过期时间去哪里了？

之前说过，如果是我们自己造轮子，基于 Redis 做分布式锁的话，需要向 Redis 发一条下面的命令：

代码语言：javascript复制

SET key random_value NX PX 3000

而在我们上面的示例代码中，为什么只有 key 没有 value 呢？

我们知道 value 是必须要有的。还记得《求锤得锤之神仙打架》这篇文章里面说的，当面试官问：

你给我讲一讲基于Redis的加锁和释放锁的细节吧。

我们从三个关键点中去回答：

原子命令加锁。
设置值的时候，放的是random_value。
value 的值设置为随机数主要是为了更安全的释放锁，释放锁的时候需要检查 key 是否存在，且 key 对应的值是否和我指定的值一样，是一样的才能释放锁。所以可以看到这里有获取、判断、删除三个操作，为了保障原子性，我们需要用 lua 脚本。

所以，这个 value 是非常重要的。

另外，第 3 步，释放锁的时候为什么需要 lua 脚本，也有读者问过，其实这事几句话就能说清楚，所以我在这里插播一下：

你看这三个操作：获取、判断、删除。

获取操作，只读不写，没有任何问题。问题就出在判断和删除之间。如果不是原子操作，出现了下面的情况：

线程 A 在判断了 value 是自己放进去的，在执行 key 删除操作之前，程序 GC 导致了 STW。
STW 期间线程 A 的锁虽然没有执行删除操作，但是由于时间到期被 redis 释放了。
STW 之后，在线程 A 执行删除操作之前，线程 B 加了同样 key 的锁。
结果你猜怎么着？线程 A 把线程 B 加的锁删除了。这就出问题了。

为什么 lua 脚本可以解决这个问题呢？因为 lua 脚本的执行是原子性的，再加上 Redis 执行命令是单线程的，所以在 lua 脚本执行完之前，其他的命令都得等着。就不会出现上面说的情况了。

第二个问题是过期时间去哪里了呢？

看上面的加锁代码，像是没有设置过期时间似的。

我们先说说没有过期时间的问题是什么。很明显嘛，容易造成死锁。

加锁操作的服务器，在没有执行释放锁操作之前，服务器崩了。

哦豁，喜提死锁一把。

value去哪了？

对于这个问题，首先我们需要确定的是，value一定是有的。

当我们自己放 value 的时候，一般就是搞个随机值，往里面一塞就完事了。

另外，我见过网上有些分析 Redis 分布式锁的文章里面 value 直接扔个 OK 进去。前面我们说过，这是不对啊，朋友们。要注意辨别。

用 Redssion 时，我们知道这个 key 肯定是框架帮我们生成了。所以我们只需要去源码中验证我们的想法即可。

但是，先别慌，我们还有一个更加简单的验证方法：程序跑起来，然后去 Redis 里面看一眼不就完事了？

看了一眼后发现，不错哦，不仅验证了我们的想法，还有意外收获呢。

意外收获一：我们看到了 TTL:25 说明虽然我们没用设置过期时间，但是框架帮我们把过期时间设置好了。这部分在这一小节中先按下不表，等下一小节详细描述。

意外收获二：可以看到我们放进去的 why 是一个 Hash 类型。并不是我们常用的 String 类型。

很明显，key 是 UUID:1，这个 1 是什么含义呢？

为什么要用 Hash 类型，而不用 String 类型呢？

我们带着这两个疑问去看一眼源码。

注意本文中的 Redssion 的 Maven 版本为 3.12.3。

Redssion 的源码非常好 Debug，我建议你自己实际操作一遍。

首先 lock 操作会调用到这个方法：

org.redisson.RedissonLock#lock(long, java.util.concurrent.TimeUnit, boolean)

可以看到，在这里的时候，获取到的 thredId 就是 1。那 key 里面 UUID 后面拼接的 1。是不是就是这里来的呢？我们接着往下看。

再往前 Debug 三步就能到下面的这个位置：

org.redisson.RedissonLock#tryLockInnerAsync

到这里的 getLockName(threadId) 其实就是我们要找的东西：

你看，这一串东西，不就是我们刚刚看到的 UUID：1 吗？这个 1 就是线程ID。

什么？你问我为什么说这个 id 是 UUID？

直觉，程序猿的直觉告诉我，这就是个 UUID。但是我可以给你验证一下。

这个 id 的来源是下面这个接口：

org.redisson.connection.ConnectionManager

而该接口有 5 个实现类：

在创建 ConnectionManager 时，每个实现类的构造方法传的都是 UUID。

所以，我们可以下结论了：

使用 Redssion 做分布式锁，不需要明确指定 value ，框架会帮我们生成一个由 UUID 和加锁操作的线程的 threadId 用冒号拼接起来的字符串。

毫无挑战甚至有点无聊的探索过程啊。（其实我想表达的是源码真的不难，不要抱有恐惧的心理，带着问题去看源码。）

但是别着急，这只是开胃菜。

对于第二个问题：为什么要用 Hash 类型，而不用 String 类型呢？

我们在下一节，寻找过期时间去哪里了的同时，寻找该问题的答案。

过期时间去哪了？

这个问题，我们从这段代码里面可以找到答案：

org.redisson.RedissonLock#tryLockInnerAsync

我们首先看一下这个方法对应的几个入参：

主要关注我框起来的部分：

script：是要执行的 lua 脚本。
keys：是 redis 中的 key。这里的 why 就是 KEYS[1]。
params：是 lua 脚本的参数。这里的 30000 就是 ARVG[1]。UUID：thredId 就是 ARVG[2]。

所以这个过期时间我们也知道了，默认是 30000ms，即30s。

知道了上面三个参数的含义后，我们再来拆解这个 lua 脚本就很简单了，首先我们把他拆解为三部分：

第一部分：加锁

先看第一部分的加锁操作：

第 4行，首先用 exists 判断了 KEYS[1] （即 why）是否存在。

如果不存在，则进入第 5 行，使用 hincrby 命令。hincrby 命令是干什么的知道吧？

之后进入第 6 行，对 KEY[1] 设置过期时间，30000ms。

然后，第7行，进行返回为 nil，结束。

这样，一个原子性的加锁操作就完成了。

到这里，我们就已经从源码的角度验证了：因为用的是 hincrby 命令，Redssion 做锁的时候 key 确实是一个 Hash 结构。

第二部分：重入

当第一部分的 if 分支判断 KEYS[1] 是存在的，则会进入到这个分支中：

由于 KEYS[1] 是一个 Hash 结构，所以第 13 行的意思是获取这个 KEYS[1] 中字段为 ARGV[2] 的数据，判断是否存在。

如果存在，则进入第 14 行代码，用 hincrby 命令对 ARGV[2] 字段进行加一操作。

然后第 15 行，没啥说的，就是重新设置过期时间为 30s。之后第 16 行，返回为 nil，结束。

所以，你在感受一下第 14 行代码的作用是什么？进入，然后加一，你联想到了什么？

看到这里的时候，解锁的 lua 脚本都不必看的，想也能想到，肯定是有一个减一的操作，然后减到 0，就释放这把锁。一会我们就去验证这个点。

所以，这里也就解释了为什么 Redssion 需要用 Hash 类型做锁。因为它支持可重入呀。

你用 String 类型，你怎么实现重入功能，来键盘给你，实现一个，让我学习一下？（其实也是可以的，就是有点背道而驰了。没意义。）

第三部分：返回

一行代码，问题不大。作用就是返回 KEY[1] 的剩余存活时间。

通过分析 lua 的这三部分，我们知道了：过期时间默认是 30s。当一个 key 加锁成功或者当一个锁重入成功后都会返回空，只有加锁失败的情况下会返回当前锁剩余的时间。

记住这个结论，我们在接下来的看门狗咋工作的这一小节中会用到这个返回值。

另外，写文章的时候我发现 Redssion 的最新版本 3.12.3 和之前的版本相比，加锁时的 lua 脚本有一个细微的差别，如下：

3.12.3 版本之前用的是 hset ，现在用的是 hincrby。所以导致第一部分和第二部分相似度有点高。看起来会有点容易迷糊。

你去网上找应该看到的都是说 hset 操作的。因为 3.12.3 版本刚刚发布一个月。

恭喜你，朋友，又学到了一个用不上的知识点。

看门狗咋工作的？

看到这一节的朋友们，辛苦了。在这一节，我们终于要看到看门狗长啥样了。

org.redisson.RedissonLock#tryAcquireAsync

这里的 ttlRemaining 就是经过 lua 脚本后返回的值。经过前面我们知道了，当加锁成功或者重入成功后会返回 null。进入这个方法：

org.redisson.RedissonLock#scheduleExpirationRenewal

这个方法，就是看门狗工作的片区了。

Debug之后，你会遇到这个方法：

org.redisson.RedissonLock#renewExpiration

很明显，从上面标注的数字可以看出来：

①：这是一个任务。

②：这任务需要执行的核心代码。

③：该任务每 internalLockLeaseTime/3ms 后执行一次。而 internalLockLeaseTime 默认为 30000。所以该任务每 10s 执行一次。

接着我们看一下 ② 里面执行的核心代码是什么：

这个 lua 脚本，先判断 UUID:threadId 是否存在，如果存在则把 key 的过期时间重新设置为 30s，这就是一次续命操作。

来，在做个小学二年的算法题：

应用题：key 默认的过期时间是 30s，每过 30s/3 的时候会去进行续命操作，那么每当 key 的 ttl（剩余时间）返回多少的时候，会进行续命操作？

答：由题干可知，30s/3 = 10s。于是得公式到：30s - 10s =20s。

所以，每当 key 的 ttl（剩余时间）为 20 的时候，则进行续命操作，重新将 key 的过期时间设置为默认时间 30s。

注意我上面一直强调的是默认时间 30s。

因为这个时间是可以修改的，比如我们想要修改为 60s，就这样：

于是 internalLockLeaseTime 就变成了 60000 了：

那么附加题就来了。

附加题：阅读上面材料后，当默认时间被修改为 60s 后，那么每当 key 的 ttl（剩余时间）返回多少的时候，会进行续命操作？

答：由题可得，时间每过 60s/3 = 20s 时，任务会被触发，看门狗进行工作。

所以，60s -20s =40s。每当 key 的 ttl 返回 40 时，会进行续命操作。

得学会变形，朋友们，明白吗？

接下来，我们看看这个 task 任务是怎么实现的。

可以看到，这个 Timeout 是 netty 包里面的类。

这个 task 任务是基于 netty 的时间轮做的。

面试官追问你：啥是时间轮？

你又不知道。那你接着往下看。

时间轮又是啥？

你听到了时间轮，你首先想到了啥？

听到这个词，就算你完全不知道时间轮，你也该想到，轮子嘛，不就是一个环嘛。

网上随便一搜，你就知道它确实长成了一个环状：

它的工作原理如下：

图片中的时间轮大小为 8 格，每格又指向一个保存着待执行任务的链表。

我们假设它每 1s 转一格，当前位于第 0 格，现在要添加一个 5s 后执行的任务，则0 5=5，在第5格的链表中添加一个任务节点即可，同时标识该节点round=0。

我们假设它每 1s 转一格，当前位于第 0 格，现在要添加一个 17s 后执行的任务，则（0 17）% 8 = 1，则在第 1 格添加一个节点指向任务，并标记round=2，时间轮每经过第 1 格后，对应的链表中的任务的 round 都会减 1 。则当时间轮第 3 次经过第 1 格时，会执行该任务。

需要注意的是时间轮每次只会执行round=0的任务。

知道了工作原理，我们再看看前面说的 Timeout 类，其实就是 HashedWheelTimer 里面 newTimeout 方法的返回：

前面我们分析了，在 Redssion 实现看门狗功能的时候，使用的是 newTimeout 方法。该方法三个入参：

task，任务，对于 Redssion 看门狗功能来说，这个 task 就是把对应的 key 的过期时间重置，默认是 30s。
delay，每隔多久执行一次，对于 Redssion 看门狗功能来说，这个 delay 就是 internalLockLeaseTime/3 算出来的值，默认是 10s。
unit，时间单位。

其实，你发现了吗，这个时候我们已经脱离了 Redssion 进入 Netty 了。

我们只需要告诉 newTimeout 方法，我们要每隔多少时间执行一次什么任务就行。

那我们为什么不自己写个更加简单的，易于理解的 Demo 来分析这个时间轮呢？

比如下面这样的：