【大白话说Java面试题 第172题】【07_Redis篇】第8题：`setnx` 做分布式锁存在的问题

PDF大白话说Java面试题 — 07_Redis篇第8题setnx做分布式锁存在的问题回答核心考点SETNX是 Redis 分布式锁的鼻祖命令但大厂面试不会只问有哪些问题而是深入考察每个问题的底层原因为什么不可重入为什么需要看门狗、生产级解决方案的演进路径从 SETNX 到 Redisson 的完整升级以及Redlock 算法的争议与替代方案。面试官真正想判断的是你是否理解简单方案与生产级方案之间的鸿沟以及如何在工程实践中做出正确选型。1. 问题一SETNX EXPIRE 非原子存在死锁风险1.1 问题描述早期实现中SETNX和EXPIRE是两个独立命令SETNX lock:order:1001 unique_value# 步骤1加锁EXPIRE lock:order:100130# 步骤2设置过期时间如果执行SETNX后Redis 宕机或客户端崩溃EXPIRE未执行锁将永久存在其他线程永远无法获取形成死锁。1.2 解决方案SET 原子命令Redis 2.6.12 引入SET命令的NX和EX/PX参数将加锁和设置过期时间合并为原子操作SET lock:order:1001 unique_value NX EX30参数语义作用NXNot eXistsKey 不存在时才设置实现互斥EX seconds秒级过期30 秒后自动释放防止死锁2. 问题二锁不可重入2.1 问题描述SETNX基于简单的 Key-Value 结构无法记录锁的持有者和重入次数。同一线程在持有锁期间再次请求同一锁时会阻塞等待自己等待自己导致死锁。publicvoidmethodA(){if(setnx(lock:order:1001,threadA)){// 获取成功methodB();// 内部调用}}publicvoidmethodB(){if(setnx(lock:order:1001,threadA)){// ❌ 返回0阻塞// 永远无法执行}}2.2 解决方案Hash 结构实现可重入锁使用 Redis Hash 结构记录线程标识和重入次数# 首次加锁HSET lock:order:1001UUID:ThreadID1# 重入加锁HINCRBY lock:order:1001UUID:ThreadID1# value 变为 2# 释放锁重入次数-1HINCRBY lock:order:1001UUID:ThreadID-1# value 变为 1# 完全释放重入次数0HDEL lock:order:1001UUID:ThreadIDIF HLEN(lock:order:1001)0THEN DEL lock:order:1001Redisson 实现RLock基于 Hash 结构field为UUID:ThreadIDvalue为重入计数支持同一线程多次获取锁。3. 问题三锁不可重试3.1 问题描述SETNX获取锁失败时直接返回 0业务线程需自行实现循环重试逻辑。简单的while循环会导致忙等待CPU 空转浪费系统资源。// ❌ 错误忙等待CPU 空转while(!setnx(lock:order:1001,value)){// 空转消耗 CPU}3.2 解决方案阻塞式重试 Pub/Sub 通知Redisson 通过 Redis Pub/Sub 机制实现事件驱动的高效重试首次获取锁失败时订阅该锁的解锁频道redisson_lock__channel:{lockName}阻塞等待解锁通知或超时不消耗 CPU收到通知后再次尝试获取锁循环直到超时。// Redisson 的 tryLock 逻辑简化publicbooleantryLock(longwaitTime,longleaseTime,TimeUnitunit){longdeadlineSystem.currentTimeMillis()unit.toMillis(waitTime);LongttltryAcquire(leaseTime,unit,threadId);if(ttlnull)returntrue;// 获取成功// 订阅解锁通知频道RFutureRedissonLockEntrysubscribeFuturesubscribe(threadId);subscribeFuture.await(remaining,TimeUnit.MILLISECONDS);// 收到通知后重试while(remaining0){ttltryAcquire(leaseTime,unit,threadId);if(ttlnull)returntrue;remainingdeadline-System.currentTimeMillis();}returnfalse;}4. 问题四超时释放业务执行时间 锁过期时间4.1 问题描述如果业务执行时间超过锁的过期时间锁被自动释放其他线程获取锁后并发操作数据导致数据不一致。更危险的是原线程业务完成后执行 DEL会误删新线程的锁。时间线线程 A线程 B说明T1获取锁30秒过期——T2执行业务Full GC 50秒——T3锁自动过期获取锁成功线程 A 仍在执行T4业务完成执行 DEL—❌ 误删线程 B 的锁4.2 解决方案看门狗Watchdog自动续期Redisson 看门狗机制在锁持有期间定期续期机制说明初始过期时间30 秒lockWatchdogTimeout续期周期每 10 秒检查一次leaseTime / 3续期操作如果锁仍被当前线程持有通过 Lua 脚本将过期时间重置为 30 秒停止条件业务完成、线程中断或显式解锁RLocklockredissonClient.getLock(order:1001);lock.lock();// 不指定 leaseTime启用看门狗// 业务逻辑执行 5 分钟...lock.unlock();// 看门狗停止续期注意如果显式指定leaseTime如lock.lock(10, TimeUnit.SECONDS)看门狗不会启用10 秒后强制释放。5. 问题五主从一致性锁丢失5.1 问题描述在 Redis 主从架构中客户端 A 在主节点获取锁成功主节点尚未将锁信息同步到从节点时宕机从节点晋升为主节点客户端 B 在新主节点获取同一锁成功客户端 A 和 B 同时持有锁互斥性被破坏。5.2 解决方案Redlock 算法在 N 个独立 Redis 实例上加锁成功节点数 N/2 1 时认为获取锁成功ConfigconfignewConfig();config.useRedLock(newRedissonClientConfig(redis://node1:6379),newRedissonClientConfig(redis://node2:6379),newRedissonClientConfig(redis://node3:6379));RLocklockredisson.getRedLock(order:1001);5.3 Redlock 的争议Martin Kleppmann 指出 Redlock 存在理论缺陷质疑点说明缓解措施时钟漂移节点时钟不同步导致锁过期计算错误NTP 同步 时钟漂移补偿GC 停顿客户端 Full GC 超过锁过期时间控制 GC、增加 fencing token网络延迟获取锁的 RTT 不确定计算有效时间时扣除 RTT无 fencing token锁过期后客户端仍可能操作资源资源服务端校验 token业界共识Redlock 在稳定环境中足够可靠但极端强一致场景优先选择 ZooKeeper 或 etcd。6. 问题六缺乏锁状态监控与告警6.1 问题描述手写SETNX方案缺乏对锁状态的监控无法及时发现死锁、锁持有时间过长等异常。6.2 解决方案Redisson 监控集成监控锁的持有时间超过阈值如 10 秒触发告警监控锁 Key 数量突增可能意味着死锁看门狗续期次数过多时告警业务执行异常。7. 六种问题综合对比问题根本原因风险等级解决方案生产必备死锁SETNXEXPIRE分离两个命令非原子 致命SET NX EX原子命令✅ 必须不可重入简单 KV 无法记录持有者 高Hash 结构 重入计数✅ 必须不可重试获取失败直接返回 高Pub/Sub 事件驱动重试✅ 推荐超时释放固定过期时间无法适配业务 致命看门狗自动续期✅ 必须主从一致性主从复制延迟 高Redlock / ZooKeeper⚠️ 视场景无监控缺乏运维手段 中集成监控告警✅ 推荐8. 从 SETNX 到 Redisson 的演进路径SETNX EXPIRE有死锁风险 ↓ SET NX EX Lua DEL解决死锁和误删但功能简陋 ↓ Redisson 单节点可重入 看门狗 阻塞重试大多数场景首选 ↓ Redisson RedLock多节点多数派高可用要求 ↓ ZooKeeper / etcd极端强一致无时钟漂移风险9. 面试官追问与高分回答模板追问 1“SETNX 做分布式锁有哪些问题”低分回答“不可重入、不可重试、超时释放、主从一致性。”没有解释根本原因和解决方案高分回答SETNX做分布式锁存在六个核心问题按风险等级排序死锁风险SETNX和EXPIRE是两个独立命令非原子执行。如果中间崩溃锁永久存在。必须用SET NX EX原子命令替代。不可重入简单 KV 结构无法记录持有者和重入次数同一线程嵌套调用会死锁。需用 Hash 结构记录UUID:ThreadID和重入计数。超时释放固定过期时间无法适配业务执行时间如 Full GC。Redisson 看门狗每 10 秒自动续期彻底解决。不可重试获取失败直接返回忙等待浪费 CPU。Redisson 通过 Pub/Sub 订阅解锁通知实现事件驱动的高效重试。主从一致性主节点宕机前未同步锁信息从节点晋升后锁丢失。Redlock 算法通过多节点多数派解决但存在时钟漂移争议。无监控缺乏锁状态监控和告警。生产环境必须集成监控。总结手写 SETNX 严禁生产使用必须直接使用 Redisson 等成熟框架。追问 2“看门狗机制是怎么解决超时释放问题的”高分回答看门狗通过动态续期解决固定过期时间的局限性当调用lock.lock()不指定 leaseTime时Redisson 默认启用看门狗初始设置锁过期时间为 30 秒后台启动定时任务Netty 的 HashedWheelTimer每 10 秒检查一次锁是否仍被当前线程持有如果持有通过 Lua 脚本原子执行pexpire将过期时间重置为 30 秒业务完成调用unlock()时取消定时任务停止续期。这样即使业务执行 5 分钟锁也不会提前释放。如果显式指定 leaseTime如 10 秒看门狗不启用强制 10 秒后释放适用于执行时间确定的场景。追问 3“Redlock 算法有什么缺陷为什么有争议”高分回答Redlock 的核心缺陷来自对时钟和进程停顿的依赖时钟漂移Redlock 假设所有 Redis 节点时钟同步但实际 NTP 同步存在误差。如果节点 A 的时钟比 B 快 10 秒A 上的锁已过期B 上仍认为有效导致两个客户端同时持有锁。GC 停顿客户端获取锁后发生 Full GC停顿 40 秒而锁过期时间只有 30 秒。GC 恢复后客户端认为仍持有锁但锁已被其他线程获取导致并发操作。无 fencing tokenRedlock 没有提供单调递增的 fencing token资源服务端无法判断请求是否来自过期的锁持有者。Martin Kleppmann 的论文指出这些缺陷后业界对 Redlock 的可靠性产生质疑。实际工程中Redlock 在时钟同步、GC 可控的环境中足够可靠但极端强一致场景如金融交易应优先选择 ZooKeeper临时节点 会话绑定或 etcdLease 机制。追问 4“为什么 Redisson 用 Hash 结构而不是 String 实现可重入锁”高分回答Redisson 使用 Hash 结构HSET/HINCRBY/HDEL而非简单 String原因有三记录持有者Hash 的field存储UUID:ThreadID可以精确识别锁的持有者避免不同 JVM 实例的线程 ID 冲突。记录重入次数Hash 的value存储重入计数通过HINCRBY实现原子性的加锁/解锁计数支持同一线程多次获取锁。原子操作Lua 脚本可以原子执行hexists判断归属→hincrby修改计数→del完全释放保证线程安全。如果用 String 结构需要多个命令组合GET 判断 → INCR 计数 → DEL 释放无法保证原子性。追问 5“分布式锁的 value 为什么要用 UUID ThreadID”高分回答锁的 value 必须全局唯一用于释放锁时验证归属防止误删。使用UUID ThreadID组合的原因UUID 区分 JVM 实例同一服务的多个节点如 K8s 多个 Pod可能生成相同的线程 IDUUID 确保不同实例的标识唯一。ThreadID 区分线程同一 JVM 内不同线程的 ThreadID 不同确保同实例内线程级别的唯一性。组合后全局唯一UUID:ThreadID在分布式环境下绝对唯一释放锁时通过 Lua 脚本比对GET值与当前线程标识一致才删除。如果只用 ThreadID多实例场景下可能冲突如果只用 UUID无法区分同实例内的不同线程重入。追问 6“如果 Redis 是单节点非主从集群还需要 Redlock 吗”高分回答“单节点 Redis 不需要 Redlock因为 Redlock 的设计目标是解决主从切换导致的锁丢失问题。单节点不存在主从复制延迟锁信息只有一份不会丢失。单节点场景下Redisson 单节点锁已足够可靠配合看门狗续期即可。但单节点 Redis 本身存在单点故障风险需要通过 Redis Sentinel 或 Redis Cluster 保证高可用。Redlock 的适用场景是多个独立的 Redis 主节点非主从关系通过多数派机制容忍部分节点故障。如果只有一个 Redis 实例或一个主从集群Redlock 没有实际意义。”10. 方案选型速查表场景方案说明学习/演示SETNX EXPIRE❌ 有死锁风险严禁生产简单场景无重入SET NX EX Lua轻量但功能有限大多数生产场景Redisson 单节点可重入 看门狗 阻塞重试首选高可用要求Redisson RedLock多节点多数派容忍故障极端强一致ZooKeeper / etcd无时钟漂移会话绑定释放面试官想要的满分总结SETNX做分布式锁的问题不是有几个而是从基础命令到生产级方案的完整鸿沟。核心问题按风险排序死锁非原子命令、不可重入简单 KV 结构、超时释放固定过期时间、不可重试忙等待、主从一致性复制延迟。生产级方案必须满足五个条件原子加锁SET NX EX、可重入Hash 结构、自动续期看门狗、防误删Lua 脚本 唯一 value、高效重试Pub/Sub 事件驱动。Redisson 完整实现了这五个条件是大多数场景的首选。Redlock 算法虽有理论争议但在稳定环境中可靠性足够。极端强一致场景如金融交易应优先选择 ZooKeeper 或 etcd它们的锁释放与客户端会话绑定不存在时钟漂移风险。最后记住手写 SETNX 严禁生产使用必须直接使用 Redisson 等成熟框架。觉得对您有帮助麻烦点点关注啦您的关注是我创作的最大动力~