目录
[二、笨办法 vs 聪明办法](#二、笨办法 vs 聪明办法)
[聪明办法：Redisson 的"看门狗"](#聪明办法：Redisson 的“看门狗”)
一句话总结 ：
看门狗 = 一个会自动给锁"续命"的小助手，只要你还在干活，它就保证你的锁不会过期！
一、问题来了：锁，怎么突然没了？
想象一下这个场景：
你正在厨房炒菜（执行业务逻辑），为了防止别人进来打翻锅，你锁上了厨房门（获取分布式锁）。
但你设了个 30 秒自动解锁（TTL = 30s）------这是为了防止你万一晕倒了，别人永远进不来。
结果......你这道菜要炒 60 秒 ！
刚到第 31 秒，门自动开了 ！
这时你老婆以为你炒完了，推门进来拿酱油------砰！油锅打翻，厨房起火！🔥
这就是分布式系统中的经典问题：
业务还没跑完，锁却过期了，导致多个线程同时操作，数据乱成一锅粥！
二、笨办法 vs 聪明办法
笨办法：手动延长锁时间
- 你预估业务要 60 秒，就设 TTL = 120 秒。
- 但万一网络卡顿，跑了 150 秒？还是可能出事。
- 而且很多业务根本没法预估时间（比如用户上传文件）。
聪明办法：Redisson 的"看门狗"
Redisson 说："别猜了，我来盯着你！"
它干了这么一件事：
只要你还在厨房里（线程还活着），我就每隔 10 秒帮你把门锁重新设成 30 秒！
这样，哪怕你炒 10 分钟，门也一直锁着；
一旦你离开厨房（释放锁或程序崩溃），我就不再续命，30 秒后自动开门------安全又省心！
三、看门狗是怎么工作的？
我们用代码说话：
RLock lock = redisson.getLock("kitchen_door");
// 没写过期时间 → 启动看门狗！
lock.lock();
try {
// 炒菜（业务逻辑）
cookFor(60_000); // 模拟60秒
} finally {
lock.unlock(); // 主动开门，看门狗停止
}背后发生了什么？
| 时间 | 动作 |
|---|---|
| T=0s | 加锁，Redis 中 kitchen_door 的 TTL = 30 秒 |
| T=10s | 看门狗检查：你还在炒菜吗？→ 是 → TTL 重置为 30 秒 |
| T=20s | 再次检查 → 还在 → TTL 又重置为 30 秒 |
| T=30s | ......持续续命 |
| T=60s | 你调用 unlock() → 删除锁，看门狗下班 |
默认规则：
- 初始 TTL = 30 秒
- 续期间隔 = 每 10 秒（即 TTL 的 1/3）
四、重要前提：什么时候才启动看门狗？
只有这一种情况：
lock.lock(); // 没有传 leaseTime 参数！如果你写了：
lock.lock(10, TimeUnit.SECONDS); // 明确指定10秒过期那 Redisson 就会说："好，10秒后自动开锁，我不插手！" → 看门狗不会启动！
所以，想用看门狗，就别手动设过期时间。
五、为什么叫"看门狗"？
因为它的行为就像一只忠诚的狗🐶：
- 主人（你的线程）在家 → 它守着门，不让外人进；
- 主人一直没出门 → 它不断加固门锁；
- 主人出门了（unlock）→ 它就休息；
- 主人突然消失（JVM 崩溃）→ 它等 30 秒，确认主人回不来了，才允许别人进门。
既防止死锁，又保证安全。
六、总结：记住这三点
- 看门狗 = 自动续期锁的后台任务；
- 只在
lock()（无参数）时启用； - 只要你的代码还在跑，锁就永远不会过期！