redisson watchdog仅在leasetime为-1或null时启用，显式设置正数租期会禁用看门狗；lockwatchdogtimeout决定续期间隔（/3）和死锁容忍上限，需根据业务耗时合理配置。
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 延迟稍高就会导致续期失败，锁提前释放。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 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()，看门狗还在傻等，但锁早已丢失——此时续期请求会失败，锁进入静默过期状态。
