在分布式锁的选择上，应优先考虑 tryLock()，因为它支持超时控制，能有效避免线程无限等待；而 lock() 方法缺乏超时机制，容易导致线程卡死。此外，使用 Redisson 锁时，必须配合数据库的条件更新作为兜底方案，这是因为 Redis 主从异步复制机制存在锁失效的风险。
lock() 和 tryLock() 到底该选哪个？
这是一个经典的选择题。lock() 方法会一直阻塞，直到成功获取锁，它适用于那些能快速执行完毕的临界区任务。但在生产环境中，tryLock() 通常是更安全的选择——它支持超时控制，能够有效规避因网络抖动、Redis 响应延迟或看门狗（watchdog）机制失效而导致的线程无限期等待问题。
lock()的风险：由于没有设置超时，一旦 Redis 主节点发生阻塞或客户端与服务器失联，等待锁的线程就可能被永久挂起，连 JVM 都束手无策。tryLock(long waitTime, long leaseTime, TimeUnit unit)的参数解析：这里有两个关键时间参数需要区分清楚：waitTime指的是尝试获取锁时最多愿意等待的时间；leaseTime则是指成功获取锁后，这把锁自动释放的持有时间（默认值为30秒）。- 实际用法推荐：
tryLock(3, 10, TimeUnit.SECONDS)—— 这个配置意味着最多等待3秒去争抢锁，一旦抢到，最多持有10秒。这种策略既能防止死锁，又能避免锁被长期占用不释放。
为什么不能只靠 Redisson 加锁，还得在数据库里加条件更新？
核心原因在于 Redis 的主从异步复制模型。在这种架构下，lock() 调用成功并不等同于锁绝对可靠。设想一个场景：主节点成功写入锁信息后突然宕机，而从节点被提升为新的主节点。此时，新的客户端完全有可能对同一个 key 再次加锁成功。这并非 Redisson 的缺陷，而是 Redis 作为 AP 系统（保证可用性和分区容错性）的天然限制。
- 兜底方案：所有关键业务操作，例如扣减库存、修改订单状态，都必须搭配数据库的条件更新。典型的 SQL 语句如：
UPDATE order SET status = 'CANCELLED' WHERE id = ? AND status = 'CREATED'。 - 校验逻辑：执行上述更新后，务必检查影响的行数。如果结果为0，则说明数据状态已经发生变化（例如订单已被处理），此时应直接拒绝当前操作，而不是依赖 Redis 锁的结果。
- 角色定位：可以这样理解两者的关系——Redisson 锁是提升并发性能的“快车道”，而数据库条件更新则是保障数据最终一致性的“红绿灯”。前者负责提效，后者负责兜底。
watchdog 自动续期失效的常见原因
Redisson 默认启用的 watchdog（看门狗）机制是个好帮手，它会每隔10秒检查持有锁的线程是否存活，并自动延长锁的有效期。但这个机制并非万无一失，在以下几种情况下可能失效：
- 线程被中断：如果持有锁的线程被
interrupt()方法中断，watchdog 会停止续期工作，导致锁到期后自动释放。因此，必须确保临界区内的代码执行不会被意外中断。 - 显式指定了租约时间：当使用
tryLock(leaseTime > 0)这种形式（即显式传入一个正的 leaseTime 参数）时，watchdog 机制就不会启动。如果想启用自动续期，leaseTime参数必须传递 -1 或不传（底层会使用默认的internalLockLeaseTime值）。 - 跨线程操作：在 Spring Boot 等框架中，如果在异步方法（标记了
@Async）中使用锁，锁对象可能会因为跨线程而丢失上下文，导致 watchdog 无法定位到原始的持有线程。因此，锁的获取和释放必须在同一个线程内完成。
读写分离场景下，Redisson 锁操作真的安全吗？
答案是安全的，但有一个至关重要的前提：必须严格区分“读取业务数据”和“读取锁状态”这两件事。
- 锁操作的路由机制：
lock()、unlock()、isLocked()等所有与锁状态相关的操作，Redisson 都会通过 Lua 脚本强制路由到主节点执行，从节点完全不参与锁逻辑。这一点是安全的。 - 业务数据的读取风险：问题往往出在业务代码本身。如果在成功加锁后，你的业务逻辑却从从节点去读取数据（比如查询库存），那么很可能读到的是尚未同步的旧值。因此，临界区内的所有数据读写操作，都必须统一走主节点。
- 如何验证：一个简单的验证方法是抓取网络包或查看日志，确认 Redisson 发出的命令是否都指向了主节点地址。不要被配置中的
readMode = SLA VE所迷惑，这个设置通常只影响RMap、RList这类数据结构的读取，对锁操作的路由逻辑没有影响。
总而言之，Redisson 的锁机制本身设计得非常扎实。真正容易出问题的地方，往往不在于“如何把锁加上”，而在于“加锁之后做了什么”——你是否从正确的节点读取了数据？数据库层面有没有做最终的状态校验？持有锁的线程生命周期是否完整？这些才是保障分布式锁可靠性的关键所在。
