RedissonWatchDog机制详解与锁安全

Redisson 的 WatchDog 机制是保障分布式锁高可用的核心设计，但它并非“开箱即用”的万能方案——其是否启用、续期节奏与容错边界完全取决于 leaseTime 参数的设置逻辑和 lockWatchdogTimeout 的合理配置：只有未显式指定租期（或设为-1）时看门狗才启动，而传入任意正数租期（如30秒）会彻底禁用它，导致锁严格超时释放、业务未完成即失锁；续期间隔由 lockWatchdogTimeout 自动计算（/3），配置过小引发高频失败，过大则延长死锁暴露时间；更关键的是，看门狗依赖客户端线程存活与网络可达，对宕机、网络分区、误删锁或事务中提前 unlock 等场景无能为力——理解这些隐含约束，才能真正用好 Redisson 锁，避免线上事故。

Redisson 的 WatchDog 机制默认开启，但只在未显式指定 leaseTime（或设为 -1）时生效；一旦你传了具体秒数（比如 lock.lock(30, TimeUnit.SECONDS)），看门狗就彻底关闭——这是绝大多数人踩坑的起点。

为什么 lock() 能触发看门狗，而 lock(30, SECONDS) 不能？

看门狗是否启动，完全由 Redisson 源码中对 leaseTime 参数的判断决定：leaseTime == -1 || leaseTime == null 才会初始化续期任务。传入正数（哪怕只是 30）会跳过整个 renewExpiration() 启动逻辑。

• lock()：不设租期 → 使用默认 lockWatchdogTimeout = 30000ms → 启动后台线程，每 10 秒发一次 EVAL 续期脚本
• lock(30, SECONDS)：显式租期 → 认为“你已自主掌控超时” → 禁用看门狗 → 锁严格在 30 秒后释放，不管业务是否结束
• tryLock(waitTime, leaseTime, unit) 中只要 leaseTime > 0，同样禁用；只有 leaseTime == -1 才启用

lockWatchdogTimeout 配置不当会导致续期失败

这个参数不只是“锁默认过期时间”，它还直接决定看门狗的续期间隔（lockWatchdogTimeout / 3）。如果把它设得太小（比如 100），续期线程每 33ms 就发一次请求，网络抖动或 Redis 延迟稍高就会导致续期失败，锁提前释放。

• 默认值 30000（30 秒）对应续期间隔约 10 秒，是经过压测验证的平衡点
• 若业务平均耗时 2 分钟，建议将 lockWatchdogTimeout 提到 120000（2 分钟），续期间隔变为 40 秒，降低无效请求频次
• 该值不能无限调大——JVM 进程崩溃后，锁最多要等 lockWatchdogTimeout 时间才自动释放，这是死锁容忍上限

看门狗不是万能的：它无法挽救网络分区或客户端宕机

看门狗依赖持有锁的线程持续存活并能连上 Redis。一旦线程中断、JVM 退出，或客户端与 Redis 之间出现网络分区，续期请求发不出去，锁会在 lockWatchdogTimeout 后自然过期。

• 这不是 Bug，而是设计取舍：宁可短暂并发，也不接受永久死锁
• 续期操作本身用异步 RFuture 发起，失败不会阻塞业务线程，但也不会重试到成功为止
• 如果你在 Spring @Transactional 方法里加锁，unlock() 在事务提交前执行，看门狗停止，锁立刻失效——必须把锁生命周期完整包裹在事务外

真正容易被忽略的是：看门狗续期靠的是 Lua 脚本原子校验（GET + PEEXPIRE），它只认当前锁的 value（即线程 ID）。一旦你手动用 DEL 或其他客户端删锁，或用错误 value 调用 unlock()，看门狗还在傻等，但锁早已丢失——此时续期请求会失败，锁进入静默过期状态。

本篇关于《RedissonWatchDog机制详解与锁安全》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！