问题
解决方案
方案一:
lock.lock(leaseTime, Unit)不设置参数,即lock.lock(),才能触发启动Redission的“看门狗”机制(守护线程)。
否则若设置了参数,则到期就释放掉锁。
方案二:
1. 使用lock.tryLock()替换lock.lock(),不停的尝试解锁。
2. 同时finally中添加代码`if (lock.isLocked && lock.isHeldByCurrentThread())`,先判断锁是否存在、若存在则判断持有锁的是否是当前线程,则才能执行解锁操作。
这样就避免了:
①当前线程业务执行完毕(即锁不存在了,锁存在则看门狗会定时帮着续期)且锁过期释放了(锁已经不存在了),
然后代码又走到了finally中,执行unlock(),导致执行二次释放锁。导致报错(attempt unlock ..企图解锁)。(锁已经不存在了,还解什么锁!当然报错喽~)
②别的线程tryLock()没获取到锁之后,
然后代码也是会走到了finally中,执行unlock(),导致的报错。
分布式锁(三):基于Redisson的分布式锁实践 – 知乎 (zhihu.com)
Redission 解锁异常:attempt to unlock lock, not locked by current thread by node id_ℳ₯㎕ddzོꦿ࿐的博客-CSDN博客
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。