必须设置过期时间，否则锁可能永久占用导致死锁；应使用原子命令set nx ex设置，配合watchdog动态续期，兼顾防死锁与防击穿。
因为不设过期时间，锁可能永远卡住，导致其他服务彻底拿不到资源。
死锁的根源是客户端异常退出
分布式环境下，持有锁的进程可能随时崩溃、网络中断、JVM OOM 或被强制 kill。一旦它没来得及执行 unlock，又没设置过期时间，那个 lock key 就会一直留在 Redis 里——后续所有请求都会因 SETNX 失败而排队或失败，业务完全阻塞。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Redis 本身不感知业务是否“还在干活”，只认 key 存不存在
- 没有过期时间，就等于把锁变成了“永久占位符”
- 这不是小概率事件，而是任何生产系统都必然面对的故障面
过期时间是自动兜底的安全阀
它不是为了限制业务时长，而是为异常情况提供确定性释放机制：哪怕客户端挂了、代码卡死、GC 停顿太久，只要过了设定时间，Redis 就自动删掉 key，让其他节点有机会重试抢锁。
- 这个机制不依赖任何外部协调或心跳检测，轻量且可靠
- 它是分布式锁能落地的底线保障，不是可选项
- 必须用原子命令（如 SET key value NX EX 30）一次性设置，避免 SETNX + EXPIRE 分两步带来的中间态风险
过期时间 ≠ 锁的有效期，只是最大容忍等待窗口
真正决定锁是否安全续用的，是看门狗机制（Watchdog）。单纯靠固定过期时间，要么太短引发击穿（业务超时后锁被删，别人进来并发操作），要么太长加剧阻塞（客户端宕机后锁卡死几十分钟）。
- 推荐做法：设一个合理基础值（比如业务 P99 耗时 × 1.5），再交由 Watchdog 动态续期
- Watchdog 只在未指定 leaseTime（或传 -1）时启动，每 10 秒检查一次持有者线程是否还活着，并用 Lua 脚本做身份校验后安全续期
- 这样既防死锁，又防击穿，锁生命周期真正和业务线程绑定
