Java|Redisson里的“看门狗”居然有这两个“bug”（）开发语言|微服务|spring|程序员

文章图片

?大家好！

提到分布式锁，大家一般都会想到 Redis。
想到 Redis，一部分同学会说到 Redisson。
那么说到 Redisson，就不得不掰扯掰扯一下它的“看门狗”机制了。
所以你以为这篇文章我要给你讲“看门狗”吗？
不是，我主要是想给你汇报一下我最近研究的由于引入“看门狗”之后，给 Redisson 带来的两个看起来就菊花一紧的 bug ：

看门狗不生效的 BUG。
看门狗导致死锁的 BUG。

为了能让你丝滑入戏，我还是先简单的给你铺垫一下，Redisson 的看门狗到底是个啥东西。

文章图片

?

看门狗描述
你去看 Redisson 的 wiki 文档，在锁的这一部分，开篇就提到了一个单词：watchdog

github.com/redisson/re…

文章图片

?

watchdog，就是看门狗的意思。
它是干啥用的呢？
好的，如果你回答不上来这个问题。那当你遇到下面这个面试题的时候肯定懵逼。
面试官：请问你用 Redis 做分布式锁的时候，如果指定过期时间到了，把锁给释放了。但是任务还未执行完成，导致任务再次被执行，这种情况你会怎么处理呢？
这个时候，99% 的面试官想得到的回答都是看门狗，或者一种类似于看门狗的机制。
如果你说：这个问题我遇到过，但是我就是把过期时间设置的长一点。
时间到底设置多长，是你一个非常主观的判断，设置的长一点，能一定程度上解决这个问题，但是不能完全解决。
所以，请回去等通知吧。
或者你回答：这个问题我遇到过，我不设置过期时间，由程序调用 unlock 来保证。
好的，程序保证调用 unlock 方法没毛病，这是在程序层面可控、可保证的。但是如果你程序运行的服务器刚好还没来得及执行 unlock 就宕机了呢，这个你不能打包票吧？
这个锁是不是就死锁了？
所以......

文章图片

?

为了解决前面提到的过期时间不好设置，以及一不小心死锁的问题，Redisson 内部基于时间轮，针对每一个锁都搞了一个定时任务，这个定时任务，就是看门狗。
在 Redisson 实例被关闭前，这个狗子可以通过定时任务不断的延长锁的有效期。
因为你根本就不需要设置过期时间，这样就从根本上解决了“过期时间不好设置”的问题。默认情况下，看门狗的检查锁的超时时间是 30 秒钟，也可以通过修改参数来另行指定。
如果很不幸，节点宕机了导致没有执行 unlock，那么在默认的配置下最长 30s 的时间后，这个锁就自动释放了。
那么问题来了，面试官紧接着来一个追问：怎么自动释放呢？
这个时候，你只需要来一个战术后仰：程序都没了，你觉得定时任务还在吗？定时任务都不在了，所以也不会存在死锁的问题。

文章图片

?

搞 Demo
前面简单介绍了原理，我也还是给你搞个简单的 Demo 跑一把，这样更加的直观。
引入依赖，启动 Redis 什么的就不说了，直接看代码。
示例代码非常简单，就这么一点内容，非常常规的使用方法：

文章图片

?

把项目启动起来，触发接口之后，通过工具观察 Redis 里面 whyLock 这个 key 的情况，是这样的：

文章图片

你可以看到在我的截图里面，是有过期时间的，也就是我打箭头的地方。
然后我给你搞个动图，你仔细看过期时间（TTL）这个地方，有一个从 20s 变回 30s 的过程：
【Java|Redisson里的“看门狗”居然有这两个“bug”（）】

?首先，我们的代码里面并没有设置过期时间的动作，也没有去更新过期时间的这个动作。

那么这个东西是怎么回事呢？

文章图片

?

很简单，Redisson 帮我们做了这些事情，开箱即用，当个黑盒就完事了。
接下来我就是带你把黑盒变成白盒，然后引出前面提到的两个 bug。
我的测试用例里面用的是 3.16.0 版本的 Redission，我们先找一下它关于设置过期动作的源码。
首先可以看到，我虽然调用的是无参的 lock 方法，但是它其实也只是一层皮而已，里面还是调用了带入参的 lock 方法，只不过给了几个默认值，其中 leaseTime 给的是 -1：

文章图片

?

而有参的 lock 的源码是这样的，主要把注意力放到我框起来的这一行代码中：

文章图片

?

tryAcquire 方法是它的核心逻辑，那么这个方法是在干啥事儿呢？
点进去看看，这部分源码又是这样的：

文章图片

?

其中 tryLockInnerAsync 方法就是执行 Redis 的 Lua 脚本来加锁。
既然是加锁了，过期时间肯定就是在这里设置的，也就是这里的 leaseTime：

文章图片

?

而这里的 leaseTime 是在构造方法里面初始化的，在我的 Demo 里面，用的是配置中的默认值，也就是 30s :

文章图片

?

所以，为什么我们的代码里面并没有设置过期时间的动作，但是对应的 key 却有过期时间呢？
这里的源码回答了这个问题。
额外提一句，这个时间是从配置中获取的，所以肯定是可以自定义的，不一定非得是 30s。
另外需要注意的是，到这里，我们出现了两个不同的 leaseTime。
分别是这样的：

tryAcquireOnceAsync 方法的入参 leaseTime，我们的示例中是 -1。
tryLockInnerAsync 方法的入参 leaseTime，我们的示例中是默认值 30 * 1000。

文章图片

?

在前面加完锁之后，紧接着就轮到看门狗工作了：

文章图片

?

前面我说了，这里的 leaseTime 是 -1，所以触发的是 else 分支中的 scheduleExpirationRenewal 代码。
而这个代码就是启动看门狗的代码。
换句话说，如果这里的 leaseTime 不是 -1，那么就不会启动看门狗。
那么怎么让 leaseTime 不是 -1 呢？
自己指定加锁时间：

文章图片

?

说人话就是如果加锁的时候指定了过期时间，那么 Redission 不会给你开启看门狗的机制。
这个点是无数人对看门狗机制不清楚的人都会记错的一个点，我曾经在一个群里面据理力争，后来被别人拿着源码一顿乱捶。

文章图片

是的，我就是那个以为指定了过期时间之后，看门狗还会继续工作的人。
打脸老疼了，希望你不要步后尘。
接着来看一下 scheduleExpirationRenewal 的代码：

文章图片

?

里面就是把当前线程封装成了一个对象，然后维护到一个 MAP 中。
这个 MAP 很重要，我先把它放到这里，混个眼熟，一会再说它：

文章图片

?
你只要记住这个 MAP 的 key 是当前线程，value 是 ExpirationEntry 对象，这个对象维护的是当前线程的加锁次数。

文章图片

?

然后，我们先看 scheduleExpirationRenewal 方法里面，调用 MAP 的 putIfAbsent 方法后，返回的 oldEntry 为空的情况。
这种情况说明是第一次加锁，会触发 renewExpiration 方法，这个方法里面就是看门狗的核心逻辑。
而在 scheduleExpirationRenewal 方法里面，不管前面提到的 oldEntry 是否为空，都会触发 addThreadId 方法：

文章图片

?

从源码中可以看出来，这里仅仅对当前线程的加锁次数进行一个维护。
这个维护很好理解，因为要支持锁的重入嘛，就得记录到底重入了几次。
加锁一次，次数加一。解锁一次，次数减一。
接着看 renewExpiration 方法，这就是看门狗的真面目了：

文章图片

?

首先这一坨逻辑主要就是一个基于时间轮的定时任务。
标号为 ④ 的地方，就是这个定时任务触发的时间条件：internalLockLeaseTime / 3。
前面我说了，internalLockLeaseTime 默认情况下是 30* 1000，所以这里默认就是每 10 秒执行一次续命的任务，这个从我前面给到的动态里面也可以看出，ttl 的时间先从 30 变成了 20 ，然后一下又从 20 变成了 30。
标号为 ①、② 的地方干的是同一件事，就是检查当前线程是否还有效。
怎么判断是否有效呢？
就是看前面提到的 MAP 中是否还有当前线程对应的 ExpirationEntry 对象。
没有，就说明是被 remove 了。
那么问题就来了，你看源码的时候非常自然而然的就应该想到这个问题：什么时候调用这个 MAP 的 remove 方法呢？
很快，在接下来讲释放锁的地方，你就可以看到对应的 remove。这里先提一下，后面就能呼应上了。
核心逻辑是标号为 ③ 的地方。我带你仔细看看，主要关注我加了下划线的地方。
能走到 ③ 这里说明当前线程的业务逻辑还未执行完成，还需要继续持有锁。
首先看 renewExpirationAsync 方法，从方法命名上我们也可以看出来，这是在重置过期时间：

文章图片

?

上面的源码主要是一个 lua 脚本，而这个脚本的逻辑非常简单。就是判断锁是否还存在，且持有锁的线程是否是当前线程。如果是当前线程，重置锁的过期时间，并返回 1，即返回 true。
如果锁不存在，或者持有锁的不是当前线程，那么则返回 0，即返回 false。
接着标号为 ③ 的地方，里面首先判断了执行 renewExpirationAsync 方法是否有异常。
那么问题就来了，会有什么异常呢？
这个地方的异常，主要是因为要到 Redis 执行命令嘛，所以如果 Redis 出问题了，比如卡住了，或者掉线了，或者连接池没有连接了等等各种情况，都可能会执行不了命令，导致异常。
如果出现异常了，则执行下面这行代码：

EXPIRATION_RENEWAL_MAP.remove(getEntryName());

然后就 return ，这个定时任务就结束了。
好，记住这个 remove 的操作，非常重要，先混个眼熟，一会会讲。
如果执行 renewExpirationAsync 方法的时候没有异常。这个时候的返回值就是 true 或者 false。
如果是 true，说明续命成功，则再次调用 renewExporation 方法，等待着时间轮触发下一次。
如果是 false，说明这把锁已经没有了，或者易主了。那么也就没有当前线程什么事情了，啥都不用做，默默的结束就行了。
上锁和看门狗的一些基本原理就是前面说到这么多。
接着简单看看 unlock 方法里面是怎么回事儿的。

文章图片

?

首先是 unlockInnerAsync 方法，这里面就是 lua 脚本释放锁的逻辑：

文章图片

?

这个方法返回的是 Boolean，有三种情况。

返回为 null，说明锁不存在，或者锁存在，但是 value 不匹配，表示锁已经被其他线程占用。
返回为 true，说明锁存在，线程也是对的，重入次数已经减为零，锁可以被释放。
返回为 false，说明锁存在，线程也是对的，但是重入次数还不为零，锁还不能被释放。

但是你看 unlockInnerAsync 是怎么处理这个返回值的：

文章图片

?

返回值，也就是 opStatus，仅仅是判断了返回为 null 的情况，抛出异常表明这个锁不是被当前线程持有的，完事。
它并不关心返回为 true 或者为 false 的情况。
然后再看我框起来的 cancelExpirationRenewal(threadId); 方法：

文章图片

?

这里面就有 remove 方法。
而前面铺垫了这么多其实就是为了引出这个 cancelExpirationRenewal 方法。
纵观一下加锁和解锁，针对 MAP 的操作，看一下下面的这个图片：

文章图片

?

标号为 ① 的地方是加锁，调用 MAP 的 put 方法。
标号为 ② 的地方是放锁，调用 MAP 的 remove 方法。
记住上面这一段分析，和操作这个 MAP 的时机，下面说的 BUG 都是由于对这个 MAP 的操作不恰当导致的。
看门狗不生效的BUG
前面找了一个版本给大家看源码，主要是为了让大家把 Demo 跑起来，毕竟引入 maven 依赖的成本是小很多的。
但是真的要研究源码，还是得把先把源码拉下来，慢慢的啃起来。
直接拉项目源码的好处我在之前的文章里面已经说很多次了，对我而言，无外乎就三个目的：

可以保证是最新的源码
可以看到代码的提交记录
可以找到官方的测试用例

好，话不多说，首先我们看看开篇说的第一个 BUG：看门狗不生效的问题。
从这个 issues 说起：

github.com/redisson/re…

文章图片

?
编辑切换为居中
添加图片注释，不超过 140 字（可选）

在这个 issues 里面，他给到了一段代码，然后说他预期的结果是在看门狗续命期间，如果出现程序和 Redis 的连接问题，导致锁自动过期了，那么我再次申请同一把锁，应该是让看门狗再次工作才对。
但是实际的情况是，即使前一把锁由于连接异常导致过期了，程序再成功申请到一把新锁，但是这个新的锁，30s 后就自动过期了，即看门狗不会工作。
这个 issues 对应的 pr 是这个：

github.com/redisson/re…

文章图片

?

在这个 pr 里面，提供了一个测试用例，我们可以直接在源码里面找到：

org.redisson.RedissonLockExpirationRenewalTest

这就是拉源码的好处。
在这个测试用例里面，核心逻辑是这样的：

文章图片

?

首先需要说明的是，在这个测试用例里面，把看门狗的 lockWatchdogTimeout 参数修改为 1000 ms：

文章图片

?

也就是说看门狗这个定时任务，每 333ms 就会触发一次。

文章图片

?

然后我们看标号为 ① 的地方，先申请了一把锁，然后 Redis 发生了一次重启，重启导致这把锁失效了，比如还没来得及持久化，或者持久化了，但是重启的时间超过了 1s，这锁就没了。
所以，在调用 unlock 方法的时候，肯定会抛出 IllegalMonitorStateException 异常，表示这把锁没了。
到这里一切正常，还能理解。
但是看标号为 ② 的地方。
加锁之后，业务逻辑会执行 2s，肯定会触发看门狗续命的操作。
在这个 bug 修复之前，在这里调用 unlock 方法也会抛出 IllegalMonitorStateException 异常，表示这把锁没了：

文章图片

?

先不说为啥吧，至少这妥妥的是一个 Bug 了。

文章图片

?

因为按照正常的逻辑，这个锁应该一直被续命，然后直到调用 unlock 才应该被释放。
好，bug 的演示你也看到了，也可以复现了。你猜是什么原因？
答案其实我在前面应该给你写出来了，就看这波前后呼应你能不能反应过来了。
首先前提是两次加锁的线程是同一个，然后我前面不是特意强调了 oldEntry 这个玩意吗：

文章图片

?

上面这个 bug 能出现，说明第二次 lock 的时候 oldEntry 在 MAP 里面是存在的，因此误以为当前看门狗正在工作，直接进入重入锁的逻辑即可。
为什么第二次 lock 的时候 oldEntry 在 MAP 里面是存在的呢？
因为第一次 unlock 的时候，没有从 MAP 里面把当前线程的 ExpirationEntry 对象移走。
为什么没有移走呢？
看一下这个哥们测试的 Redisson 版本：

文章图片

?

在这个版本里面，释放锁的逻辑是这样的：

文章图片

诶，不对呀，这不是有 cancelExpirationRenewal(threadId) 的逻辑吗？
没错，确实有。
但是你看什么情况下会执行这个逻辑。
首先是出现异常的情况，但是在我们的测试用例中，两次调用 unlock 的时候 Redis 是正常的，不会抛出异常。
然后是 opStatus 不为 null 的时候会执行该逻辑。
也就是说 opStatus 为 null 的时候，即当前锁没有了，或者易主了的时候，不会触发 cancelExpirationRenewal(threadId) 的逻辑。
巧了，在我们的场景里面，第一次调用 unlock 方法的时候，就是因为 Redis 重启导致锁没有了，因此这里返回的 opStatus 为 null，没有触发 cancelExpirationRenewal 方法的逻辑。
导致我第二次在当前线程中调用 lock 的时候，走到下面这里的时候，oldEntry 不为空：

文章图片

?

所以，走了重入的逻辑，并没有启动看门狗。
由于没有启动看门狗，导致这个锁在 1000ms 之后就自动释放了，可以被别的线程抢走拿去用。
随后当前线程业务逻辑执行完成，第二次调用 unlock，当然就会抛出异常了。
这就是 BUG 的根因。
找到问题就好了，一行代码就能解决：

文章图片

?
只要调用了 unlock 方法，不管怎么样，先调用 cancelExpirationRenewal(threadId) 方法，准没错。
这就是由于没有及时从 MAP 里面移走当前线程对应的对象，导致的一个 BUG。
再看看另外一个的 issue：

github.com/redisson/re…

文章图片

?

这个问题是说如果我的锁由于某些原因没了，当我在程序里面再次获取到它之后，看门狗应该继续工作。
听起来，说的是同一个问题对不对？
是的，就是说的同一个问题。
但是这个问题，提交的代码是这样的：

文章图片

在看门狗这里，如果看门狗续命失败，说明锁不存在了，即 res 返回为 false，那么也主动执行一下 cancelExpirationRenewal 方法，方便为后面的加锁成功的线程让路，以免耽误别人开启看门狗机制。
这样就能有双重保障了，在 unlock 和看门狗里面都会触发 cancelExpirationRenewal 的逻辑，而且这两个逻辑也并不会冲突。

文章图片

?

另外，我提醒一下，最终提交的代码是这样的，两个方法入参是不一样的：

文章图片

?

为什么从 threadId 修改为 null 呢？
留个思考题吧，就是从重入的角度考虑的，可以自己去研究一下，很简单的。
看门狗导致死锁的BUG
这个 BUG 解释起来就很简单了。
看看这个 issue：

github.com/redisson/re…

文章图片

?

在这里把复现的步骤都写的清清楚楚的。
测试程序是这样的，通过定时任务 1s 触发一次，但是任务会执行 2s，这样就会导致锁的重入：

文章图片

?

他这里提到一个命令：

CLIENT PAUSE 5000

主要还是模拟 Redis 处理请求超时的情况，就是让 Redis 假死 5s，这样程序发过来的请求就会超时。
这样，重入的逻辑就会发生混乱。
看一下这个 bug 修复的对应的关键代码之一：

文章图片

?

不管 opStatus 返回为 false 还是 true，都执行 cancelExpirationRenewal 逻辑。
问题的解决之道，还是在于对 MAP 的操作。
另外，多提一句。
也是在这次提交中，把维护重入的逻辑封装到了 ExpirationEntry 这个对象里面，比起之前的写法优雅了很多，有兴趣的可以把源码拉下来进行一下对比，感受一下什么叫做优雅的重构：

文章图片

?

线程中断
在写文章的时候，我还发现一个有意思的，但对于 Redisson 无解的 bug。
就是这里：

文章图片

我第一眼看到这一段代码就很奇怪，这样奇怪的写法，背后肯定是有故事的。
这背后对应的故事，藏在这个 issue 里面：

github.com/redisson/re…

文章图片

翻译过来，说的是当 tryLock 方法被中断时，看门狗还是会不断地更新锁，这就造成了无限锁，也就是死锁。
我们看一下对应的测试用例：

文章图片

?

开启了一个子线程，在子线程里面执行了 tryLock 的方法，然后主线程里面调用了子线程的 interrupt 方法。
你说这个时候子线程应该怎么办？
按理来说，线程被中断了，是不是看门狗也不应该工作呢？
是的，所以这样的代码就出现了：

文章图片

但是，你细品，这几行代码并没有完全解决看门狗的问题。只能在一定概率上解决第一次调用后 renewExpiration 方法后，还没来得及启动定时任务之前的这一小段时间。
所以，测试案例里面的 sleep 时间，只有 5ms：

文章图片

这时间要是再长一点，就会触发看门狗机制。
一旦触发看门狗机制，触发 renewExpiration 方法的线程就会变成定时任务的线程。
你外面的子线程 interrupt 了，和我定时任务的线程有什么关系？
比如，我把这几行代码移动到这里：

文章图片

?

其实没有任何卵用:

文章图片

?

因为线程变了。
对于这个问题，官方的回答是这样的：

文章图片

?

大概意思就是说：嗯，你说的很有道理，但是 Redisson 的看门狗工作范围是整个实例，而不是某个指定的线程。
意外收获
最后，再来一个意外收获：

文章图片

你看 addThreadId 这个方法重构了一次。
但是这次重构就出现问题了。
原来的逻辑是当 counter 是 null 的时候，初始化为 1。不为 null 的时候，就执行 counter++，即重入。
重构之后的逻辑是当 counter 是 null 的时候，先初始化为 1，然后紧接着执行 counter++。
那岂不是 counter 直接就变成了 2，和原来的逻辑不一样了？
是的，不一样了。
搞的我 Debug 的时候一脸懵逼，后来才发现这个地方出现问题了。