本文介绍了在SpringBoot应用中基于Redis+Redisson的分布式锁的基本使用，以及Redisson分布式锁的看门狗机制。
1 添加相关Maven依赖
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-data-redisartifactId>
dependency>
<dependency>
<groupId>org.apache.commonsgroupId>
<artifactId>commons-pool2artifactId>
dependency>
<dependency>
<groupId>org.redissongroupId>
<artifactId>redisson-spring-boot-starterartifactId>
<version>3.18.0version>
dependency>
本文的SpringBoot版本为2.7.18，对应最新的redisson版本为3.18.0。
2 Redisson分布式锁的基本使用
lock():
@Service
public class TicketService {
@Resource
private RedissonClient redissonClient;
private void createTicket() {
// 获取锁，"lock:createTicket"为锁住的资源名，用于区分不同锁
RLock lock = redissonClient.getLock("lock:createTicket");
lock.lock(); // 阻塞等待加锁
try {
// 加锁执行的代码
doCreateTicket();
} finally {
if (lock.isLocked()) {
lock.unlock(); // 释放锁
}
}
}
}
tryLock():
// 模拟集群部署时的多实例并发问题
public void runTask() {
// 加锁实现任务的串行，防止同时执行
RLock lock = redissonClient.getLock("lock:taskName");
if (lock.tryLock()) { // 尝试获取锁，获取不到直接结束
try {
doRunTask();
} finally {
lock.unlock(); // 释放锁
}
}
}
3 看门狗机制
Redisson 的 看门狗机制（Watchdog Mechanism） 是其分布式锁功能中最核心、最强大的特性之一，它解决了传统分布式锁中 “锁过期但业务未执行完” 的经典问题。
一、问题背景：为什么需要看门狗？
假设你用 Redis 实现了一个简单的分布式锁：
SET lock_key my_instance NX EX 30
- 设置一个 30 秒过期的锁。
- 如果业务逻辑执行时间 超过 30 秒，锁自动过期。
- 此时另一个实例可以获取锁 → 出现 两个实例同时持有锁 → 锁失效！
二、Redisson 看门狗机制（Watchdog）是什么？
Redisson 的看门狗是一个 自动续期机制：
工作流程图解
线程A获取锁（lock()）
↓
Redisson 启动看门狗（后台线程）
↓
看门狗每 10 秒检查一次（默认）
↓
如果线程A仍持有锁 → 执行 EXPIRE lock_key 30
↓
锁的 TTL 重新设置为 30 秒
↓
直到线程A调用 unlock() → 看门狗停止，锁被删除
三、关键参数（默认值）
| 参数 | 值 | 说明 |
|---|---|---|
| 锁默认超时时间（leaseTime） | 30 秒 | lock() 不传参时的 TTL |
| 看门狗检查间隔 | 10 秒 | 30 * 1/3 ≈ 10 秒 |
| 续期命令 | EXPIRE lock_key 30 | 重置 TTL |
四、代码示例
RedissonClient redisson = Redisson.create(config);
RLock lock = redisson.getLock("my:lock");
// 获取锁（默认 30 秒超时，看门狗自动续期）
lock.lock();
try {
// 执行业务逻辑（可能耗时 1 分钟）
Thread.sleep(60_000);
System.out.println("业务执行完成");
} finally {
// 释放锁 → 看门狗停止，锁被删除
lock.unlock();
}
在这个例子中：
- 即使业务执行了 60 秒，锁也不会提前释放。
- 看门狗会在第 10 秒、20 秒、30 秒、40 秒、50 秒时自动续期。
- 最终
unlock()被调用，锁被删除。
五、看门狗如何避免续期风暴？
Redisson 使用了 单例看门狗 + 懒启动 策略：
- 多个锁共享同一个看门狗调度器。
- 每个锁的续期任务独立，但调度是高效的。
- 只有持有锁的线程才启动续期任务。
六、什么情况下看门狗不会工作？
| 场景 | 说明 |
|---|---|
使用 lock(long, TimeUnit) 并指定 leaseTime 大于 0 | 如lock.lock(10, SECONDS) 会禁用看门狗 |
| JVM 宕机或线程崩溃 | 看门狗线程也停止 → 锁会在 TTL 后自动释放（安全） |
| Redis 宕机 | 依赖 Redis 高可用（如哨兵、集群） |
| 网络分区 | 持有锁的节点失联 → 锁最终过期（遵循 CP 模型） |
七、总结
| 特性 | 说明 |
|---|---|
| 核心价值 | 实现“只要线程活着，锁就不会过期” |
| ️ 自动续期 | 每 1/3 TTL 时间自动 EXPIRE |
| ️ 防误删 | 结合 threadId + UUID 唯一标识锁 |
| 无需预估时间 | 业务执行多久都不怕锁过期 |
| 推荐使用 | lock() 而不是 tryLock() 或带超时的 lock(timeout) |
这是 Redisson 分布式锁 高可用、易用、安全 的关键所在。
A 参考内容
- Redis 分布式锁的基础原理
- Redisson的看门狗watchDog机制
- Redisson的看门狗策略——保障Redis数据安全与稳定的机制
- redisson中的看门狗机制总结