redisson tryLock

应用场景
RLock rLock = redissonClient.getLock(Constant_LOCK + request.getId());
try {
    boolean isLocked = rLock.tryLock();
    if (!isLocked) {
        throw new ServiceException(ErrConstant.OPERATION_FAILED, "请勿重复提交");
    }
源码
public interface RLock extends Lock, RLockAsync {
    String getName();

    void lockInterruptibly(long var1, TimeUnit var3) throws InterruptedException;

    boolean tryLock(long var1, long var3, TimeUnit var5) throws InterruptedException;

    void lock(long var1, TimeUnit var3);

    boolean forceUnlock();

    boolean isLocked();

    boolean isHeldByThread(long var1);

    boolean isHeldByCurrentThread();

    int getHoldCount();

    long remainTimeToLive();
}

实际上 

tryLock 是lock接口方法,redisson重写了

Redisson tryLock(long time, TimeUnit unit) 方法深度解析

Redisson 的 tryLock(long time, TimeUnit unit) 方法是分布式锁的核心 API 之一,下面我将从多个维度详细解析其工作原理和使用场景。

方法签名

java

boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException;

核心特性解析

1. 参数含义

  • waitTime:获取锁的最大等待时间

  • leaseTime:锁的持有时间(自动释放时间)

  • unit:时间单位

2. 返回值

  • true:成功获取锁

  • false:在等待时间内未获取到锁

底层实现机制

1. Redis 数据结构

使用 Hash 结构存储锁信息:

text

key: "lock_name"
field: "客户端ID:线程ID"
value: 重入次数

2. Lua 脚本原子操作

Redisson 通过 Lua 脚本保证原子性:

lua

-- 尝试获取锁的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
-- 已存在锁时的处理...

3. 看门狗机制(leaseTime = -1 时)

  • 默认情况下启动看门狗

  • 每 10 秒(默认)检查并续期锁

  • 保持锁直到显式释放

典型使用场景

1. 基本用法

java

RLock lock = redisson.getLock("myLock");
boolean isLocked = lock.tryLock(10, 30, TimeUnit.SECONDS);
try {
    if (isLocked) {
        // 业务逻辑
    }
} finally {
    if (isLocked) {
        lock.unlock();
    }
}

2. 不同参数组合效果

waitTimeleaseTime行为特点
0>0立即尝试,获取失败直接返回
>0>0在指定时间内循环尝试
>0-1获取成功后启动看门狗自动续期
0-1立即尝试+自动续期

异常处理要点

  1. InterruptedException

    • 等待期间线程被中断会抛出

    • 需要正确处理中断状态

  2. 锁续期失败

    • 看门狗续期失败会自动释放锁

    • 业务代码应实现幂等性

性能优化建议

  1. 合理设置等待时间

    • 避免设置过长的 waitTime

    • 根据业务平均处理时间设置 leaseTime

  2. 避免锁竞争

    java

    // 使用随机退避
    while (!lock.tryLock(50, 100, TimeUnit.MILLISECONDS)) {
        Thread.sleep(random.nextInt(100));
    }
  3. 监控建议

    • 监控锁等待时间

    • 设置锁等待超时告警

与其他方法的对比

方法特点适用场景
lock()阻塞直到获取锁必须获取锁的场景
tryLock()尝试获取,可设置超时有限等待的场景
tryLock(0, ...)立即尝试一次非阻塞快速失败场景

实现原理示意图

text

[客户端A] --(tryLock)--> [Redis服务器]
       |___ 1. 检查锁是否存在
       |___ 2. 不存在则获取锁
       |___ 3. 存在则等待重试
       |___ 4. 获取成功启动看门狗(leaseTime=-1)

使用注意事项

  1. 必须释放锁

    java

    try {
        if (lock.tryLock(...)) {
            // ...
        }
    } finally {
        lock.unlock();
    }
  2. 避免死锁

    • 确保 leaseTime > 业务执行时间

    • 或使用默认的看门狗机制

  3. 集群模式特殊处理

    • RedLock 算法需要多数节点确认

    • 网络分区时可能有脑裂问题

<think>我们正在讨论Redisson的锁续期机制,特别是它如何检测持有锁的线程是否已经结束或崩溃。 根据引用[^1],我们知道Redisson通过看门狗(Watchdog)机制来实现锁的续期。这个机制会定期检查持有锁的线程是否还活跃,如果活跃则延长锁的持有时间(即续期),如果线程已经结束或崩溃,则锁会被释放。 具体来说,Redisson的锁续期机制是通过一个后台线程(看门狗线程)来实现的。当客户端成功获取锁后,会启动一个看门狗线程,该线程会定期(默认是锁过期时间的1/3)去检查锁是否还被当前线程持有。如果锁仍然被当前线程持有,那么看门狗线程就会对锁进行续期(即重新设置锁的过期时间)。 那么,如何检测线程是否结束或崩溃呢? 在Redisson中,当获取锁时,会记录当前线程的ID(在分布式环境中,这个ID通常由客户端生成,确保唯一性)。看门狗线程在续期时,会检查当前线程是否还存活(通过Java的Thread类提供的方法,如isAlive()方法)。如果线程已经终止(即不再存活),那么看门狗线程就不会再续期,从而让锁自然过期。 但是,这里有一个关键点:在分布式系统中,一个线程的崩溃(比如整个JVM崩溃)是无法通过另一个JVM(或另一个节点)来检测该线程是否存活的。因此,Redisson实际上并不是直接检测线程是否存活,而是通过以下方式: 1. 在同一个JVM内:如果持有锁的线程已经结束(正常结束或异常崩溃),那么看门狗线程(如果还在运行)会检测到当前线程已经不再存活,从而停止续期。但是,如果整个JVM崩溃,那么看门狗线程也会随之停止,因此不会进行续期操作。 2. 在分布式环境中:Redisson的锁续期机制依赖于与Redis的通信。看门狗线程会定期向Redis发送续期命令(通过Lua脚本)。如果持有锁的客户端崩溃了(比如整个JVM崩溃),那么看门狗线程也会停止,因此不会发送续期命令,锁在Redis中就会自动过期。 因此,看门狗机制的关键在于:它只在持有锁的客户端还存活并且能够与Redis通信的情况下才会续期。如果客户端崩溃,那么续期操作就会停止,锁就会自动释放。 总结一下,Redisson锁续期机制检测线程结束或崩溃的方式: - 对于同一个JVM内的线程结束:通过检查线程状态(isAlive())来停止续期。 - 对于客户端崩溃(如JVM崩溃):看门狗线程也会停止,因此不会续期,锁自动过期。 需要注意的是,锁的默认过期时间是30秒,看门狗线程每10秒(即30/3)续期一次,将锁的过期时间重置为30秒。 下面是一个简化的流程: 1. 线程A获取锁成功,Redisson启动一个看门狗线程(如果还没有的话)。 2. 看门狗线程每隔10秒检查一次: a. 检查当前线程(线程A)是否还持有该锁(通过比较Redis中存储的锁的值,该值包含了线程ID等信息)并且线程A是否还存活。 b. 如果线程A还持有锁且线程A还存活,则执行续期操作(将锁的过期时间重置为30秒)。 c. 如果线程A已经不再持有锁(比如被其他线程释放了)或者线程A已经结束(isAlive()返回false),则不再续期,并结束看门狗线程。 3. 如果线程A在持有锁期间崩溃(整个JVM崩溃),那么看门狗线程也会停止,因此不会续期,锁在30秒后自动过期。 这样,就避免了因为持有锁的线程崩溃而导致锁一直不被释放的问题。 引用[^1]提到了Radisson(应为Redisson)的看门狗机制,它类似于AQS的实现(在分布式环境中的实现),通过后台线程来监听锁的状态并续期。 因此,用户的问题得到解答:Redisson通过看门狗线程定期检查持有锁的线程是否存活(在同一个JVM内)以及通过续期操作的停止(在客户端崩溃时)来检测线程结束或崩溃。 现在,我们根据用户的问题,生成相关问题:</think>### Redisson 锁续期机制解析 Redisson 的锁续期机制(看门狗机制)通过以下方式检测线程结束或崩溃: 1. **线程状态监控** Redisson 在获取锁时为当前线程注册一个监控任务(看门狗线程),定期(默认10秒)检查持有锁的线程状态: - 通过 Java 的 `Thread.isAlive()` 方法判断线程是否存活 - 若线程已终止(`isAlive() == false`),立即停止续期并释放锁 - 示例代码逻辑: ```java if (!Thread.currentThread().isAlive()) { unlock(); // 释放锁 cancelRenewal(); // 停止续期 } ``` 2. **JVM 崩溃检测** 当整个 JVM 崩溃时: - 看门狗线程随进程终止而销毁 - Redis 中的锁 key 因**未续期而自动过期**(默认30秒) - 其他线程可在超时后重新获取锁 3. **续期失败处理** 续期操作通过 Redis Lua 脚本实现原子性验证: ```lua if redis.call("hexists", KEYS[1], ARGV[2]) == 1 then redis.call("pexpire", KEYS[1], ARGV[1]); return 1; end; return 0; ``` - 续期前验证线程ID是否匹配 - 若线程崩溃导致ID不匹配,续期失败触发锁释放 4. **双重超时保障** - **锁租约时间**:默认30秒,Redis 自动过期释放 - **续期间隔**:默认10秒(租约时间的1/3) - 任一超时均可触发锁释放 [^1] 引用说明:Redisson 通过线程状态检测和租约超时双重机制保障锁释放,避免因线程崩溃导致的死锁问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值