介绍一下Redisson的看门狗机制

如果过期时间太短，业务没执行完锁就释放了，会导致并发安全问题；如果过期时间太长（甚至不设过期时间），万一客户端宕机了，锁就会一直留在 Redis 里形成死锁。

一、 核心工作原理

看门狗的核心逻辑可以概括为：自动续期，防止提前失效。

1. 触发条件

并不是所有的 Redisson 锁都会启动看门狗。

• 启动：只有当你加锁时没有显式指定leaseTime（或者设为 -1）时，看门狗才会启动。
• 不启动：如果你写的是lock.lock(10, TimeUnit.SECONDS)，Redisson 会认为你很清楚业务耗时，到期即删，不再续期。

2. 默认参数

• 默认生存时间：lockWatchdogTimeout默认为30 秒。
• 续期频率：每隔lockWatchdogTimeout / 3的时间（即10 秒）检查一次。

3. 续期过程

当锁成功获取后，Redisson 会在后台启动一个定时任务（基于 Netty 的HashedWheelTimer时间轮）：

1. 每隔 10 秒，看门狗会检查主线程是否还持有这把锁。
2. 如果线程依然存活且未主动释放锁，它会向 Redis 发送一段Lua 脚本。
3. 该脚本负责将该 Key 的过期时间重新重置为 30 秒。

二、 如果客户端宕机了怎么办？

这正是看门狗机制的高明之处：

• 自动释放：如果持有锁的 Java 进程突然崩溃或断电，看门狗这个后台线程自然也就随之消失了。
• 死锁预防：此时没有人再给 Redis 里的 Key 续期，那么最多过了 30 秒（默认值），Redis 就会自动删除这个 Key，其他等待的线程就能重新竞争锁。

三、 源码层面的实现逻辑

在 Redisson 的tryLockInnerAsync方法中，加锁成功后会调用scheduleExpirationRenewal：

// 伪代码逻辑privatevoidrenewExpiration(){// 1. 创建一个延时任务Timeouttask=timer.newTimeout(timeout->{// 2. 异步执行续期 Lua 脚本CompletionStage<Boolean>future=renewExpirationAsync(threadId);future.whenComplete((res,e)->{if(res){// 3. 如果续期成功，递归调用自身，实现循环续期renewExpiration();}});},internalLockLeaseTime/3,TimeUnit.MILLISECONDS);}

四、 优缺点分析

优点

• 业务解耦：开发者不需要预估业务执行时间，避免了因 GC 抖动或网络延迟导致的锁提前失效。
• 安全防死锁：结合了 Redis 的 TTL 机制和存活检查。

缺点与风险

• 性能开销：虽然 Lua 脚本很轻量，但大量长耗时任务会导致频繁的续期网络请求。
• 依然存在“异步复制”问题：看门狗解决了单机 Redis 上的锁过期问题，但如果 Redis 是主从架构，Master 宕机且锁未同步到 Slave，依然可能发生锁丢失（这需要配合Redlock算法或使用ZooKeeper来解决）。

总结

看门狗就像是一个**“心跳监测器”**。它在不阻塞主业务逻辑的前提下，确保了只要你的程序还在运行，锁就永远不会过期；而一旦你的程序“断气”了，锁也能在短时间内自动归还。

在你的微服务项目中，如果涉及到长时间的任务处理（比如复杂的报表生成或跨系统的 AIGC 内容处理），看门狗是保证分布式锁可靠性的必备工具。

关于 Redisson 的锁，你是否还关注过它的公平锁或者**红锁（Redlock）**的具体应用场景？