Redisson Watchdog 为什么需要续租，何时续租？

核心回答

Watchdog 用来在任务耗时不确定时持续延长锁租约，降低业务尚未完成、锁却先过期而让另一个执行者进入的风险。它会在租约到期之前安排续约，不是等锁过期后再把锁“续回来”。锁一旦过期，互斥资格可能已经交给别人。

Redisson 普通 RLock 在未指定固定 leaseTime 的获取方式下使用看门狗；指定明确租期的调用通常按固定到期处理，不能再假定看门狗替它续约。

什么时候续，什么时候停

官方配置中 lockWatchdogTimeout 默认是 30 秒。以固定版本 Redisson 3.52.0 的实现为例，续约任务按内部租期的约三分之一调度，默认相当于约 10 秒发起一次续约，并把仍属于本持有者的锁 TTL 延长。这里是调度间隔，不能理解为任何负载下都精确在该时刻成功。

获取成功后注册续约任务，正常解锁时清理相应续约状态；客户端进程退出后无法继续发起续约，服务端锁最终会到期。可重入锁还涉及重入计数，不能把每次 unlock 都理解为立刻删除整个锁。

续约需要校验锁的所有者，避免把别人的锁延期。解锁同样不能无条件删除 Key；当锁已经过期并被别人获取时，旧线程不再拥有解锁资格。

看门狗不能保证什么

长时间 GC、进程暂停、网络分区或 Redis 故障都可能让续约来不及完成。旧任务恢复后仍可能继续写业务数据，所以续约机制不等于任意故障下严格互斥，更不等于分布式事务。

重要写入可以结合数据库条件更新、唯一约束、版本号或由资源端原子校验的 fencing token。业务请求本身也要幂等，防止超时重试造成重复副作用。

常见追问

看门狗是否知道业务一直有进展？ 通常续约反映的是客户端和锁续约机制仍在运转，并不证明业务没有卡死。任务还需要独立的超时、进度和失败恢复策略。

把租期设置得特别长就够了吗？ 长租期降低过早释放概率，却会拖慢故障后的接管；固定租期与续约都应结合任务时间、暂停风险和业务恢复要求设计。

参考资料