关于RedissonLock的一些所思

pom依赖

        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.18.0</version>
        </dependency>

关于RedissonClient.getLock()

我们一般的使用Redisson的方式就是：

 RLock myLock = redissonClient.getLock("my_order");
 //myLock.lock();
 //myLock.tryLock();

就上面的例子里，如果某个线程已经拿到了my_order的锁，那别的线程调用myLock.lock方法就会阻塞。

不过现在我的问题是，如果某个线程已经持有了my_order的锁，那其余的线程调用redissonClient.getLock(“my_order”); 这一步会阻塞么？
答案是不会阻塞。

看门狗机制

使用锁的时候，有个问题，就是当某个线程从redis拿到了锁之后，一般要告诉redis这个锁最长多久就要自动删除（如果不这么做，一旦某个线程自己死掉了，那redis就认为这锁一直被某个线程持有着，就不会放别的线程进来了，相当于卡死了整个系统）
但是上面的流程有一个问题，这个锁的持有时间该怎么设计呢？5s？10s？如果某次我的逻辑执行的时间超过了那个设定的时间怎么办？
所以后面Redisson就有了一个看门狗机制。什么意思呢？就是业务方使用锁的时候，也不用指定那个自动删除时间，用户使用锁的时候Redisson就会自动每隔10s调用一次redis，把锁的超时时间往后推30s。这样如果持有锁的线程死掉了，那redis最多30s也会自动把那个锁清理掉。

lock方法与tryLock方法

lock和tryLock的区别

• 返回值
  lock 是 void；
  tryLock 是 boolean。

• 时机
  lock 一直等锁释放；
  tryLock 获取到锁直接返回true，获取不到锁就直接返回false。
  上面是基本用法，但是问题是lock方法和trylock方法都有重载方法呀！！！

方法签名	可以拿到锁	不可以拿到锁	拿到锁之后的超时时间
lock.lock()	立即返回void	一直阻塞	没有超时时间，由看门狗保证锁不会卡死
lock.lock(50,TimeUnit.SECONDS);	立即返回void	一直阻塞	持有锁最多50秒，50s以后，不管用户是否主动释放，redis都会删除锁
lock.tryLock()	立即返回true	立即返回false	没有超时时间，由看门狗保证锁不会卡死
lock.tryLock(3, TimeUnit.SECONDS);	立即返回true	最多等待3秒，3秒后如果还是没有就返回false	没有超时时间，由看门狗保证锁不会卡死
lock.tryLock(3,50,TimeUnit.SECONDS);	立即返回true	最多等待3秒，3秒后如果还是没有就返回false	持有锁最多50秒，50s以后，不管用户是否主动释放，redis都会删除锁

建议使用lock.tryLock()与lock.tryLock(3, TimeUnit.SECONDS)这两种形式

怎么关闭锁

必须判断

 lock.isHeldByCurrentThread()

一个demo

  public static void saveOrder(Long orderId){

        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        redissonClient = Redisson.create(config);
        
        RLock myLock = redissonClient.getLock("order_" + orderId);
        boolean canPass = false;
        try {
            canPass = myLock.tryLock(3, TimeUnit.SECONDS);
            if (canPass){
                // my logic
            }else{
            	// .....
            }
        }catch (Exception e){

        } finally {
            if (canPass && myLock.isHeldByCurrentThread()){
                myLock.unlock();
            }
        }
    }

当然 上面的redissonClient 一般都是自动注入的。
使用isHeldByCurrentThread主要是为了避免，自己线程上获得的锁，但是已经过期，被别的线程拿走了
那其实
除非你是使用下面两种方式获得锁

lock.lock(50,TimeUnit.SECONDS);
lock.tryLock(3,50,TimeUnit.SECONDS);	

才需要判断isHeldByCurrentThread
因为别的方法都有看门狗机制，保证在在使用期间锁不会过期。
那如果我使用下面这两种形式呢

lock.tryLock()
lock.tryLock(3, TimeUnit.SECONDS)

理论上不需要判断isHeldByCurrentThread

扩展

大家看上面saveOrder的代码，整个代码里大部分都是模版代码，而且关键的时得记得最终在finally里面的unlock锁。
所以有没有什么办法精简一下代码呢？
有呀，使用aop，把模板抽出去，这样用户只用关注业务代码就好。
大家可以参考这个工程
kq-universal-redis-starter
基于注解的Redisson锁

参考资料

https://www.bmabk.com/index.php/post/5410.html