redis分布式锁必须启用watchdog机制防击穿，因其将锁生命周期与业务线程绑定；手动设leasetime会导致固定过期后锁被删，引发确定性并发；watchdog仅在未指定leasetime（或传-1）时启动，通过带身份校验的lua脚本每10秒（lockwatchdogtimeout/3）安全续期。
Redis分布式锁必须带Watchdog机制，否则只要业务耗时超过预设过期时间，锁就必然击穿——这不是概率问题，是确定性故障。
为什么手动设leaseTime会导致锁击穿？
你调用 tryLock(5, 30, TimeUnit.SECONDS)，看似加了30秒锁，但实际只“保命”30秒。一旦业务因GC、下游超时、网络抖动多耗几秒，Redis就会在第30秒准时删掉key。此时另一个线程调用 SETNX 成功，两个线程同时操作同一资源。
- 锁击穿不是“可能”，而是“只要发生慢路径就必现”——比如查库存+扣减+发MQ+回调支付，任意一环延迟2秒，30秒就扛不住
- 你无法靠“设更长leaseTime”解决：设120秒，万一客户端OOM挂了，锁要卡死2分钟，整个订单链路阻塞
- Redis本身不感知业务是否存活，它只认TTL；而Watchdog让锁的生命周期和业务线程绑定，这才是防击穿的本质
Watchdog续期怎么保证安全不误续？
续期不是无脑重设EXPIRE，而是带身份校验的原子操作。Redisson用Lua脚本执行：if redis.call("get", KEYS[1]) == ARGV[2] then return redis.call("pexpire", KEYS[1], ARGV[1]) else return 0 end。只有当前锁value匹配自己的threadId，才允许续期。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 避免A线程续了B线程的锁：value里存的是UUID+threadId组合，不是固定字符串
- 避免并发续期覆盖：Lua在Redis单线程中执行，GET+PEXPIRE不可分割
- 避免无限续：Watchdog线程在调用
unlock()时被显式cancel，不会残留
Watchdog默认10秒续一次，这个间隔能改吗？
能，但不建议随便动。续期间隔由 lockWatchdogTimeout 配置项决定，默认30000毫秒（即30秒租约），续期周期自动设为它的1/3（10秒）。改小（如5秒）会增加Redis QPS压力；改大（如20秒）则击穿风险上升——因为两次续期之间有20秒空窗。
- 真正该调的是
lockWatchdogTimeout本身：如果你的业务P99耗时是60秒，就把该值设为60000，续期间隔自动变成20秒 - 修改方式是在RedissonClient初始化时传入Config：
config.setLockWatchdogTimeout(60000) - 注意：这个值对所有未指定leaseTime的锁生效，不是单个锁的局部配置
什么情况下Watchdog根本不会启动？
Watchdog只在你**不传leaseTime或显式传-1**时激活。只要你写了具体数值，比如 tryLock(5, 45, TimeUnit.SECONDS)，Redisson就认为你要手动管理生命周期，直接禁用Watchdog。
- 这是最容易踩的坑：开发测试时业务快，设了45秒没问题；上线后流量一涨，45秒变瓶颈，但Watchdog根本没开
- 正确写法是
tryLock(5, -1, TimeUnit.SECONDS)，让Watchdog接管续期 - 如果真需要固定过期（比如某些幂等场景），必须自己实现心跳+续约逻辑，别依赖Redisson自动机制
Watchdog不是“锦上添花”的功能，它是把分布式锁从“尽力而为”拉到“生产可用”的关键一环。最常被忽略的点是：它只响应“未指定leaseTime”这一种触发条件，而不是根据业务耗时自动判断是否启用。
