当前位置：首页 > news >正文

十万个why：锁明明还没过期，为什么另一个线程能抢进去？

news 2026/5/12 11:44:10

做分布式开发的时候，大家对 Redis 分布式锁应该都不陌生。

为了防止锁死，比如服务器突然断电，锁永远不释放，我们通常都会给锁加一个过期时间（TTL）。

写代码的时候，我们心里的算盘是这样打的：

❝
“我的业务逻辑跑完只需要 200 毫秒，但我为了保险，给锁设了 10 秒的过期时间。这 10 秒够我跑 50 次了，绝对稳如老狗。”

但现实往往喜欢给人大嘴巴子。

在线上高并发场景下，你可能会遇到一种极其诡异的并发现象：

监控显示，线程 A 还在执行业务逻辑，锁的过期时间也没到（理论上），但线程 B 竟然大摇大摆地抢到了锁，开始修改同一份数据。脏数据就这么产生了～

那这把明明还没过期的锁，到底是怎么失效的。

1. 案发现场

为了复现这个问题，我们先看一段看似标准的分布式锁伪代码：

// 1. 加锁，设置 10秒 过期 if (redis.setnx("lock_key", "thread_A", 10s)) { try { // 2. 执行业务逻辑 (预计 200ms) doBusiness(); } finally { // 3. 释放锁 // (这里通常会校验是不是自己的锁，先省略) redis.del("lock_key"); } }

这段代码在 99.99% 的时间里都能完美工作，但你的价值往往就是去解决那 0.01% 疑难问题。

直到有一天，服务器负载突然飙升，应用触发了一次严重的Full GC，或者宿主机发生了短时间的卡顿。

就在这瞬间，事故发生了。

2. 时间被冻结

我们总以为时间是连续的、均匀流逝的。但在计算机的世界里，尤其是 Java 的世界里，时间是可以暂停的。

导致锁失效的真凶，正是 JVM 的STW（Stop-The-World）机制。

我们把时间放慢看，在微观的时间轴上到底发生了什么：

(0s) 线程 A 成功拿到锁，过期时间10s。

(0.1s) 线程 A 刚开始执行doBusiness()，才跑了一行代码。

(0.2s)事故来了！JVM 触发了一次耗时极长的 Full GC，可能是因为内存泄漏，或者堆太大回收慢。

此时JVM 暂停了包括线程A在内所有工作线程，线程 A 停在了第 0.2s，它觉得自己才刚开始跑。但Redis 服务端的时间并没有停！Redis 那边的倒计时还在正常走。

(10.2s) 10 秒过去了，Redis 发现lock_key过期了，于是删除了这个 Key。

(10.3s) 线程 B 进来请求加锁，因为它发现 Redis 里没锁，所以成功拿到了锁。

(12s)Full GC 结束，线程 A 被唤醒了。线程 A 完全不知道自己sleep 12 秒，以为自己才跑 0.2s，手里还攥着锁。于是线程 A 继续执行剩下的业务逻辑，往数据库里写数据。

(12.1s) 线程 B 同时也在写数据。

结果线程 A 和线程 B 同时在操作数据，锁彻底失效了。

这就是分布式系统中最经典的时间跳变问题，你以为你拥有 10 秒，其实在 STW 面前，这 10 秒可能瞬间就蒸发了。

3. 加长过期时间行不行？

很多同学的第一反应是：那我就把过期时间设长点，设成 10 分钟，GC 总不能停 10 分钟吧？

这确实能降低概率，但治标不治本。

副作用大：如果你的服务真的挂了，锁要等 10 分钟才能释放，这期间业务就瘫痪了。
不可控：你永远不知道下一次 STW 会停多久，或者网络延迟会有多大。

Watchdog 续命

这是目前业界最主流的方案，比如 Java 的Redisson客户端就实现了这个机制，俗称看门狗。

它的原理是：

线程 A 拿到锁，过期时间设为 30s。
Redisson 会在后台启动一个守护线程。
每隔 10s（默认是过期时间的 1/3），守护线程就去 Redis 检查一下：线程 A 还活着吗？还持有锁吗？
如果还持有，就自动把锁的过期时间重新续满到 30s。

这样一来，只要线程 A 的进程没挂，即使正在 Full GC，只要 GC 结束，守护线程也会恢复工作去续期，锁就永远不会过期。

只有当线程 A 的机器彻底宕机，守护线程也挂了，锁才会因为没人续期而自动释放。

4. 看门狗就万无一失了吗？

这就完了？如果是普通的业务，Redisson 确实够用了。

但如果你做的是金融级的核心业务，还要考虑到一种更极端的黑天鹅场景：

如果 GC 暂停发生在“最后一步”怎么办？

想象一下这个场景：

线程 A 拿到了锁，看门狗也在正常工作。
线程 A 查完数据库，计算完了金额，正准备执行最后一步UPDATE语句。
突然，超长 Full GC 来了。
这次 GC 停得太久，连后台的“看门狗”线程也被暂停了，没法去 Redis 续期。
Redis 里的锁过期了。
线程 B 拿到了锁，修改了金额。
GC 结束线程 A 苏醒，它不需要再请求 Redis，而是直接把那条UPDATE语句发给了数据库。

这又是数据覆盖了，即使有看门狗，在极端并发下，分布式锁依然无法保证 100% 的互斥安全性。

这也不能算 Bug，这是 CAP 理论总是不能十全十美。在异步网络模型中，仅仅依靠锁和时间，是无法做到绝对安全的。

终极解法：乐观锁

要彻底解决这个问题，我们不能光靠锁，还得靠存储层数据库兜底。

这个方案叫Fencing Token 栅栏令牌，或者通俗点叫乐观锁/版本号。

加锁时返回版本号：线程 A 抢 Redis 锁的时候，Redis 生成一个递增的数字 Token，比如 33。

带版本号更新：线程 A 在操作数据库时，必须带上这个 33。

UPDATE accountSET money = 100 WHEREid = 1AND current_token < 33; -- 甚至更简单的乐观锁： UPDATEaccountSET money = 100, version = version + 1 WHEREid = 1ANDversion = old_version;