半泽和莉娜2. 从单机锁到分布式锁：为什么面试官死磕这个点
先说个我面试别人时候的感受：很多候选人一听到“分布式锁”三个字，立刻条件反射般背出“SET NX EX”五连，再补一句“Redisson看门狗”。听起来挺全，但一追问“为什么释放锁要校验标识”“Redis挂了怎么办”，立刻就卡壳。这其实暴露了一个关键问题——你背的是结论，不是逻辑。
分布式锁解决的本质问题，是“多个进程/多台机器之间的互斥”。单机时代我们用synchronized或者ReentrantLock，JVM内部自己就能保证线程安全。但微服务拆开之后，锁的边界从“进程内”扩展到“跨进程”，Java的锁管不了别的机器上的代码，这才需要一把大家都能看得见、摸得着的“公共锁”。Redis因为单线程模型、IO多路复用、读写速度极快，天然成了这把公共锁的首选载体。
但“快”不等于“可靠”。Redis分布式锁真正的难点，不在于“怎么加锁”，而在于“加锁之后怎么应对各种意外”：持有锁的进程挂了怎么办？锁过期了但业务还没跑完怎么办？Redis主从切换了锁丢了怎么办？这些问题才是面试官真正想听的——因为它们直接对应生产环境里会踩的坑。所以这篇文章不打算给你罗列一堆标准答案，而是把8个最高频的面试问题摊开，从原理到实现再到坑点，一层层说清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
3. 面试第一问：为什么选Redis做分布式锁，而不是ZooKeeper或数据库
3.1 三种方案的底层逻辑对比
这个问题几乎每场面试都会出现，本质上考的是你对“锁”这个需求的权衡能力。数据库悲观锁（比如SELECT FOR UPDATE）实现最简单，但性能是硬伤，一个简单的争抢操作可能要消耗数据库连接和行锁资源，高并发下容易把数据库拖垮；乐观锁靠版本号或时间戳，适合读多写少的场景，但并发冲突一多，重试成本非常高。ZooKeeper的分布式锁基于临时顺序节点，可靠性确实好——客户端挂了节点自动消失，天然解决“死锁”问题，但ZooKeeper本身是CP模型，写性能有限，而且引入一套独立中间件，运维成本不低。
Redis的方案走的是另一个极端：用高性能换取一定的可靠性牺牲。Redis单机QPS可以轻松到10万+，加锁、释放锁都只是一两次内存操作，毫秒级完成。相比ZooKeeper动辄几十毫秒的写路径，Redis在“追求极速响应、可以接受极小概率极端异常”的场景里，几乎是唯一的选择。缓存、Session共享、计数器、排行榜，很多系统本来就已经有Redis，不用额外引入组件，这也是Redis分布式锁这么普及的现实原因。
3.2 面试官追问：什么场景坚决不能用Redis锁
顺着上面的逻辑，对方很可能会追问：“那你觉得Redis分布式锁的适用边界在哪里？” 这时候你要主动交代清楚：如果业务对“锁的可靠性”要求极高——比如金融转账、库存扣减，锁一旦丢失可能导致超卖、重复扣款这种资金级事故，那么Redis锁（哪怕是RedLock）都存在理论上的风险窗口。这种情况下要么升级到ZooKeeper或etcd这类CP模型组件，要么在业务层面做幂等兜底。另外，如果你的Redis集群规模小、运维能力弱，主从切换又很频繁，那也要慎重——这跟锁本身无关，是底层存储的可用性拖累了锁的可靠性。能把这个“边界感”讲清楚，比背一百个Redis命令更能让面试官点头。
4. 面试第二问：加锁和释放锁的原子性，是面试里最大的坑
4.1 为什么SETNX之后必须拼上EXPIRE
很多老教程还在教用SETNX key value加锁，再用EXPIRE key seconds单独设置过期时间。这个写法在面试里属于“送命题”：两个命令之间不是原子的。假如SETNX执行成功之后，进程突然被kill掉或者JVM发生长时间GC停顿，EXPIRE根本没机会执行，这把锁就永远躺在Redis里，其他所有线程都进不来，直接整体死锁。
正确做法是Redis 2.6.12以后统一用一条命令：SET lock_key unique_value NX PX 30000。NX保证只有键不存在时才能写入，PX设置过期时间，两个条件在一条命令里完成，从根上杜绝了“加锁成功但没设过期时间”这种半成品状态。这里有个细节值得多说一句：unique_value必须是一个能标识持有者身份的随机字符串（比如UUID），绝不能每个线程都用同一个固定值，否则就埋下了后面那个“误删锁”的雷。
4.2 释放锁用Lua脚本，不是简单的DEL
释放锁的逻辑，一句话概括就是“先校验、后删除”，但这三个字里藏着第二个巨坑。很多人释放锁直接DEL lock_key，完全不校验Value。假设线程A持有锁，因为业务执行过久触发了过期时间，锁自动释放了；此时线程B抢到锁开始执行；如果线程A在结束前顺手DEL一下，就把B的锁删了，B的业务还在跑，另一批线程C、D、E一看锁没了，一拥而入——相当于自己把自己的锁给拆了。
正确的释放方式是用Lua脚本，把“比对Value”和“删除Key”做成原子操作：
lua复制if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
只有Value匹配才删除，不匹配则直接返回。为什么必须用Lua？因为Redis的Lua脚本是原子执行的，整个脚本运行期间不会有其他命令插入，这才能保证“判断+删除”中间的窗口期没有被并发钻空子。
4.3 面试官最爱追问的“锁被误删”场景还原
追问往往从这里开始：“你能说一个具体的误删场景吗？” 我建议你直接用这个例子：线程A拿到锁，业务代码里调了一个外部接口，接口超时重试，整体耗时超过了锁的过期时间比如10秒。锁自动释放后，线程B拿到锁开始写数据。A的外部调用终于返回了，A继续往下走，执行finally里的删除逻辑。如果不校验Value，A就把B的锁删了。更糟的情况是B也执行完了也删了一次锁，那C就进来了。一层层“连锁误删”，整个互斥保护完全失效。如果你能把这个链条口述得清清楚楚，面试官基本能确认你是真正处理过这个问题的人。
5. 面试第三问：锁过期了但业务还没跑完，怎么办
5.1 过期时间设多长才合理
这个问题没有标准答案，但有一个非常实用的判断思路：过期时间要大于业务预估最大耗时。比如正常业务是50毫秒，有网络抖动时可能到1秒，你拍脑袋设3秒，看起来挺安全，但遇到JVM Full GC停顿、数据库连接池耗尽、下游接口雪崩，业务实际执行了10秒，锁在第3秒就没了。所以“乐观但留有余量”是原则——太小容易提前失效，太大一旦持有者崩溃，备用节点要等很久才能抢到锁，影响故障恢复速度。
我见过比较稳的做法是：默认设30秒，但在业务里配合“自动续期”机制，让锁的有效期跟随业务执行动态延长。这个机制就是Redisson看门狗的思路，下面会细讲。如果你不想引入额外依赖，还有一个土办法：在业务代码的关键节点手动PEXPIRE续期，但这样侵入性强、容易漏，适合锁操作简单直接的场景。
5.2 Redisson看门狗续期机制的原理解读
Redisson解决“锁过期业务没跑完”的方案极其巧妙。当你用RLock lock = redisson.getLock("orderLock"); lock.lock();加锁时，默认会启动一个后台定时任务——看门狗。它的行为可以拆成三步：
- 加锁成功后，看门狗会记录锁的剩余过期时间（默认30秒）。
- 每隔
leaseTime / 3，也就是10秒，它就会检查一次：如果锁还被当前线程持有，就自动执行PEXPIRE把锁的过期时间重新拉回30秒。 - 业务执行完，主动
unlock()，看门狗任务销毁，锁被正常释放。
这就像你出门前给家里留了一盏灯，然后每隔10分钟让邻居去确认一下灯还亮着，如果亮着就再给灯重新定时。只要你的业务还在跑，锁就永远不会过期；什么时候不跑了，看门狗也停了，锁自然就被回收。
这里有一个隐藏的好处在面试里一定要点出来：看门狗的续期目标Key是当前线程持有锁的那个Key，而且是Hash结构存储的，里面存了线程标识和重入次数。所以Redisson的锁天然支持可重入，同一线程可以多次加同一把锁，每次加锁重入计数加一，释放锁时计数减一，减到零才真正删除Key。这一点比你自己基于String SET实现的锁要完整得多。
5.3 手动指定leaseTime时看门狗会失效
面试官很可能在这里设陷阱：“那我看门狗是不是永远都能续期？” 答案是：不一定。如果你调用的是lock.lock(10, TimeUnit.SECONDS)，也就是手动指定了leaseTime，Redisson会认为你已经明确告诉它“这把锁只住10秒”，它就不会再启动看门狗线程。此时如果业务超过10秒还没跑完，锁照样提前释放。所以使用Redisson时，除非你很清楚业务耗时有上限，否则建议用不带leaseTime的lock()方法，把续期交给看门狗去管，或者反过来，给一个足够大的leaseTime，然后业务自己控制节奏。这个细节很冷门，但非常能体现你的源码阅读深度。
6. 面试第四问：Redis集群模式下，锁真的可靠吗
6.1 主从切换导致锁丢失的惊险案例
这张图可能很多面试官都会让你画出来：客户端A向Master节点写入锁Key，数据还没来得及同步到Slave，Master就挂了，Sentinel把Slave提升为新Master。此时新Master里根本没有这把锁的数据，客户端B加锁时发现Key不存在，直接加锁成功。瞬间A和B同时持有同一把业务锁，互斥失败。
这个问题的本质是Redis主从复制是异步的。异步意味着“我写入成功”和“数据真正送到备份节点”之间存在一个时间差，而这个时间差恰恰就是故障发生的窗口。Redis官方也承认这个问题无法从主从复制层面根治，只能通过其他策略去缓解。
6.2 RedLock算法的核心思想与争议
Redis官方给出的方案是RedLock，思路很直白：不再依赖单一Redis节点，而是部署N个（通常是5个）相互独立的Redis实例，加锁时必须向大多数节点（至少3个）成功写入才算加锁成功；释放锁时向所有节点发送删除命令。它的理论基础是：只要大多数节点还存活，系统就能对外提供一致的锁服务；即便个别节点挂了，只要没有超过半数，整个锁的决策依然有效。
但RedLock从诞生起就伴随着巨大争议。分布式系统专家Martin Kleppmann写过一篇著名的文章《How to do distributed locking》，直接指出RedLock存在三大硬伤：一是它依赖所有节点的时间戳，而分布式环境下各节点的时钟可能漂移，节点宕机后重启，时钟回拨可能导致锁的有效期计算失真；二是客户端在“写入半数节点”和“获得锁”之间如果发生GC停顿，锁的有效期被白白消耗，等恢复过来可能已经失效了；三是RedLock本身并不能完全解决“不可暂停的进程”和“不可控的时钟”这两个分布式锁的基础假设问题。Antirez（Redis作者）专门写了一篇长文反驳，双方各有各的道理。面试时你不需要站队，但能把两边核心论点都讲出来的候选人，基本就是这个问题的满分答案。
6.3 生产实践：RedLock真的有必要吗
我说点面试之外的实在话。绝大多数互联网业务，比如秒杀库存、订单状态的流转、接口防重，单节点Redis加锁配合合适的过期时间，已经能满足99.9%的需求。RedLock的成本却很高：需要多部署3到5倍的Redis节点，运维复杂度直线上升，而且它在网络分区、时钟异常时的表现也远非完美。我个人的倾向是：如果业务能接受极小概率的“重复执行”，就用单节点或者主从哨兵模式的Redis锁，然后在业务层加幂等兜底（比如数据库唯一索引、操作日志去重）；如果业务绝对无法接受，比如涉及资金类的操作，那就别硬扛Redis了，直接上ZooKeeper或者etcd。这种“不炫技、看场景”的思路，反而是很多高级工程师在面试里更愿意听到的。
7. 面试第五问：分布式锁的可重入和阻塞等待，是怎么实现的
7.1 自旋等待 vs 发布订阅：两种等待锁的方式
分布式环境下，“抢锁失败”之后线程该怎么办，是一个经常被忽略但很实际的问题。感受一下两种模式的区别：自旋等待就是写一个while(true)循环，不断尝试加锁，直到成功或者超时。Redis官方文档里的SET NX示例就是这么干的，但它的缺点在低版本Redis上尤其明显——每轮循环都是一次网络请求，大量线程失败后持续空转，Redis的压力成倍上涨。若并发量高，这种“锁竞争风暴”可能直接把Redis打挂。
Redisson的处理方式要优雅很多。它内部维护了一个Semaphore（信号量），加锁失败后，当前线程不会立刻重试，而是通过Redis的发布订阅（Pub/Sub）订阅一个特定的Channel，等其他线程释放锁后，Redis会往这个Channel里推送一条消息，等待的线程被唤醒后重新尝试。这就像你去餐厅吃饭没位置，服务员让你留下手机号，有位子了第一时间通知你，而不是让你每隔10秒就跑来问一次“有没有位子”——省去了大量无意义的轮询请求。
7.2 Redisson可重入锁的Hash结构存储
再往深挖一层，Redisson为什么能实现可重入？因为它加锁时写入的不是一个简单的String，而是一个Hash。这个Hash的Key是锁名称，Field是持有锁的线程唯一标识（UUID + 线程ID），Value是重入计数。
加锁时会执行一段Lua脚本，逻辑大致是：
lua复制if (redis.call('exists', KEYS[1]) == 0) then
redis.call('hset', KEYS[1], ARGV[1], 1)
redis.call('pexpire', KEYS[1], ARGV[2])
return nil
end
if (redis.call('hexists', KEYS[1], ARGV[1]) == 1) then
redis.call('hincrby', KEYS[1], ARGV[1], 1)
redis.call('pexpire', KEYS[1], ARGV[2])
return nil
end
return redis.call('pttl', KEYS[1])
同一个线程再来加锁时，hexists命中，计数加一；释放锁时，计数减一，减到0才删除整个Hash。这种结构的巧妙之处在于：锁的“归属”信息完整地存在Redis里，不依赖客户端本地状态，任何客户端都能正确判断这把锁是不是自己持有的。
7.3 读锁和写锁：分布式环境下的读写互斥
Redisson还提供了ReadWriteLock，语义上参考了Java的ReentrantReadWriteLock：读锁和读锁不互斥，读锁和写锁互斥，写锁和写锁互斥。这非常适合“缓存一致性”场景，比如多个线程同时读一个配置，允许并发；一旦某个线程要更新配置，就必须等到所有读锁释放。
实现上，写锁依然用Hash存储，读锁则会在Hash里维护一个“读锁计数”的字段，所有持有读锁的线程共享这个计数。写锁加锁前会检查当前有没有读锁，有则阻塞；读锁加锁前会检查写锁是否被持有，有则阻塞。这块的生产使用率并不高，但能提出来，说明你对Redisson的高级特性有系统性的了解，而不是只停留在最常用的lock()和unlock()。
8. 面试第六问：锁的粒度怎么设计，才能扛住高并发
8.1 一把大锁锁全表，性能直接归零
这个问题很考察实战经验。我见过太多人把分布式锁用“歪”了：不管什么业务，上来就是一把大锁。比如一个商城的库存中心，所有商品共用一把inventory_lock，任何一次库存扣减都要全局排队。先不说性能问题，单说可用性——只要某个商品的扣减逻辑出了问题，导致锁长时间不释放，整个库存中心的操作全部阻塞，一个热点商品能拖垮全站。
锁的粒度设计本质上是在“并发安全”和“并发性能”之间做平衡。最粗的粒度是“所有请求共用一把锁”，最细的粒度是“同一业务实体的请求共用一把锁”，比如把锁的Key设计成stock:lock:{productId}，不同的商品天然走不同的锁，互不干扰。
8.2 分片锁：把一把大锁拆成N把小锁
对于超高并发的热点数据，比如一个爆款SKU的库存扣减，即使锁Key已经细化到商品维度，单把锁的争抢还是会让所有购买请求排队。此时可以玩一个分片技巧：把库存总数拆成多个分片，每个分片有自己的锁Key。比如1万件库存拆成10个分片，每个分片1000件，扣减时先对productId做哈希取模，路由到其中一个分片，只锁这个分片。
看一个简化的思路：
java复制// 分片数，根据并发量调节
private static final int SHARD_COUNT = 10;
private String buildLockKey(Long productId, int quantity) {
int shard = (productId.hashCode() & Integer.MAX_VALUE) % SHARD_COUNT;
return "stock:shard:" + productId + ":" + shard;
}
这样只要多个用户落在不同分片上，锁之间完全不冲突；就算落在同一个分片，也只需要等待同一个分片的锁，而不是所有的库存操作都堵在一起。分片后带来的新问题是：不同分片的库存可能分配不均，某个分片被抢光了，其他分片还有货，这时候需要“先查各分片可用库存，再决定扣哪个分片”或者做“分片库存动态调配”。这些延伸出来的问题，恰恰能体现出你对高并发场景的完整思考。
8.3 锁的Key命名规范，很多人栽在这
锁Key的命名看起来是小事，但实际踩坑的人很多。一是别把整个对象序列化之后当Key，序列化结果太长不说，一旦对象的字段顺序或内容发生变化，锁Key就变了；二是Key里必须包含业务维度，比如订单场景用order:lock:{orderId}，活动场景用promotion:lock:{promotionId}:{userId}，把锁的维度收敛到“真正需要互斥的实体”上；三是统一加前缀，方便排查问题——分布式锁的Key一多，运维同学想查看哪些锁还活着，靠一个keys order:lock:*就能扫出来。这些小的细节，单看没什么技术含量，合在一起就能体现出你的工程素养。
9. 面试第七问：锁的可靠性和性能，能同时兼顾吗
9.1 加锁性能的瓶颈到底在哪
很多人误以为分布式锁的性能瓶颈在Redis本身，其实Redis单次SET操作耗时在微秒级别，真正的瓶颈往往在客户端逻辑上。比如加锁时用了同步网络IO，每次加锁都要走一次完整RTT；或者高频业务里反复创建连接，连接池耗尽；又或者锁等待用了自旋重试，大量无效请求把带宽和CPU打满，加锁自然就慢了。
性能优化的方向其实很清晰：一是连接复用，用Lettuce或Jedis连接池，别每次加锁都新建连接；二是减少锁操作的次数，复杂的业务链路上，把多个需要互斥的操作合并到一个分布式事务或者一个大锁临界区里，避免一把锁加三次；三是精确控制锁的等待时间，不要无限期等锁，超过一定时间直接返回失败或走降级逻辑，避免线程堆积。
9.2 高并发压测时，锁竞争带来的线程阻塞问题
举个压测场景。系统QPS 5000，其中2000个请求竞争同一把锁，Redis本身处理加锁命令很快，但客户端线程在等待锁的过程中会阻塞。如果用Redisson的tryLock(waitTime, leaseTime)，过了waitTime还没拿到锁就直接返回false，线程可以去处理其他请求，而不是无限阻塞下去。这是Redisson比原生SET NX方案更好用的另一个原因——它把“带超时等待”做到了客户端API层面，调用方一行代码就能控制等待策略。
另外补充一点：拿到锁后，临界区的代码一定要精简，只放真正需要互斥的操作。比如库存扣减，只需要“检查库存-扣减库存-写流水”这三个步骤，凡是和并发安全无关的逻辑都不要放进锁里。锁内代码越短，线程持有锁的时间越短，锁竞争的自然就越低。
9.3 缓存击穿和锁失效的联动陷阱
这个坑特别隐蔽。假设你做了“缓存空值”处理，某个热点Key在缓存里不存在，大量请求同时打到数据库，你加了一个“重建缓存”的分布式锁，减少DB压力。但如果在持锁重建缓存期间，缓存还没写完，锁就提前过期了，后面又有一批请求进来，发现缓存还是空的，继续抢锁重建——这就可能把数据库压垮。这里需要的是“锁内双重检查”，也就是常说的Double-Check：抢到锁之后，先再查一次缓存是否存在，如果存在就直接返回，不用重建；只有确认缓存确实不存在，才执行重建逻辑。这种“锁 + 缓存 + 回源”的组合设计，面试官一听就知道你不是只会写CRUD。
10. 面试第八问：Redisson的锁和底层ZooKeeper锁的选型对比
10.1 从CAP角度理解三者的差异
这个问题通常是压轴题，考察的是对分布式理论的理解。Redis是AP模型，优先保证可用性和分区容错性，牺牲的是一致性（极端情况）；ZooKeeper是CP模型，优先保证一致性和分区容错性，写入时如果半数以上节点不可用，它会拒绝服务。etcd和ZooKeeper类似，同为CP模型，实现分布式锁时用的是Raft共识算法，数据在多数节点复制成功后才算提交。
三者的选择其实很简单：如果你不能接受“锁极大概率丢失”，那就别用Redis；如果你能接受“在极端故障时，锁服务短暂不可用”，那ZooKeeper和etcd都是更稳妥的选择。这套取舍听起来很理论，但在真实架构评审里就是这么用的。
10.2 ZooKeeper锁最核心的优势：临时顺序节点
ZooKeeper的锁基于一个重要特性：临时节点（Ephemeral Node）。客户端创建一个临时节点，客户端会话断开后，ZooKeeper会自动删除这个节点。这解决了Redis锁里一个老大难问题——持有锁的进程崩溃后，锁无法释放导致死锁。在ZooKeeper中不用设置过期时间，只要客户端还活着，会话还在，锁就在；客户端挂了，节点自动消失，锁自动释放，不需要看门狗续期。
配合顺序节点后，ZooKeeper还可以实现公平锁：多个客户端同时抢锁时，各自创建临时顺序节点，节点编号最小的获得锁，其他客户端监听前一个节点的删除事件。这比Redis锁在“公平性”上好很多，没有惊群效应，监听回调精确到“前一个节点释放时我来抢”。
10.3 如果你的项目里已经有etcd，用etcd实现更省心
现在很多新项目直接用etcd做配置中心，既然已经有了etcd，再顺手用它实现分布式锁，比单独引入Redis或ZooKeeper划算得多。etcd的Lease（租约）、Revision（版本号）和Watch机制，天然就是为分布式协调设计的。实现一个分布式锁的基本思路：创建Lease并设置TTL，通过Txn事务判断Key是否不存在，不存在则写入并且绑定Lease；抢锁失败时Watch这个Key，等它被删除后再尝试。etcd的TTL机制同样面临“业务执行时间超过TTL”的问题，但它提供了KeepAlive续约接口，客户端可以自行管理续约周期。
真到了选型层面，我一般会这么建议：技术团队极简部署，能少一个组件就少一个组件，业务允许极小概率的锁失效，Redis锁加业务幂等最省事；如果已经有了ZooKeeper或者etcd，对一致性要求又高，用它们写锁也没多大事，等于是拿组件复用换取可靠性；如果是金融级强一致业务，别自己造轮子，直接引入成熟的分布式协调组件，至少在审计上站得住脚。
11. 分布式锁在生产环境中的运维经验和避坑清单
11.1 监控锁的指标，防止“死锁无声”
很多分布式锁的问题，都不是“爆”出来的，而是“藏”出来的。锁的Key一直没删除，所有相关请求都在超时重试，表面看接口变慢，实际上锁早就死了。所以监控分布式锁，重点要看几个指标：锁的等待时间分布、抢锁失败率、锁内业务执行时长。这三类指标能直接告诉你锁是否正常：等待时间突然变长，大概率是某个持有锁的线程卡住了；失败率升高，可能是锁的Key被误删或者竞争太激烈；锁内执行时间波动大，则说明临界区代码质量有问题。把这些指标接到Prometheus + Grafana上，比上线一百个功能都有用。
11.2 锁的租期设置通用建议
在没有Redisson看门狗或者不想用它的场景下，锁的过期时间最好的做法是按照业务最大耗时的两到三倍来设置。比如业务95%的情况在200毫秒内完成，最大值在800毫秒，那过期时间可以设2到3秒，既保证极端情况不会太早过期，又不至于因为锁持有者崩溃而长时间卡住后续请求。
还有一个小技巧：给锁的Value里带上当前机器IP、线程号、请求ID等信息，排查问题时能直接定位“是哪台机器、哪个线程在占用锁”。Redis客户端执行HGETALL lock_key，看到Value里的元信息，整个问题链路就一目了然了。
11.3 一个容易忽略的坑：锁的公平性
Redis官方的SET NX锁是非公平锁，后来的线程可能先抢到锁，先来的线程反而一直等待。Redisson默认也是非公平的，但提供了FairLock（公平锁），它内部基于Redis的List和Hash实现了一个等待队列，保证先申请锁的线程先获得锁。不过公平锁的性能远差于非公平锁，只适合真正需要顺序保障的场景。面试如果聊到这里，你可以主动提一句“Redis锁大部分场景是非公平的，如果需要公平性，要么用Redisson FairLock，要么考虑ZooKeeper的顺序节点实现”，这种对比思维是加分项。
11.4 经验总结：分布式锁不是“实现出来”就完了，而是要“运行得好”
我踩过的最深的一个坑，是给一个高并发订单服务上了分布式锁之后，没有仔细设计锁的粒度，结果双11压测直接把Redis的CPU打到了90%。后来把一把全局锁拆成了按订单维度加锁，配合Redisson的看门狗，再补了锁内双重检查和失败降级，压测数据才恢复正常。这类经验其实印证了一个道理：分布式锁是一个“看起来很简单，用起来全是细节”的技术点。它的设计核心不是API怎么调，而是异常分支怎么处理——进程崩溃、网络超时、GC停顿、主从切换、时钟漂移、数据倾斜，任何一个点都可能让锁失效甚至引发线上事故。面试时如果能把这个维度讲透，远比你背一百个Redis命令更有说服力。