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 缓存和数据结构管理技能。通过自然语言操作 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 自然过期,而这个窗口期就是数据不一致的风险期。










