Spring Boot集成Redis本身不会导致死锁，所谓“Redis死锁”实为分布式锁释放逻辑错误或业务阻塞引发的伪死锁；根本原因在于锁未按持有者身份安全释放、超时时间与业务不匹配、无条件delete导致锁残留或误删。
直接说结论：Spring Boot集成Redis本身不会导致死锁，所谓“Redis死锁”99%是分布式锁释放逻辑错误或业务阻塞引发的伪死锁。 真正的问题出在锁未按持有者身份安全释放、锁超时时间与业务执行时间不匹配、或在finally块里无条件delete——这些都会让锁残留、误删、或长期占用，最终表现为“请求卡住”“接口超时”“数据库连接池耗尽”等典型症状。
Redis分布式锁释放时value校验必须做
很多开发者以为只要setIfAbsent成功，后续delete就安全了。错。一旦业务执行慢于锁过期时间，锁自动释放后，另一个线程抢到锁并开始执行；此时原线程终于执行完，却在finally里无脑delete——删掉的是别人刚加的锁，导致并发失控。
- 必须用唯一标识（如
UUID.randomUUID().toString()）作为锁的value - 释放前必须先
get(lockKey)比对value，仅当一致才delete - 这个比对+删除操作不能拆成两步，否则有竞态；生产环境应改用Lua脚本保证原子性（Redisson已内置）
别用RedisTemplate手写锁，优先选Redisson
自己用StringRedisTemplate拼SET key value NX EX 30再加value校验，看似可控，实则埋雷：
-
tryLock(...)和unlock()之间若发生JVM停顿、GC、网络抖动，看门狗机制缺失会导致锁提前释放 - 不可重入：同一线程重复获取锁会失败，而Redisson的
RLock默认支持可重入 - 没有自动续期：业务执行超30秒，锁就丢了；Redisson的watchdog默认每10秒续一次（leaseTime=-1时启用）
- 集群模式下，手写方案无法保证RedLock语义，Redisson提供
RedissonMultiLock
leaseTime设为-1不是万能解药
很多人看到Redisson文档写“tryLock(5, -1, TimeUnit.SECONDS)启用看门狗”，就全设成-1。但要注意：
- 看门狗只对“当前线程仍存活且锁未被主动释放”的情况续期；若线程卡死、OOM、或被kill，锁仍会在30秒（默认
lockWatchdogTimeout）后自动释放 - 续期依赖Redisson内部定时任务，若应用线程池耗尽、CPU打满，watchdog可能无法触发
- 建议显式设置合理
leaseTime（如60秒），再配合业务监控：记录每次锁获取耗时，超过阈值告警
finally里unlock()前必须加isHeldByCurrentThread()判断
这是Redisson使用者最容易忽略的一点。如果你在finally块中直接调用lock.unlock()，而此时锁已被自动释放或被其他线程释放，会抛IllegalMonitorStateException，甚至导致后续业务逻辑跳过、资源未清理。
- 正确写法是：
if (lock.isHeldByCurrentThread()) { lock.unlock(); } - 这个判断成本极低，但能避免因异常中断导致的锁状态混乱
- 尤其在嵌套调用、AOP切面加锁等场景下，不确定锁是否还在当前线程持有时，这行判断就是安全底线
最危险的不是锁加不上，而是锁“看起来加上了，其实没生效”或者“加上了却永远不释放”。所有看似隐蔽的“死锁”，基本都源于对锁生命周期缺乏精确控制——value校验、续期机制、持有者判定，三者缺一不可。线上环境宁可多打几行日志，也不要省掉任何一个防御性判断。
