Redission Rlock线上出现的bug以及正确的使用

我会带着你远行 2023-06-17 12:54 17阅读 0赞

### 文章目录 ###

*  官网写法
 *  个人解毒（读）
 *  存在的坑
 *  思考
 *  最后

# 官网写法 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODMzNjY1OA_size_16_color_FFFFFF_t_70]

# 个人解毒（读） #

**Redission**

<table> 
 <thead> 
  <tr> 
   <th>方法</th> 
   <th>效果</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>lock()</td> 
   <td>经典面试问题：如果业务执行未完成，锁释放了肿么办？<br>lock()会默认使用一个<strong>看门狗</strong>的机制去延长锁的时间，默认30秒</td> 
  </tr> 
  <tr> 
   <td>lock(long leaseTime, TimeUnit unit)</td> 
   <td>加锁leaseTime时间过后会自动解锁。<br> 这里有个问题，很多人习惯lock(xx,xx)之后再次unlock()，<br><strong>这里就有个坑了，下面再详细讲解</strong></td> 
  </tr> 
  <tr> 
   <td>tryLock(long waitTime, long leaseTime, TimeUnit unit)</td> 
   <td>最多等待waitTime，上锁之后leaseTime自动解锁</td> 
  </tr> 
 </tbody> 
</table>

# 存在的坑 #

在我们不了解业务会执行多久的时候，使用lock(long leaseTime, TimeUnit unit)，就会出现当我业务已经超过锁的时间之后，自动释放锁，这个时候你又去unlock()，会报**IllegalMonitorStateException**，也就是当前的锁已经不是你的了，你没有权限去解锁。

跳坑：我们在unlock的时候调用isHeldByCurrentThread()来判断是否被当前线程占有锁，然后再unlock().

# 思考 #

当出现上面的情况时，就是业务还没执行完，锁已经释放了。那这个分布式锁就废掉了，为啥?  
当A拿到锁，开心的执行的时候，锁超时释放了。但是A还是认为自己拿到锁的，继续开心执行。这时B进来了，拿到锁。那么A和B都拿到锁了，这个分布式锁的意义就不存在了。

引申出其他的问题：我看到我们公司项目的代码，里面锁的是10秒，10秒哦，还报**IllegalMonitorStateException**错误，可以猜测这业务执行得有多慢，得优化。其次锁的粒度也没有控制好，他们把整个业务都包在锁里头。真正需要锁的可能就一小部分业务逻辑，西西~

# 最后 #

写法不规范，接坑人两行泪

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODMzNjY1OA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191129091849213.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODMzNjY1OA==,size_16,color_FFFFFF,t_70