Redisson 3.27.0 tryLock 与 lock 源码对比：3个关键差异点与选型决策树

Redisson 3.27.0 tryLock与lock源码深度解析：3个核心差异与工程实践指南

1. 分布式锁的本质与Redisson设计哲学

在现代分布式系统中，锁机制是协调多节点并发访问的基石。不同于单机环境下的synchronized或ReentrantLock，分布式锁需要解决网络分区、时钟漂移、节点故障等复杂问题。Redisson作为Redis官方推荐的Java客户端，其分布式锁实现具有以下设计特点：

• 看门狗机制：自动续期避免业务未完成时锁过期
• 可重入设计：同一线程可多次获取同一把锁
• Lua脚本原子性：所有锁操作通过Redis单线程特性保证原子性
• 多种锁类型：支持公平锁、联锁、红锁等复杂场景

// 典型锁使用示例 RLock lock = redisson.getLock("resourceLock"); try { if (lock.tryLock(10, 30, TimeUnit.SECONDS)) { // 业务逻辑 } } finally { lock.unlock(); }

2. 核心差异一：阻塞行为与线程调度

2.1 lock方法的阻塞特性

lock()方法会无限期阻塞当前线程，直到获取到锁。其底层通过Redis的PUB/SUB机制实现等待通知，关键源码片段：

// RedissonLock.java public void lock() { try { lock(-1, null, false); } catch (InterruptedException e) { throw new IllegalStateException(); } } private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException { long threadId = Thread.currentThread().getId(); // 尝试获取锁 Long ttl = tryAcquire(-1, leaseTime, unit, threadId); if (ttl == null) { return; } // 订阅锁释放消息 RFuture<RedissonLockEntry> future = subscribe(threadId); // 循环尝试获取锁 while (true) { ttl = tryAcquire(-1, leaseTime, unit, threadId); if (ttl == null) { break; } // 等待锁释放信号 getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS); } }

2.2 tryLock的非阻塞尝试

tryLock()允许设置最大等待时间(waitTime)，超时后立即返回false。其实现通过组合等待时间和系统时钟检测：

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException { long time = unit.toMillis(waitTime); long current = System.currentTimeMillis(); long threadId = Thread.currentThread().getId(); // 首次快速尝试 Long ttl = tryAcquire(waitTime, leaseTime, unit, threadId); if (ttl == null) { return true; } // 计算剩余等待时间 time -= System.currentTimeMillis() - current; if (time <= 0) { return false; } // 有限次重试 while (true) { current = System.currentTimeMillis(); ttl = tryAcquire(waitTime, leaseTime, unit, threadId); if (ttl == null) { return true; } time -= System.currentTimeMillis() - current; if (time <= 0) { return false; } // 等待锁释放信号 getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS); } }

2.3 性能对比与选型建议

工程实践提示：在高并发场景下，不当使用lock()可能导致线程池耗尽。建议优先考虑tryLock()配合降级策略。

3. 核心差异二：异常处理与中断响应

3.1 lock的中断不敏感性

标准lock()方法不响应Thread.interrupt()，这是其设计上的权衡：

public void lock() { try { lock(-1, null, false); // interruptibly参数固定为false } catch (InterruptedException e) { // 实际不会执行到此处 throw new IllegalStateException(); } }

3.2 tryLock的中断友好设计

tryLock()完整支持Java中断机制，这对响应式编程非常重要：

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException { // ... if (Thread.interrupted()) { throw new InterruptedException(); } // 等待过程会检查中断状态 getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS); }

3.3 异常处理最佳实践

// 推荐的处理模板 RLock lock = redisson.getLock("orderLock"); try { if (lock.tryLock(3, 30, TimeUnit.SECONDS)) { processOrder(); } else { log.warn("获取订单锁超时"); fallbackProcess(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 log.error("订单处理被中断", e); throw new BusinessException("系统繁忙"); } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }

4. 核心差异三：看门狗机制与租约时间

4.1 lock的自动续约机制

当不指定leaseTime时，lock()会启用看门狗（默认30秒续期）：

private <T> RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) { if (leaseTime != -1) { return tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG); } // 启用看门狗 RFuture<Long> ttlRemainingFuture = tryLockInnerAsync( waitTime, commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG); ttlRemainingFuture.onComplete((ttlRemaining, e) -> { if (e != null) { return; } if (ttlRemaining == null) { scheduleExpirationRenewal(threadId); // 启动续期任务 } }); return ttlRemainingFuture; }

4.2 tryLock的固定租约策略

tryLock()在指定leaseTime后会禁用看门狗，到期自动释放：

-- 底层Lua脚本片段 if (redis.call('exists', KEYS[1]) == 0) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end;

4.3 参数配置决策树

graph TD A[需要确保业务完成?] -->|是| B[使用lock()自动续期] A -->|否| C{能否预估最大耗时?} C -->|能| D[tryLock+适当leaseTime] C -->|不能| E[tryLock+看门狗+监控告警]

危险警示：误用leaseTime可能导致业务未完成锁已释放。对于耗时操作，建议结合熔断器模式使用。

5. 工程实践与性能优化

5.1 锁粒度设计原则

• 细粒度锁：按业务ID拆分（如order:1001）
• 分段锁：库存场景可使用stock:1001:segment1等
• 避免全局锁：如必须使用，设置合理超时

5.2 高性能锁配置

Config config = new Config(); config.useClusterServers() .setTimeout(1000) .setRetryInterval(1500); // 优化看门狗间隔 config.setLockWatchdogTimeout(30000L); // 默认30秒 RedissonClient redisson = Redisson.create(config);

5.3 监控指标建议

6. 典型场景解决方案

6.1 秒杀系统实现

public boolean seckill(Long itemId, Long userId) { String lockKey = "seckill:" + itemId; RLock lock = redisson.getLock(lockKey); try { // 快速失败策略 if (!lock.tryLock(0, 10, TimeUnit.SECONDS)) { return false; } int stock = getStock(itemId); if (stock <= 0) { return false; } return updateStock(itemId, stock - 1) > 0; } finally { lock.unlock(); } }

6.2 定时任务防重

@Scheduled(cron = "0 0/5 * * * ?") public void generateReport() { RLock lock = redisson.getLock("reportJob"); if (lock.tryLock()) { try { // 生成报表 } finally { lock.unlock(); } } }

6.3 分布式事务协调

public void transfer(Long from, Long to, BigDecimal amount) { RLock lock1 = redisson.getLock("account:" + from); RLock lock2 = redisson.getLock("account:" + to); RedissonMultiLock multiLock = new RedissonMultiLock(lock1, lock2); try { if (multiLock.tryLock(100, 10, TimeUnit.SECONDS)) { // 转账业务 } } finally { multiLock.unlock(); } }

在Redisson的实际应用中，我们发现tryLock()配合合理的waitTime参数，能够显著降低系统死锁风险。特别是在微服务架构中，建议将锁等待时间与上游服务的超时时间联动配置，形成完整的超时控制链。