深入解析 Redisson 分布式锁核心原理与源码实现

等待与通知机制

如果加锁失败，Redisson 不会简单地轮询重试，而是利用 Redis 的 Pub/Sub 机制进行通知。

1. 订阅频道：线程获取不到锁时，会订阅一个特定的 Channel（例如 redisson_lock__channel__{myLockKey}）。
2. 阻塞等待：线程阻塞在该频道的监听上。
3. 收到通知：当其他线程释放锁时，会向该频道发布一条消息。订阅者收到消息后被唤醒，再次尝试获取锁。

这种机制避免了无效的空转，显著提升了性能。

看门狗机制（Watchdog）

为了防止业务执行时间超过锁的过期时间导致锁自动释放，Redisson 引入了看门狗机制。

• 默认行为：如果不指定 leaseTime（锁的有效期），Redisson 会自动启动看门狗。
• 续期策略：看门狗是一个后台定时任务，每隔 leaseTime / 3 的时间，就会尝试刷新一次 Key 的过期时间。
• 停止条件：当线程释放锁时，看门狗任务也会随之停止。

这意味着只要持有锁的线程还在运行，锁就不会因为超时而被误删，除非显式设置了 leaseTime。

解锁流程

解锁同样依赖 Lua 脚本保证原子性，主要逻辑如下：

1. 校验所有权：检查当前线程是否是锁的持有者（对比 UUID 和 ThreadID）。
2. 重入处理：如果是重入锁，将计数器减 1。只有当计数器归零时，才真正删除 Key。
3. 发布通知：删除 Key 后，向订阅频道发布解锁消息，唤醒等待的线程。

public void unlock() {
    connectionManager.write(getName(), new SyncOperation<Object, Void>() {
        @Override
        public Void execute(RedisConnection<Object, Object> connection) {
            LockValue lock = (LockValue) connection.get(getName());
            if (lock != null) {
                LockValue currentLock = new LockValue(id, Thread.currentThread().getId());
                if (lock.equals(currentLock)) {
                    if (lock.getCounter() > 1) {
                        lock.decCounter();
                        connection.set(getName(), lock);
                    } else {
                        unlock(connection);
                    }
                } else {
                    throw new IllegalMonitorStateException("Attempt to unlock lock, not locked by current id");
                }
            }
            return null;
        }
    });
}

总结

Redisson 通过结合 Redis 的数据结构特性与 Netty 的异步通信能力，提供了一个健壮且易用的分布式锁方案。

优点：

• 符合 JDK Lock 接口规范，开发成本低。
• 支持可重入、超时自动释放及看门狗续期。
• 利用 Pub/Sub 减少空转，性能优于简单轮询。

注意点：

• 依赖 Redis 单点，需考虑 Redis 集群的高可用配置。
• 看门狗机制会增加额外的网络开销，对于短耗时任务可能不适用。
• 解锁失败时会有重试机制，但极端情况下仍需人工介入排查。

理解这些底层原理，能帮助我们在生产环境中更好地配置和使用 Redisson，避免因锁机制不当引发的线上故障。