Redis 的“看门狗”机制，其实是 Redis 的 Java 客户端 Redisson 提供的一项核心功能。它本质上是一个分布式锁的“自动续命”机制。
它的核心作用非常明确：解决分布式锁的过期时间难以精确预估的痛点。
⚙️ 看门狗的工作原理
在没有看门狗机制之前，使用 Redis 分布式锁面临一个两难的局面：
- 如果锁的过期时间设置得太短，业务逻辑还没执行完，锁就自动释放了，导致其他线程抢锁，引发并发安全问题。
- 如果过期时间设置得太长，一旦持有锁的客户端宕机，这把锁就会长时间无法释放，造成死锁。
Redisson 的看门狗完美解决了这个矛盾，它的工作流程如下：
- 默认租期与启动：当你调用 Redisson 的
lock()方法获取锁，且没有指定过期时间（leaseTime）时，看门狗机制会自动启动。Redisson 会先给锁设置一个默认的过期时间（通常是 30 秒），并同时在后台启动一个定时任务线程（即看门狗）。 - 定时“续命”：看门狗线程会每隔一段时间（默认是锁过期时间的 1/3，即 10 秒），自动去检查并延长锁的过期时间。
- 原子性续期：为了保证安全，续期操作是通过 Lua 脚本在 Redis 服务端原子执行的。脚本会先检查当前锁的持有者是不是自己（通过 UUID 和线程 ID 校验），如果是，就将锁的过期时间重置为 30 秒。
- 任务结束：当业务逻辑执行完毕，客户端调用
unlock()释放锁时，看门狗定时任务会被取消。如果客户端直接宕机，看门狗线程也会随之消失，锁会在 30 秒后自动过期释放，不会造成死锁。
💻 实际开发中的应用
在实际开发中，使用 Redisson 的看门狗机制非常简单，核心就是不手动指定锁的过期时间。
Java (Redisson) 代码示例：
@Autowired
private RedissonClient redissonClient;public void processOrder() {RLock lock = redissonClient.getLock("order_lock");try {// 关键：不传 leaseTime 参数，或者传 -1，默认启用看门狗！// 只要业务还在跑，锁就会每10秒自动续期到30秒lock.lock(); // 执行业务逻辑，哪怕耗时超过30秒也不怕锁被释放doHeavyBusiness(); } finally {// 释放锁，同时看门狗任务也会自动停止if (lock.isHeldByCurrentThread()) {lock.unlock();}}
}
💡 避坑指南与注意事项
虽然看门狗机制非常强大，但在生产环境中使用时，有几个容易踩坑的地方需要注意：
- 手动指定过期时间会禁用看门狗：如果你调用了
lock.lock(10, TimeUnit.SECONDS)或者tryLock(waitTime, leaseTime, unit)并传入了具体的leaseTime，看门狗机制将不会生效。 - 必须在 finally 中释放锁：如果业务代码抛出异常导致没有执行
unlock()，看门狗会一直给锁续期，这把锁将永远不会过期，导致其他线程永远拿不到锁（造成资源泄漏）。 - 不适用于超长耗时任务：如果你的业务逻辑需要执行几个小时，不建议一直持有分布式锁。长时间持锁是架构设计的反模式，建议将长任务改为“提交任务+异步执行”的模式，锁只保护“提交”这个动作。
- 极端情况下的续期失败：如果客户端发生了长时间的 Full GC（Stop-The-World），看门狗线程可能无法按时发送续期指令，导致锁意外过期。此外，在 Redis 主从切换的瞬间，续期指令也可能丢失。