Redisson 使用手册：从 API 误区到看门狗失效，在此终结分布式锁的噩梦

写在前面
在上一篇《分布式锁的代价与选择：为什么我们最终拥抱了Redisson？》中，我们聊到了手写 SETNX 的"茹毛饮血"时代。既然选择了 Redisson，就意味着我们已经告别了那些让人提心吊胆的死锁噩梦。
很多时候，我们以为只是调用了一个简单的 lock.lock()，但背后其实是一整套复杂的自动续期、Lua 脚本原子执行和发布订阅机制在默默支撑。
这篇文章不讲虚的，我们从常用的 API 起手，一路通过生产环境的避坑实战，最后钻进底层数据结构与 Lua 源码里，把 Redisson 彻底扒个干干净净。

一、不仅是 Lock 这么简单：核心 API 全景

Redisson 之所以受欢迎，是因为它把分布式锁封装成了我们最熟悉的 java.util.concurrent.locks.Lock 接口风格，极大地降低了学习成本。但除了最基础的 lock()，还有核心功能是你必须掌握的。
1. 基础那把锁：RLock

这是 90% 场景下的默认选择。它对应 Redis 底层的 Hash 结构。

1. RLock lock = redisson.getLock("order:1001");
2. lock.lock(); // 阻塞式等待，默认 30秒过期，自带看门狗
3. try {
4.    // 业务逻辑
5. } finally {
6.    lock.unlock();
7. }

复制代码

2. 更聪明的锁：tryLock (⚡️推荐)

在实际业务中，我们往往不希望线程无限死等，浪费资源。这里有两种常见姿势：
姿势 A：要等待 + 启用看门狗 (最常用)

只指定 waitTime，不指定 leaseTime。这是既想要非阻塞（或有限等待），又想要自动续期的最佳实践。

1. // 参数1：wait time，我只愿意排队 3秒，拿不到就走人
2. // 参数2：时间单位
3. // 重点：没传 leaseTime，所以看门狗机制会自动生效！
4. boolean res = lock.tryLock(3, TimeUnit.SECONDS);
6. if (res) {
7.    try {
8.      // 处理业务（哪怕跑 5分钟 也不怕锁过期）
9.    } finally {
10.      lock.unlock();
11.    }
12. } else {
13.    log.warn("抢锁失败，别挤了！");
14. }

复制代码

姿势 B：要等待 + 自动过期 (慎用)

指定了 leaseTime，看门狗会失效。

1. // 参数1：wait time，排队 3秒
2. // 参数2：lease time，上锁后 10秒 自动强制释放（注意：指定 leaseTime 会让看门狗失效！）
3. // 参数3：时间单位
4. boolean res = lock.tryLock(3, 10, TimeUnit.SECONDS);
6. if (res) {
7.    try {
8.      // 处理业务，必须保证在 10秒 内完成！
9.    } finally {
10.      lock.unlock();
11.    }
12. }

复制代码

3. 文明的排队：公平锁 FairLock

默认的锁是非公平的（Non-Fair），线程抢锁全靠 CPU 调度，谁快谁得。但如果你的业务要求"先来后到"（比如抢票排队），请务必使用公平锁。

1. // 内部利用 Redis 的 List（作为线程等待队列）和 Hash（作为超时记录）实现
2. RLock fairLock = redisson.getFairLock("ticket:queue");
3. fairLock.lock();

复制代码

4. 读多写少的神器：读写锁 ReadWriteLock

这个场景太经典了：商品详情页，读的人多（10000次/秒），改库存的人少（1次/秒）。如果全互斥，性能直接崩盘。

1. RReadWriteLock rwLock = redisson.getReadWriteLock("product:stock:101");
3. // 读锁：多个线程可以同时加读锁，只要没有写锁
4. rwLock.readLock().lock();
6. // 写锁：必须等所有读锁和写锁都释放了才能加，全互斥
7. rwLock.writeLock().lock();

复制代码

5. 联锁 MultiLock (原子性加多把锁)

有时候我们需要同时锁定多个资源，比如"库存"和"余额"，要么都锁住，要么都不锁，防止死锁。

1. RLock lock1 = redisson.getLock("lock:order");
2. RLock lock2 = redisson.getLock("lock:stock");
3. // 同时加锁：lock1 lock2
4. RedissonMultiLock lock = new RedissonMultiLock(lock1, lock2);
5. lock.lock();

复制代码

二、扒开底层：Hash 结构与 Lua 脚本

以下源码基于 Redisson 3.16+ 版本（目前生产环境主流版本）分析。

Redisson 为什么能实现可重入锁？为什么它比我们自己写的 SETNX 强？
答案藏在 Redis 的数据结构里。Redisson 并没有使用简单的 String 类型，而是使用了 Hash。
1. Redis 里的样子

假设我们对 order:1001 加锁，Redis 里实际存储的数据长这样：

1. KEY: order:1001
2. TYPE: Hash
4. # hash 对应 value 内容
5. {
6.     "UUID:ThreadID" : 1  # 锁的持有者 : 重入次数
7. }

复制代码

• KEY: 锁的名字。
  
• FIELD (Key): UUID:ThreadId。这里由客户端生成的唯一 UUID 加上当前线程 ID 拼接而成。为什么要加 UUID？ 因为不同服务器上的 JVM 进程 ID 可能一样，必须通过客户端启动时生成的 UUID（ConnectionManagerId）来唯一标识一个 Redisson 实例。
  
• VALUE: 1。这是重入计数器。如果同一个线程再 lock 一次，这里变成 2。
  

2. 加锁的 Lua 脚本

Redisson 为了保证一系列判断和写入是原子的，把它封装在 Lua 脚本里发给 Redis。

1. -- KEYS[1] = 锁名称
2. -- ARGV[1] = 过期时间 (默认 30000ms)
3. -- ARGV[2] = 锁持有者唯一ID (UUID:ThreadId)
5. -- 情况 1：锁根本不存在
6. if (redis.call('exists', KEYS[1]) == 0) then
7.     -- 创建 Hash，设置重入次数为 1
8.     redis.call('hincrby', KEYS[1], ARGV[2], 1);
9.     -- 设置过期时间
10.     redis.call('pexpire', KEYS[1], ARGV[1]);
11.     return nil; -- 返回 null 表示加锁成功
12. end;
14. -- 情况 2：锁存在，且持有者就是我（重入）
15. if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
16.     -- 重入次数 +1
17.     redis.call('hincrby', KEYS[1], ARGV[2], 1);
18.     -- 重新续期
19.     redis.call('pexpire', KEYS[1], ARGV[1]);
20.     return nil;
21. end;
23. -- 情况 3：锁存在，但不是我
24. -- 返回当前锁还剩多少毫秒过期，方便客户端等待
25. return redis.call('pttl', KEYS[1]);

复制代码

这段脚本完美解释了：

• 原子性：这一大坨逻辑在 Redis 里是原子执行的，不会插队。
  
• 可重入：通过 hexists 判断是不是自己，是的话就 hincrby。
  
• 互斥性：如果既不是新锁，也不是自己的锁，直接返回剩余时间，让你可以去睡一会儿再来。
  

三、拆开看门狗的黑盒：源码漫游

经常听说"看门狗"，它到底长什么样？
其实，它本质上是一个 HashedWheelTimer（时间轮） 驱动的定时任务。
1. 启动入口

当我们调用 lock() 不传时间时，最终会走到这里：

1. // RedissonLock.java
2. private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
3.     long threadId = Thread.currentThread().getId();
4.     Long ttl = tryAcquire(leaseTime, unit, threadId);
6.     // 如果 lock 成功，ttl 会返回 null
7.     if (ttl == null) {
8.         return;
9.     }
10.    
11.     // 如果失败，会订阅一个 Redis Channel，等待锁释放的消息（不用死循环空转）
12.     // ... 省略订阅逻辑
13. }

复制代码

关键在 tryAcquireAsync 里：

1. private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId) {
2.     if (leaseTime != -1) {
3.         // 如果你传了时间，就按你的时间走，不启动看门狗
4.         return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
5.     }
6.    
7.     // 没传时间（leaseTime = -1）
8.     // 先设置默认 30秒 过期
9.     RFuture<Long> ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
10.    
11.     // 加锁成功后，开启续期任务
12.     ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
13.         if (e == null) {
14.            if (ttlRemaining == null) {
15.                // 重点：启动定时续期
16.                scheduleExpirationRenewal(threadId);
17.            }
18.         }
19.     });
20.     return ttlRemainingFuture;
21. }

复制代码

2. 续期的无限套娃

scheduleExpirationRenewal 最终会调用 renewExpiration：

1. private void renewExpiration() {
2.     // 这里的 1/3 是硬编码的规则
3.     // 默认 lockWatchdogTimeout 是 30000ms
4.     // 所以每 10000ms 执行一次
5.     Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
6.         @Override
7.         public void run(Timeout timeout) throws Exception {
8.             
9.             // 执行 Lua 脚本，把 ttl 重新刷回 30秒
10.             RFuture<Boolean> future = renewExpirationAsync(threadId);
11.             
12.             future.onComplete((res, e) -> {
13.                 if (res) {
14.                     // 如果续期成功，这就形成了递归调用：自己调自己
15.                     renewExpiration();
16.                 }
17.             });
18.         }
19.     }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
20. }

复制代码

核心逻辑总结：

• 三分之一原则：每隔锁超时时间的 1/3（默认10秒），检查一次。
  
• 无限递归：只要检查到锁还在，就重置过期时间，并注册下一次检查。
  
• 生死绑定：这个任务跑在客户端进程里，如果客户端宕机，任务停止，Redis 里的锁在 30秒 后自动过期。
  

四、我在生产环境踩过的坑：避坑实战

API 谁都会调，但能避开坑的才是老司机。这六个坑，都是真金白银换来的教训。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

这个有用。

谢谢楼主提供！

感谢发布原创作品，程序园因你更精彩

感谢发布原创作品，程序园因你更精彩

谢谢分享，试用一下

这个有用。

懂技术并乐意极积无私分享的人越来越少。珍惜

这个好，看起来很实用

感谢分享

懂技术并乐意极积无私分享的人越来越少。珍惜

热心回复！

前排留名，哈哈哈

新版吗？好像是停更了吧。

收藏一下   不知道什么时候能用到

分享、互助 让互联网精神温暖你我