关于RedissonLock的一些所思

关于RedissonClient.getLock()

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

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

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

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

RedissonClient.getLock()放在哪里？

public class OrderService{private RLock myLock = redissonClient.getLock("my_order");public void createOrder(){RLock myLock2 = redissonClient.getLock("my_order");//myLock.lock();//myLock2.lock();}
}

就上面的例子，使用myLock2肯定是OK的。那能使用myLock么？我还不确定。。。。

看门狗机制

使用锁的时候，有个问题，就是当某个线程从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.isLocked() && lock.isHeldByCurrentThread()

一个demo

  public static void saveOrder(){Config config = new Config();config.useSingleServer().setAddress("redis://127.0.0.1:6379");redissonClient = Redisson.create(config);RLock myLock = redissonClient.getLock("order");try {boolean canPass = myLock.tryLock(3, TimeUnit.SECONDS);if (canPass){// my logic}else{// .....}}catch (Exception e){} finally {if (myLock.isLocked() && myLock.isHeldByCurrentThread()){myLock.unlock();}}}

当然 上面的redissonClient 一般都是自动注入的。

参考资料

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