Redisson Watchdog 为什么需要续租，何时续租？
未标记
考查重点：锁租期与自动续约。任务时长不定时 Watchdog 在租期到前续租，避免业务未完锁先释放；核是否采用自动续约模式及失联后的过期行为
本题目录
参考答案
核心回答
Watchdog 用来在任务耗时不确定时持续延长锁租约，降低业务尚未完成、锁却先过期而让另一个执行者进入的风险。它会在租约到期之前安排续约，不是等锁过期后再把锁“续回来”。锁一旦过期，互斥资格可能已经交给别人。
Redisson 普通 RLock 在未指定固定 leaseTime 的获取方式下使用看门狗；指定明确租期的调用通常按固定到期处理，不能再假定看门狗替它续约。
什么时候续，什么时候停
官方配置中 lockWatchdogTimeout 默认是 30 秒。以固定版本 Redisson 3.52.0 的实现为例，续约任务按内部租期的约三分之一调度，默认相当于约 10 秒发起一次续约，并把仍属于本持有者的锁 TTL 延长。这里是调度间隔，不能理解为任何负载下都精确在该时刻成功。
获取成功后注册续约任务，正常解锁时清理相应续约状态；客户端进程退出后无法继续发起续约，服务端锁最终会到期。可重入锁还涉及重入计数，不能把每次 unlock 都理解为立刻删除整个锁。
续约需要校验锁的所有者，避免把别人的锁延期。解锁同样不能无条件删除 Key；当锁已经过期并被别人获取时，旧线程不再拥有解锁资格。
看门狗不能保证什么
长时间 GC、进程暂停、网络分区或 Redis 故障都可能让续约来不及完成。旧任务恢复后仍可能继续写业务数据，所以续约机制不等于任意故障下严格互斥，更不等于分布式事务。
重要写入可以结合数据库条件更新、唯一约束、版本号或由资源端原子校验的 fencing token。业务请求本身也要幂等，防止超时重试造成重复副作用。
常见追问
看门狗是否知道业务一直有进展？ 通常续约反映的是客户端和锁续约机制仍在运转，并不证明业务没有卡死。任务还需要独立的超时、进度和失败恢复策略。
把租期设置得特别长就够了吗？ 长租期降低过早释放概率，却会拖慢故障后的接管；固定租期与续约都应结合任务时间、暂停风险和业务恢复要求设计。
参考资料
- 国内：JavaGuide / Snailclimb：分布式锁入门：租约和资源回收部分说明自动续期要解决的过早释放问题，以及旧执行者迟到写的风险。
- 国内：JavaGuide / Snailclimb：分布式锁实现方案：看门狗部分说明租约机制怎样对应 Redisson API；具体版本的续租细节需结合相应源码阅读。
- 国内：JavaGuide / Snailclimb：分布式协调：Lease 与 Fencing：采用旧客户端暂停后恢复的例子，解释正文中续租失败后仍需资源端版本或 fencing 保护的原因。
- 国外：Redisson：Locks and synchronizers：官方锁语义说明未指定固定租期时的续约机制，以及解锁必须由持有者完成。
- 国外：Martin Kleppmann：How to do distributed locking：借鉴暂停恢复与 token 检验过程，说明正文中看门狗无法独自阻止旧持有者继续修改共享资源，以及资源端校验的用途。
