直接用SETNX易误删锁，因加锁与设过期非原子操作，且释放锁未校验线程标识；正确做法是SET+NX+EX原子加锁并用Lua脚本校验值后删除。
为什么直接用 SETNX 容易误删锁
很多同学一上来就写 SETNX lock:product:123 1，再配个 EXPIRE 分两步设锁，但这是错的。Redis 的命令不是原子的，中间若服务宕机或网络中断，锁可能只有 key 没有过期时间，变成永久死锁。更危险的是释放锁时直接 DEL lock:product:123 —— 如果线程 A 拿到锁后执行慢，超时自动释放，线程 B 又拿到了新锁，此时 A 才执行完并 DEL，就把 B 的锁给删了。
正确做法是用原子命令：SET lock:product:123 "uuid-abc" EX 30 NX，其中 "uuid-abc" 是当前线程唯一标识；释放锁必须先 GET 判断值匹配，再 DEL，且这两步需用 Lua 脚本保证原子性。
加锁后一定要 double-check 缓存
拿到锁不等于缓存一定为空。因为锁等待期间，其他线程可能已更新缓存。所以加锁成功后，必须再次 GET 一次缓存，确认仍为空才查库。
- 第一次
GET缓存为空 → 尝试加锁 - 加锁成功 → 再次
GET缓存（防止锁等待时已被更新） - 若仍为空 → 查库、写缓存、释放锁
- 若已有值 → 直接返回，跳过查库
tryLock + 休眠重试比死等更实用
分布式环境下不能像单机那样用 synchronized 一直阻塞。应该设置明确的获取锁超时（如 100ms）和重试次数（如 3 次），避免线程长时间挂起。
常见错误是拿到锁失败就立刻 sleep(50) 然后递归调用自己，容易引发栈溢出或雪崩式重试。推荐写成循环：
- 最多尝试 3 次获取锁
- 每次失败后
Thread.sleep(50) - 超过次数直接返回空或抛异常，由上层降级处理
逻辑过期比物理过期更适合高读低写热点
对秒杀商品详情这类数据，用“永不过期 + 逻辑过期字段”比纯互斥锁更平滑。缓存 value 存成 JSON：{"data": {...}, "expireAt": 1745172000000}，每次读取先判断 expireAt 是否过期。
过期后不阻塞，而是用线程池异步刷新，当前请求仍返回旧值。这样既防击穿，又不拖慢响应速度。但要注意：异步任务必须带重试和失败告警，否则脏数据会一直存在。
真正难的不是加锁，而是锁的生命周期管理 —— 锁该设多长？谁来续期？异步更新失败怎么兜底？这些细节没对齐，锁反而会成为系统瓶颈点。
