看门狗机制原理和应用

Redis 的“看门狗”机制，其实是 Redis 的 Java 客户端 Redisson 提供的一项核心功能。它本质上是一个分布式锁的“自动续命”机制。

它的核心作用非常明确：解决分布式锁的过期时间难以精确预估的痛点。

⚙️ 看门狗的工作原理

在没有看门狗机制之前，使用 Redis 分布式锁面临一个两难的局面：

• 如果锁的过期时间设置得太短，业务逻辑还没执行完，锁就自动释放了，导致其他线程抢锁，引发并发安全问题。
• 如果过期时间设置得太长，一旦持有锁的客户端宕机，这把锁就会长时间无法释放，造成死锁。

Redisson 的看门狗完美解决了这个矛盾，它的工作流程如下：

1. 默认租期与启动：当你调用 Redisson 的 lock() 方法获取锁，且没有指定过期时间（leaseTime）时，看门狗机制会自动启动。Redisson 会先给锁设置一个默认的过期时间（通常是 30 秒），并同时在后台启动一个定时任务线程（即看门狗）。
2. 定时“续命”：看门狗线程会每隔一段时间（默认是锁过期时间的 1/3，即 10 秒），自动去检查并延长锁的过期时间。
3. 原子性续期：为了保证安全，续期操作是通过 Lua 脚本在 Redis 服务端原子执行的。脚本会先检查当前锁的持有者是不是自己（通过 UUID 和线程 ID 校验），如果是，就将锁的过期时间重置为 30 秒。
4. 任务结束：当业务逻辑执行完毕，客户端调用 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();
        }
    }
}

💡 避坑指南与注意事项

虽然看门狗机制非常强大，但在生产环境中使用时，有几个容易踩坑的地方需要注意：

1. 手动指定过期时间会禁用看门狗：如果你调用了 lock.lock(10, TimeUnit.SECONDS) 或者 tryLock(waitTime, leaseTime, unit) 并传入了具体的 leaseTime，看门狗机制将不会生效。
2. 必须在 finally 中释放锁：如果业务代码抛出异常导致没有执行 unlock()，看门狗会一直给锁续期，这把锁将永远不会过期，导致其他线程永远拿不到锁（造成资源泄漏）。
3. 不适用于超长耗时任务：如果你的业务逻辑需要执行几个小时，不建议一直持有分布式锁。长时间持锁是架构设计的反模式，建议将长任务改为“提交任务+异步执行”的模式，锁只保护“提交”这个动作。
4. 极端情况下的续期失败：如果客户端发生了长时间的 Full GC（Stop-The-World），看门狗线程可能无法按时发送续期指令，导致锁意外过期。此外，在 Redis 主从切换的瞬间，续期指令也可能丢失。