Redisson分布式锁8大陷阱实测解析 避免重复扣库存等数据错乱

Redisson虽提供可重入、自动续期等便利特性，但实际使用中仍频发重复扣库存、订单重复处理等问题。经项目实践归纳，其核心陷阱集中在加锁、执行、释放与续期、组合与故障四阶段，共8类高频问题。

第一类：传leaseTime导致看门狗失效。当tryLock(waitTime, leaseTime, unit)中leaseTime > 0时，Redisson关闭自动续期机制；仅leaseTime ≤ 0才启用看门狗。若临界区耗时超租期，锁提前释放引发并发冲突。正确策略应依据临界区执行时间确定是否设固定租期。

第二类：事务提交前提前释放锁。在Spring Boot中，若unlock()位于@Transaction注解方法内且早于事务提交，数据库回滚时锁已释放，其他线程可能重复执行业务逻辑。应通过TransactionSynchronizationManager注册事务提交后回调执行解锁，确保锁与事务生命周期对齐。

第三类：锁粒度与资源粒度不匹配。全局锁（如global:lock）虽防并发却严重降低吞吐，应按订单号、用户ID或SKU等业务资源粒度加锁，并保证键唯一可散列。

第四类：忽略续期失败风险。看门狗依赖定时PTTL续期，Full GC、网络抖动可能导致续期失败。需监控TTL与续期失败次数，并配合版本号或状态机做业务兜底校验。

第五类：可重入边界失控。同一线程多次获取锁时，若嵌套调用未统一管理锁上下文，外层释放后内层仍操作将出错。建议用ThreadLocal或显式标识追踪锁持有状态。

其余三类包括：异常路径未释放锁（须强制finally块）、多级缓存中锁与缓存更新顺序错乱、集群主从切换致锁失效（可启用RedLock增强一致性）。需强调，分布式锁仅为协调机制，不能替代幂等设计与最终一致性保障，如订单支付应结合唯一号+状态机+消息去重多重防护。