Java面试——Redis分布式锁的实现方案_技术教程

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);
    }
}

注意点：