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

做分布式开发的时候大家对 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或者宿主机发生了短时间的卡顿。就在这瞬间事故发生了。 欢迎加入小哈的星球你将获得:专属的项目实战多个项目 / 1v1 提问 /Java 学习路线 /学习打卡 / 每月赠书 / 社群讨论新项目《Spring AI 项目实战》正在更新中..., 基于 Spring AI Spring Boot 3.x JDK 21;《从零手撸仿小红书微服务架构》 已完结基于 Spring Cloud Alibaba Spring Boot 3.x JDK 17..., 点击查看项目介绍演示地址http://116.62.199.48:7070/《从零手撸前后端分离博客项目全栈开发》2期已完结,演示链接http://116.62.199.48/;专栏阅读地址https://www.quanxiaoha.com/column截止目前累计输出 100w 字讲解图 4013 张还在持续爆肝中..后续还会上新更多项目目标是将 Java 领域典型的项目都整一波如秒杀系统, 在线商城, IM 即时通讯Spring Cloud Alibaba 等等戳我加入学习解锁全部项目已有4500小伙伴加入2. 时间被冻结我们总以为时间是连续的、均匀流逝的。但在计算机的世界里尤其是 Java 的世界里时间是可以暂停的。导致锁失效的真凶正是 JVM 的STWStop-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;校验如果中间有线程 B 抢占了锁拿到了 Token 34 并修改了数据线程 A 的 Token 33 就会变成旧版本数据库的更新操作就会失败影响行数为 0。写在最后回到标题的问题锁明明还没过期为什么会被别人抢走因为在分布式的世界里我的时间和大家的时间往往不是一回事。要好好的去理解这句话当你下次写分布式锁的时候对于剩下的那 1%如果你在做涉及钱的核心业务请务必加上数据库层面的乐观锁做最后的兜底。千万别太相信时间很多奇怪问题都是时间引起的。看完等于学会点个赞吧 欢迎加入小哈的星球你将获得:专属的项目实战多个项目 / 1v1 提问 /Java 学习路线 /学习打卡 / 每月赠书 / 社群讨论新项目《Spring AI 项目实战》正在更新中..., 基于 Spring AI Spring Boot 3.x JDK 21;《从零手撸仿小红书微服务架构》 已完结基于 Spring Cloud Alibaba Spring Boot 3.x JDK 17..., 点击查看项目介绍演示地址http://116.62.199.48:7070/《从零手撸前后端分离博客项目全栈开发》2期已完结,演示链接http://116.62.199.48/;专栏阅读地址https://www.quanxiaoha.com/column截止目前累计输出 100w 字讲解图 4013 张还在持续爆肝中..后续还会上新更多项目目标是将 Java 领域典型的项目都整一波如秒杀系统, 在线商城, IM 即时通讯Spring Cloud Alibaba 等等戳我加入学习解锁全部项目已有4500小伙伴加入1. 我的私密学习小圈子从0到1手撸企业实战项目~ 2. 阿里二面什么是 MySQL 回表查询如何避免修订版 3. Nacos 点了下线为什么流量还是打到了停机的机器上 4. 如何画出一张优秀的架构图老鸟必备最近面试BAT整理一份面试资料《Java面试BATJ通关手册》覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。 获取方式点“在看”关注公众号并回复 Java 领取更多内容陆续奉上。PS因公众号平台更改了推送规则如果不想错过内容记得读完点一下“在看”加个“星标”这样每次新文章推送才会第一时间出现在你的订阅列表里。 点“在看”支持小哈呀谢谢啦