Redisson的RLock默认启用Watchdog自动续期，仅当调用lock()（不传leaseTime）时启动；若调用lock(long, TimeUnit)则禁用Watchdog，锁严格按设定时间过期，不续期。
Redisson 的 RLock 默认就启用 Watchdog 自动续期，只要你不显式传入过期时间（即调用 lock() 而非 lock(long, TimeUnit)），它就会在加锁成功后自动启动续期机制——不需要你手动写定时任务或轮询逻辑。
为什么 lock() 和 lock(long, TimeUnit) 行为完全不同
这是最容易混淆的点：两种加锁方式触发的续期逻辑完全隔离。
-
lock()：不指定超时时间，Redisson 会设一个默认 TTL（lockWatchdogTimeout，默认 30 秒），并立即启动 Watchdog。后续每次续期都把 TTL 刷新为该值，只要线程还活着、客户端没 shutdown，锁就不会过期 -
lock(long, TimeUnit)：你指定了固定过期时间，Watchdog 就不会启动。锁到期后 Redis 自动删除，不管业务是否执行完 - 混用风险：若在
lock(10, TimeUnit.SECONDS)后又调用tryLock()或误以为 watchdog 还在工作，会导致锁提前释放、并发冲突
Watchdog 续期失败的三个典型信号
Watchdog 不是“永远可靠”，它依赖客户端存活、网络稳定和 Redis 响应及时。以下现象说明续期可能已中断：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 日志中频繁出现
Can't update lock或Unable to send unlock message—— 通常是 Redis 响应超时或连接断开 - 锁 key 在 Redis 中的 TTL 稳定下降（如从 30s → 20s → 10s → 0），且未被重置 —— Watchdog 定时任务未执行或 Lua 校验失败
- 业务日志显示“锁已释放但任务仍在执行”，紧接着出现重复处理（如双订单、库存超扣）—— 续期失效后其他节点抢到了锁
必须调整的两个关键配置项
Watchdog 默认参数适合中小规模场景，高并发或长耗时任务下必须按需调优：
-
lockWatchdogTimeout：决定续期目标 TTL 和触发周期（约 1/3 值）。若业务平均耗时 90 秒，建议设为90000（90 秒），否则续期间隔太短、压力大，或间隔太长、易过期 -
lockWatchdogBatchSize：默认 100，表示每次续期任务最多刷新 100 把锁。若单机持有锁数常超 200（如批量导出启了 300 个线程各持一把），部分锁会错过本轮续期。可设为300，但需确认 Netty 时间轮调度不堆积
Watchdog 的可靠性高度依赖客户端进程生命周期——一旦 JVM 退出、线程被 kill、或 RedissonClient 被 close，续期立刻停止，且不会通知 Redis 主动删锁。这意味着锁释放完全交给 TTL 自然过期，而这个窗口期就是数据不一致的风险期。
