，谁才是最终答案？)
🔒 前言：面试官的陷阱
“请手写一个 Redis 分布式锁。”
如果你直接写了redis.setnx(key, 1)，面试官可能会让你直接回家等通知。
为什么？
- 如果服务器宕机，锁没释放怎么办？（死锁）
- 如果你加了过期时间，但业务执行时间超长怎么办？（锁失效）
- 如果你释放了别人的锁怎么办？（并发安全）
今天，我们像剥洋葱一样，从青铜到王者，拆解分布式锁的7 种进化形态。
👶 第一阶段：青铜时代 (漏洞百出)
写法一：裸奔的setnx
// 1. 抢锁if(redis.setnx(lockKey,1)==1){try{// 业务逻辑...}finally{// 2. 释放锁redis.del(lockKey);}}- 致命死穴：如果业务逻辑执行到一半，服务器宕机了/重启了，
finally没执行，锁永远删不掉。造成永久死锁！
写法二：setnx+expire
if(redis.setnx(lockKey,1)==1){redis.expire(lockKey,30);// 补一个过期时间try{...}finally{redis.del(lockKey);}}- 致命死穴：
setnx和expire是两条命令，不是原子的。如果刚 setnx 完，网线被拔了，expire 没执行，依然死锁！
🥈 第二阶段：白银时代 (原子性解决)
写法三：SET NX PX(Redis 2.6.12+)
Redis 官方终于看不下去了，把设置值和过期时间合并成了一条命令。
// 原子命令：SET lockKey requestId NX PX 30000Stringresult=jedis.set(lockKey,requestId,"NX","PX",30000);if("OK".equals(result)){try{...}finally{redis.del(lockKey);}}- 潜在问题：解决了死锁，但还有一个大坑——误删锁。
- A 拿到锁，过期时间 30s。
- A 业务卡顿，跑了 40s。此时锁自动过期，B 拿到了锁。
- A 跑完了，执行
finally里的del，把 B 的锁给删了！ - C 趁虚而入，B 和 C 同时在跑，线程不安全。
写法四：UUID + Lua 脚本 (校验身份)
为了防止删错锁，我们在 Value 里存一个 UUID (Client ID)。删除前判断一下：这是不是我的锁？
-- Lua 脚本保证原子性ifredis.call('get',KEYS[1])==ARGV[1]thenreturnredis.call('del',KEYS[1])elsereturn0end- 依然痛点：虽然不删别人的锁了，但 A 的业务还没跑完锁就过期了，A 依然是在“裸奔”（并发执行）。我们需要**“锁续期”**。
🥇 第三阶段：黄金时代 (Redisson 看门狗)
写法五：手动写守护线程 (太累)
你自己写一个 Timer，每隔 10秒 检查一下，如果 A 还在跑，就给锁续命。
但是，写好这个多线程逻辑极其复杂，很容易由“解决死锁”变成“制造死锁”。
写法六：Redisson (工业级标准)
Redisson是 Redis 官方推荐的 Java 客户端，它内置了一个神器——看门狗 (WatchDog)。
使用代码（极其优雅）：
RLocklock=redisson.getLock("myLock");try{// 1. 加锁 (默认 30s 过期，自动启动看门狗)lock.lock();// 2. 业务逻辑 (哪怕跑 1 小时，锁也不会断)Thread.sleep(60*60*1000);}finally{// 3. 解锁 (自动停止看门狗)lock.unlock();}看门狗原理图解：
WatchDog 核心逻辑：
- Redisson 只要加锁成功，就会启动一个后台定时任务（TimeTask）。
- 默认每隔10秒(默认过期时间 30s 的 1/3) 检查一次。
- 如果当前线程还持有锁，就通过 Lua 脚本把 Redis 里的过期时间重置为 30s。
- 如果服务器宕机，看门狗线程也挂了，没人续期，Redis 里的锁 30s 后自动失效，不会死锁。完美！
👑 第四阶段：王者时代 (RedLock 红锁)
写法七：RedLock (解决主从一致性)
场景：
- A 在 Redis Master 拿到了锁。
- Master 还没来得及把数据同步给 Slave，Master 挂了。
- Slave 升级为 New Master。
- B 在 New Master 也可以拿到锁。
结果：A 和 B 同时持锁。
为了解决这个极端问题（虽然概率极低），Redisson 实现了RedLock算法。
- 原理：搞 5 个独立的 Redis 节点（不是集群，没有主从）。
- 规则：客户端同时向这 5 个节点申请锁，只要N/2 + 1 (即 3 个)节点加锁成功，就认为获取锁成功。
RLocklock1=redisson1.getLock("lock");RLocklock2=redisson2.getLock("lock");RLocklock3=redisson3.getLock("lock");RedissonRedLocklock=newRedissonRedLock(lock1,lock2,lock3);lock.lock();(注：RedLock 性能较差，且存在时钟跳变问题，业界争议较大，一般业务场景不推荐使用。)
📝 总结：谁才是最终答案？
在 99% 的业务场景下（电商秒杀、库存扣减、定时任务不重跑），Redisson 的默认锁（写法六）就是最终答案。
它完美解决了：
- 死锁(宕机自动过期)
- 原子性(Lua 脚本)
- 误删(UUID 校验)
- 业务超时(WatchDog 自动续期)
除非你是在做“金融级核心转账”，否则不要去碰 RedLock，过度设计是万恶之源。
