锁对象泄漏本质是锁key存在但value已失效，导致误删他人锁、状态污染与虚假空闲判断；需通过唯一value标识、原子Lua校验、健康检查点及lease时间双校验根治。
业务没执行完，锁却提前过期，这不是单纯的“锁失效”，而是会引发一连串次生干扰——比如锁对象泄漏（即锁 key 仍存在但已失去控制权），进而污染锁状态、干扰后续加锁判断、甚至让其他服务误判资源可用性。这个问题在高并发、长耗时任务（如报表生成、批量导入、跨系统对账）中尤为隐蔽，大厂常用来考察候选人对分布式锁生命周期的深度理解。
锁对象泄漏的本质是“身份失控”
所谓泄漏，并非 Redis 中 key 没被删，而是 key 还在，value 却已不属于当前持有者。典型路径如下：
- 服务 A 用 UUID-1 加锁，设置 TTL=30s
- 业务执行到第 35 秒才完成，此时锁早已过期，Redis 自动删除 key
- 但服务 A 不知情，仍在执行释放逻辑：读取 key 当前 value（此时为 nil 或已被服务 B 占用），再调 DEL —— 若未做原子校验，可能误删服务 B 的锁
- 更危险的是：若服务 A 释放时用了错误的 Lua 脚本（比如只判断 key 存在就删），或干脆跳过校验直接 DEL，就会导致“锁对象残留语义”：key 看似空闲，实则刚被误删，下一刻服务 B 的锁又写入，而服务 C 查 key 不存在便贸然加锁……整个锁状态进入不可信区间
次生干扰的三种典型表现
锁对象泄漏不会立刻报错，但会逐步放大系统不一致性：
- 虚假空闲判断：监控脚本或运维工具扫描锁 key，发现 key 不存在，就认为“无锁占用”，触发人工干预或自动扩容，结果新实例一上线就撞上正在运行的旧任务
- 续约线程持续扰动：若启用了 Watch Dog，而主线程崩溃但守护线程仍在运行，它会不断尝试续期一个已失效或归属他人的锁，产生无效 Redis 请求，拖慢集群响应
- 日志与链路断裂：Tracing 系统记录“加锁成功→业务执行→释放成功”，但实际释放操作删的是别人锁，导致链路追踪显示一切正常，而数据错误已在下游发生，排查时完全找不到日志证据
根治关键：从“保锁存活”转向“控锁主权”
不能只靠续约延长 TTL，必须确保每个操作都绑定明确的身份主权：
- 加锁时 value 必须含唯一标识（推荐 UUID + 实例 ID + 时间戳组合），避免纯随机值在日志中无法溯源
- 所有锁操作（续期、查询、释放）均通过同一套 Lua 脚本完成，脚本内强制校验 value 全等，拒绝任何模糊匹配
- 业务主流程需设置“锁健康检查点”：例如每执行完一个子步骤，主动 GET key 并比对 value，不一致立即中断并告警，而非硬扛到结尾才释放
- 监控层面增加“锁持有漂移率”指标：统计单位时间内同一 key 的 value 变更频次，突增即提示潜在泄漏或误删
生产环境可落地的轻量加固方案
不依赖 Redisson 等框架也能快速收敛风险：
- 在加锁命令后追加一条 SET key:lease:expire {timestamp} EX 3600，单独记录该次锁预期截止时间，供后续核验
- 释放锁前，先 EVAL 原子脚本：检查当前 value 是否匹配 + 当前时间是否早于 lease:expire 记录的时间，双条件满足才允许释放
- 定时任务每 5 分钟扫描所有锁 key，对 TTL 剩余＜5s 且 value 不符合预期格式的 key，自动打标并推送至告警群，人工介入确认
