Redis分布式锁防误删的核心是用UUID作为锁的唯一身份标识，释放锁时必须通过Lua脚本原子性校验value是否匹配，避免GET-DEL两步操作导致的竞态；单靠DEL会因锁过期后被其他客户端重获而误删他人锁。
Redis 分布式锁在高并发下通过 UUID 防止误删，核心是让每个客户端持有“可验证身份”的锁，而不是只靠 key 存在与否来判断能否删除。关键不在加锁时用了什么命令，而在于释放锁时能否**准确识别并仅操作自己持有的锁**。
为什么单靠 DEL 会误删？
客户端 A 加锁后业务执行超时，锁自动过期；客户端 B 立即获取到同一把锁；A 任务结束后直接 DEL key —— 此时删掉的是 B 的锁。问题本质是：DEL 不检查锁归属，只要知道 key 就能删。
UUID 作为锁的“身份证”
每次加锁时，不存线程 ID（易冲突），而是生成一个全局唯一、不可预测的字符串，比如：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
Java 中常用：
UUID.randomUUID().toString() -
更稳妥的做法：拼接服务实例标识 + UUID + 线程 ID，如
"svc-order-01:" + UUID + ":" + Thread.currentThread().getId() - 注意：UUID 必须在加锁前生成，并作为 value 写入 Redis，且全程复用同一个值
释放锁必须验证再删除
不能分两步走（GET → 判断 → DEL），否则中间可能被其他客户端抢占。正确做法是：
- 用 Lua 脚本保证原子性：脚本内读取 key 对应 value，比对是否等于当前客户端的 UUID，相等才执行 DEL
-
示例 Lua 脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then<br> return redis.call("del", KEYS[1])<br>else<br> return 0<br>end - 调用方式：传入锁 key 和本地保存的 UUID，Redis 执行整个逻辑不中断
配套要点不能漏
光有 UUID 不够，还需配合以下设计才能真正防误删：
-
加锁必须原子：使用
SET key value EX seconds NX，避免 SET + EXPIRE 分离导致的死锁风险 - 过期时间要合理：不能太短（频繁过期引发误删），也不能太长（故障时阻塞久）；建议结合业务平均耗时 × 2～3 倍，并预留重试缓冲
- 客户端需保存 UUID 副本：解锁时必须能准确提供当初加锁用的 value，不能临时再生成一个
