Redisson分布式锁避坑指南，8个高频问题与业务边界设计要点

在高并发系统中，Redisson作为主流的Redis客户端库，因其对分布式锁的封装能力被广泛采用。然而，不少开发者反馈：代码中明确调用了lock()和unlock()，却仍出现订单重复处理、库存超扣等数据不一致问题。这类现象并非Redisson本身存在缺陷，而是锁的使用方式与业务边界未对齐所致。

Redisson确实提供了可重入性、看门狗自动续期、持有者校验等关键保障机制，但这些能力仅作用于锁的生命周期管理层面。它无法感知业务逻辑是否完成、数据库事务是否提交，更不能替代幂等性设计。因此，“锁加成功”不等于“业务互斥成功”。

根据实际项目经验，Redisson在落地过程中最常见的问题可归纳为8类，集中出现在加锁、执行、释放与续期、组合与故障四个阶段。其中，多数问题源于对API语义的误解或对业务边界缺乏清晰界定。

第一类陷阱：传了leaseTime，看门狗却已“下班”

表面看是“等待2秒、锁30秒”，但关键在于：当tryLock(waitTime, leaseTime, unit)中leaseTime > 0时，Redisson不会启动看门狗机制。该行为在Redisson 3.35版本源码中明确限定——仅当leaseTime <= 0时才启用自动续期。

这意味着，若临界区执行耗时超过30秒，锁将提前失效。后续线程无需等待原线程释放，即可获取同一把锁，导致并发冲突。常见重载方法的语义差异如下：

lock()：无限等待，租期默认30秒，开启看门狗
lock(30, SECONDS)：无限等待，租期30秒，关闭看门狗
tryLock(2, SECONDS)：最多等2秒，租期默认30秒，开启看门狗（等价于tryLock(2, -1, SECONDS)）
tryLock(2, 30, SECONDS)：最多等2秒，租期30秒，关闭看门狗

正确策略应基于临界区执行时间的可预测性：若耗时不确定（如依赖慢查询），建议使用无固定租期写法，配合业务超时控制；若上限明确（如批量同步固定条数数据），则可设略大于预期的最大执行时间的租期，但必须有实测依据，而非随意填写。

第二类陷阱：事务提交前提前释放锁

该问题在Spring Boot项目中尤为突出，常与@Transactional注解共现。典型场景如下：

问题在于：unlock()发生在事务提交之前。若数据库操作成功但事务尚未提交（例如后续还有其他操作失败触发回滚），此时锁已被释放，其他线程可能立即获取锁并执行相同逻辑，造成重复处理。

正确做法是将解锁动作移至事务提交之后。可通过AOP切面、自定义注解或手动控制事务边界实现。例如使用TransactionSynchronizationManager.registerSynchronization()注册事务提交后回调，在回调中执行解锁操作，确保锁与事务生命周期严格对齐。

第三类陷阱：锁粒度与资源粒度不匹配

部分团队为简化开发，对整个服务方法加一把全局锁，如redissonClient.getLock("global:lock")。这虽能避免并发问题，却严重牺牲吞吐量。更合理的做法是按业务资源粒度加锁，例如订单号、用户ID、商品SKU等。需注意：锁键应具备唯一性与可散列性，避免因键冲突导致不同资源被同一把锁阻塞。

第四类陷阱：未处理锁续期失败或网络抖动

看门狗机制依赖定时任务向Redis发送PTTL指令以延长锁有效期。若应用实例发生Full GC、线程阻塞或网络分区，可能导致续期请求延迟或丢失，锁提前过期。对此，应结合监控指标（如锁剩余TTL、续期失败次数）设置告警，并在业务层增加兜底机制，例如通过版本号或状态机校验操作合法性。

第五类陷阱：忽略锁的可重入性边界

Redisson默认支持可重入锁，即同一线程可多次获取同一把锁。但若业务中存在嵌套调用且未统一管理锁上下文，可能出现外层释放后内层仍尝试操作的情况。建议通过ThreadLocal或显式锁标识管理锁持有状态，避免跨层级误释放。

其余三类问题包括：异常路径下未释放锁（需强制finally块）、多级缓存场景下锁与缓存更新顺序错乱、以及集群模式下主从切换导致的锁失效（需启用RedLock或WaitStrategy增强一致性）。

需要强调的是，分布式锁本质是“尽力而为”的协调机制，不能替代业务层面的幂等设计与最终一致性保障。例如订单支付场景，除加锁外，还应结合唯一订单号+状态机+消息去重等多重防护。

在微服务架构日益普及的当下，Redisson已成为分布式协调的事实标准之一。但其价值发挥高度依赖使用者对底层原理的理解与业务场景的适配能力。与其追求“零失误”的锁实现，不如建立清晰的锁使用规范：明确锁保护的资源边界、评估临界区执行时间、校验事务与锁的生命周期耦合关系，并辅以可观测性手段进行验证。

技术工具永远服务于业务目标，锁的设计亦如此——它不是用来“防止并发”，而是为了在可控范围内实现业务逻辑的串行化执行。当开发者跳出“只要加了锁就安全”的思维定式,转而关注锁与业务的协同边界时,才能真正规避那些看似隐蔽、实则高频的生产事故。