Java面试——Redis分布式锁的实现方案

日期：2026-01-19 00:00 / 作者：星降

SETNX+EXPIRE不能直接作分布式锁，因二者非原子操作，存在死锁和主从不一致风险；必须用SET的NX+EX选项加唯一value，并用Lua脚本校验后解锁。

为什么 setnx + expire 不能直接用作分布式锁

因为 SETNX 和 EXPIRE 是两个独立命令，中间存在窗口期：如果执行完 SETNX 返回 1，但还没来得及执行 EXPIRE 就发生进程崩溃或网络中断，这个锁就永远不释放了——变成死锁。

更隐蔽的问题是：Redis 主从异步复制下，主节点写入成功后挂掉，从节点升主，但锁信息可能没同步过去，导致多个客户端同时拿到“同一个锁”。

必须用原子操作保证“设值 + 过期”一步完成，例如 SET key value EX seconds NX
value 不能固定（比如都用 "1"），得是唯一标识（如 UUID 或线程 ID + 时间戳），否则解锁时无法判断是不是自己加的锁
解锁不能简单用 DEL，否则可能误删别人持有的锁；必须用 Lua 脚本先校验 value 再删除

如何安全地加锁和解锁（Java + Jedis 示例）

核心是两处原子性：加锁靠 SET 命令的 NX EX 选项；解锁靠 Lua 脚本防止误删。Jedis 本身不封装这些逻辑，得自己写。

public class RedisLock {
    private static final String LOCK_SUCCESS = "OK";
    private static final Long RELEASE_SUCCESS = 1L;

    // 加锁，返回 value（即锁标识），失败返回 null
    public String tryLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
        String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);
        if (LOCK_SUCCESS.equals(result)) {
            return requestId;
        }
        return null;
    }

    // 解锁：Lua 脚本确保只有自己的锁才被删
    private static final String UNLOCK_SCRIPT = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";

    public boolean unlock(Jedis jedis, String lockKey, String requestId) {
        Object result = jedis.eval(UNLOCK_SCRIPT, Collections.singletonList(lockKey), Collections.singletonList(requestId));
        return RELEASE_SUCCESS.equals(result);
    }
}

注意点：

requestId 必须全局唯一，建议用 UUID.randomUUID().toString()，不要用时间戳或纯数字
不要在 finally 块里无条件 unlock——如果加锁失败，unlock 会删掉别人正在用的锁
Jedis 连接要支持事务/eval，且连接池配置需合理，避免锁未释放时连接被回收

Redission 的看门狗（WatchDog）机制是怎么回事

Redission 默认加锁 30 秒，但如果你的业务执行超过 30 秒，又没手动续期，锁会被自动释放。WatchDog 就是解决这个问题的：它会在锁剩余时间过半（默认 15 秒）时，自动用新过期时间（仍是 30 秒）延长锁有效期，只要客户端还活着且没主动 unlock。

这个机制依赖心跳线程，默认每 10 秒检查一次。但它只在使用 RLock.lock() 无参方法时生效；如果传了超时时间（如 lock(10, TimeUnit.SECONDS)），WatchDog 就不启动。

WatchDog 只对 Redission 自己获取的锁有效，你用原生命令加的锁它管不了
如果业务线程卡住（比如 full gc 或阻塞 IO），心跳发不出，锁仍会被释放——这不是 bug，是设计使然
关闭 WatchDog：构造 Config 时调用 setLockWatchdogTimeout(0)，但之后必须自己 handle 续期

Redis 集群下 RedLock 是否真有必要

RedLock（多节点独立加锁）理论上能提升容错，但 Martin Kleppmann 等人指出它在时钟漂移、GC 暂停等现实场景下并不能真正保证安全性。Redis 官方文档也已弱化 RedLock 推荐，转而建议优先用单节点 Redis（配合高可用架构）+ 正确的客户端实现。

实际项目中，95% 以上的分布式锁需求，用单个 Redis 实例 + 原子 set + Lua 解锁 + 合理超时，再配合服务降级（如锁失败走本地缓存或直接拒绝），比硬上 RedLock 更稳定、更易维护。

RedLock 要求至少 3 个独立 Redis 节点，运维成本翻倍
每次加锁要向多数节点发起请求，延迟高、失败路径复杂
若用 JedisCluster，它的哈希槽重定向机制和 RedLock 的“
逐节点尝试”逻辑容易冲突，出问题难排查

除非你的业务真的要求“Paxos 级别”的强一致性，否则别为“听起来更安全”而引入 RedLock。