Redisson 看门狗不是保险丝，是闹钟：一次 STW 42 秒导致锁被双持有的复盘

栈：Redisson 3.27.2、Redis 7.0.13（1 主 2 从 + 1 哨兵）、JDK 17（G1）、Spring Boot 3.2、12 台应用机（K8s 自建，4C8G 容器）。

一、现象：一个「只跑一次」的同步任务，跑了 184 遍「两遍」

背景：我们有一条用户资料同步链路 order:sync:{uid}，同一 uid 的资料变更事件可能从两个上游（订单服务、客服工单）同时到达，靠 Redisson RLock.tryLock(0, -1, SECONDS) 拿锁保证同一 uid 同一时刻只有一个实例执行同步。代码写得很标准，-1 表示交给看门狗（watchdog）自动续期。

03:14（凌晨低峰）开始，对账系统发现 184 个 uid 的同步记录在 28 秒窗口内出现了 2 条，且两条的 instance_id 不同——也就是两个实例认为自己同时持有同一把锁，把同一份数据各同步了一遍。下游 ERP 侧产生了 184 笔重复变更，人工回滚花了 3 小时。

诡异点先列三条，后面逐条拆：

锁的 TTL 配置是默认 30s，看门狗间隔默认 10s（= TTL/3）；
故障时段 Redis 侧 SLOWLOG 干净、哨兵没切换、used_memory 离上限还有 40%——服务端一切正常；
出事的 184 个 uid 全部集中在同一台应用机 A 上——不是全集群抖动，是单实例事件。

一句话：锁没有「被抢走」，是它在我们眼皮底下自己「死」了，而我们还以为它活着。

二、根因：看门狗是闹钟，不是保险丝；闹钟靠「活着的线程」去按

很多人把看门狗理解成「锁的保险丝」——业务没跑完它就自动保着，直到业务结束才释放。这个理解是反的。看门狗的真实语义是一条单向因果链：

客户端进程活着且能按时发出 PEXPIRE 续期命令 → 锁才活着。任何一个环节断了，锁按 30s TTL 无条件过期，Redis 不知道「持有者」是谁、更不关心它是不是卡住了。

也就是说：看门狗保护的不是「业务没跑完」，而是「客户端没死透」。 这两者的差集，就是我们这次踩的坑。

把机制拆成三层看：

续期任务是 scheduleAtFixedRate 的定时任务。加锁成功后，Redisson 在内部的 DefaultScheduledExecutorService（本质一个单线程 ScheduledThreadPoolExecutor）上注册一个每 10s 触发一次的任务，执行 PEXPIRE lock:xxx 30000。
续期命令走的是 Netty 事件循环线程。Redisson 的 CommandAsyncService 底层是 Netty 单线程 event loop 收发命令。一个 event loop 上的所有命令是串行排队的——如果前一条命令（哪怕是另一把锁的、另一个业务的）卡住，后面的 PEXPIRE 就被排在其后。
JVM 层面，STW 一停，上面两层全停。G1 的并发标记阶段不 STW，但并发标记失败退化到 Full GC（To-space exhausted / humongous 分配失败）是整堆 STW 的。STW 期间，ScheduledThreadPoolExecutor 的 worker 线程、Netty 的 event loop 线程全部冻结——闹钟本身被按停了。

这次的具体因果链（用 jstat 与 GC log 交叉验证）：

03:11:42，实例 A 发生一次 Full GC，STW 42.3s（gc.log 里 Pause Full 42.3s，触发原因是 humongous 对象分配失败——一个 1.2MB 的 byte[] 反序列化产物在 4C8G 容器里超过了 G1 的 humongous 阈值 HeapSize/2）；
03:11:42 之前，实例 A 持有着其中约 190 把 order:sync:{uid} 锁，最近一次 PEXPIRE 成功时间是 03:11:39（锁 TTL 到期时间 ≈ 03:12:09）；
STW 42.3s > 30s TTL → 03:12:09 这批锁全部过期；
03:12:24 实例 A 恢复，代码继续跑，它仍认为自己持有锁，把同步任务跑完（这部分执行发生在 03:12:24–03:12:35）；
同一时刻，实例 B 的定时任务正常 tryLock，成功拿到已过期释放的锁，也跑了一遍（03:12:20–03:12:33）；
两段时间窗重叠 约 11 秒，184 个 uid 的同步逻辑在这 11 秒内被并发执行了两次。

关键数字对账：42.3s（STW）− 30s（TTL）= 12.3s 的「锁已死但我不知道」窗口，正好覆盖了实例 B 拿锁到实例 A 恢复执行这段重叠。这不是巧合，是必然——只要 STW 时长超过 TTL，重叠窗口就必然出现，且长度 = STW − TTL + 业务剩余执行时间。

三、具体做法：三条可复现的加固

1. 把「锁还活着吗」变成可观测的事实，而不是假设

加锁成功后立刻打点，并在业务执行的关键步骤前主动探活：

RLock lock = redisson.getLock("order:sync:" + uid);
if (!lock.tryLock(0, -1, TimeUnit.SECONDS)) { return; }
long lockAcquiredAt = System.nanoTime();
try {
    doSync(uid);
} finally {
    // 探活：如果锁已被 TTL 清掉，isHeldByCurrentThread() 返回 false
    if (!lock.isHeldByCurrentThread()) {
        log.error("LOCK_LOST uid={} heldForMs={}", uid,
                  (System.nanoTime() - lockAcquiredAt) / 1_000_000);
        // 触发补偿 / 告警，而不是继续假设自己持有
    }
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

isHeldByCurrentThread() 发一条 EVAL（校验 value 里的 threadId 是否还在），成本约 0.3ms，对同步链路完全可接受。这是把「看门狗保住了」从信仰变成断言。

2. 给看门狗留「余量倍数」，而不是贴着 30s 设计

默认 TTL 30s 是看门狗间隔 10s 的 3 倍。这个 3 倍余量假设的是「一次续期最多延迟 10s」——但 STW 可以远超 10s。两条改法：

调大 TTL：config.setLockWatchdogTimeout(60000)（60s），把余量从「扛 1 次 STW」提到「扛 2 次」。代价是持锁方真死了之后，其他实例要等 60s 才能拿到锁——对「同一 uid 串行同步」这种场景，60s 的等待是可接受的，比重复执行便宜得多。
缩小 STW：这次根因是 humongous 分配失败。在 4C8G 容器上把 -XX:G1HeapRegionSize=16m（默认 region 是 HeapSize/2048 ≈ 8MB，1.2MB 的 byte[] 不算 humongous，但更大的 3.8MB 的 byte[] 会），并限制反序列化单包上限 2MB，把 humongous 分配失败的概率从「每天 1–2 次」降到 0。改后连续 14 天 gc.log 无 Full GC。

3. 业务侧必须自带幂等，锁只是「降低并发概率」而非「保证正确性」

这条是本次复盘里最反直觉、也最重要的一条：

锁过期 ≠ 锁失效。对 Redis 而言，TTL 一到 key 就没了，锁「失效」了；但对业务而言，持有锁的那个实例并不知道锁已经没了，它还在跑——这才是真正的风险窗口。

所以幂等必须落在业务层，不能依赖锁。我们这次的 doSync 改成了：

-- 用「版本号 CAS」代替「无锁覆盖写」
UPDATE user_profile
SET payload = :new_payload, version = version + 1, updated_at = NOW()
WHERE uid = :uid AND version = :expected_version;
-- affected rows = 0 时说明被另一个实例抢先写过，本次直接放弃

version 是单调递增的乐观锁版本号，即使两个实例同时跑 doSync，第二个的 CAS 会失败（affected rows=0），业务上等价于「只跑了一次」。这把「锁保证互斥」降级成「锁降低并发概率 + 版本号保证最终只有一份生效」，正确性不再依赖看门狗是否续期成功。

四、踩过的坑与反直觉之处

坑 1：把「看门狗续期成功」当成「锁还有效」的充要条件。 反直觉点：续期成功只证明「那一刻锁还在」，不证明「业务跑完之前锁都在」。STW 期间续期任务被冻结，恢复后下一条续期命令会成功（因为 Redis 侧 key 已过期，Redisson 的续期 Lua 脚本在 key 不存在时会直接返回 0，但 Redisson 3.27.2 的实现里，unlock 前的 isHeldByCurrentThread 检查不会自动触发——它只在显式调用时才查）。所以「续期命令没报错」≠「锁还有效」。

坑 2：tryLock(0, -1, SECONDS) 的 -1 被当成「永久锁」。 -1 的语义是「交给看门狗管理」，不是「永不过期」。看门狗管理的前提是客户端进程活着且 CPU 可调度。K8s 容器里 4C 的 limit 如果被其他线程（比如一个跑飞的批处理）吃满，event loop 线程可能长期拿不到 CPU 时间片——效果等价于一次「慢 STW」，锁照样过期。

坑 3：用「锁的 TTL 比业务执行时间长」来论证安全。 我们最初的设计假设是「业务 P99 执行时间 800ms，TTL 30s，余量 37 倍，绝对安全」。这个论证漏掉了 STW 这个变量——STW 不是「业务执行慢」，是「业务执行暂停」，暂停期间 TTL 照走。余量倍数必须覆盖最坏 STW 时长，而不是最坏业务执行时长。

五、结论与可复用清单

看门狗是闹钟，不是保险丝。它的语义是「客户端活着 → 锁活着」，不是「业务没跑完 → 锁活着」。STW 超过 TTL 的那一刻，锁就死了，而持有者不知道。
isHeldByCurrentThread() 必须在业务关键步骤前显式调用，不要假设「加锁成功 = 全程持有」。
TTL 余量要覆盖最坏 STW，不是最坏业务执行时间。4C8G 容器上建议 TTL ≥ 60s，并监控 gc.log 里的 Full GC 停顿。
锁是「降低并发概率」的工具，不是「保证正确性」的工具。正确性必须落在业务层的幂等（版本号 CAS / 幂等键 / 状态机 CAS）上。
监控三条线：① 业务侧 LOCK_LOST 告警（isHeldByCurrentThread()=false）；② GC 侧 Full GC 停顿 > 10s 告警；③ Redis 侧 expired_keys 增量（锁 key 被 TTL 清除会体现在这里，但粒度粗，只能当辅助信号）。

关联阅读：站内谢知远-918 的「Redisson 看门狗续期与主从切换：3 起丢锁事故机制拆解」覆盖了服务端主从切换导致的丢锁；程清和-927 的「时钟回拨 30 秒把 Redis 分布式锁打穿」覆盖了时钟漂移导致的 TTL 提前过期。本文补的是第三条根因——客户端 STW 导致续期漏拍，三者合在一起才是「锁丢了」的完整根因清单。

0赞 0收藏 0评论 2浏览

Redisson 看门狗不是保险丝而是闹钟：一次 STW 42 秒导致同一业务锁被两个实例同时持有 11 秒的复盘