错误信息：
attempt to unlock lock, not locked by current thread by node id: b9df1975-5595-42eb-beae-bdc5d67bce49 thread-id: 52
查看日志，找到对应的堆栈信息：
Exception in thread "thread0" java.lang.IllegalMonitorStateException: attempt to unlock lock, not locked by current thread by node id: b9df1975-5595-42eb-beae-bdc5d67bce49 thread-id: 52
at org.redisson.RedissonLock.lambda$unlockAsync$4(RedissonLock.java:616)
at org.redisson.misc.RedissonPromise.lambda$onComplete$0(RedissonPromise.java:187)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:578)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:552)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:491)
at io.netty.util.concurrent.DefaultPromise.addListener(DefaultPromise.java:184)
at org.redisson.misc.RedissonPromise.onComplete(RedissonPromise.java:181)
at org.redisson.RedissonLock.unlockAsync(RedissonLock.java:607)
at org.redisson.RedissonLock.unlock(RedissonLock.java:492)
at com.qsl.ResissonTest.testLock(ResissonTest.java:41)
at java.lang.Thread.run(Thread.java:748)
翻译过来就是：
企图去释放锁，不被当前线程（node id: b9df1975-5595-42eb-beae-bdc5d67bce49 thread-id: 52）锁住
也就是：当前线程企图去释放别的线程的锁。
怎么能释放别人的锁？
基础回顾
在排查问题之前，我们先弄清楚node id: b9df1975-5595-42eb-beae-bdc5d67bce49 thread-id: 52中的node id和thread-id是什么。
关于thread-id，我相信大家都理解，就是抛异常的线程的 id，没问题吧？那node id呢？
回忆一下八股文：
问：
redisson用的redis的什么数据类型来实现锁的答：
hash问：那
hash中的key、field、value的值分别是什么答：
key的值是锁名，field的值是线程id，value的值是重入次数问：如果多个服务同时去获取一把锁，
field的值是不是有可能相同，比如服务 A 获取锁的线程的thread-id是 52，服务 B 获取锁的线程的的thread-id也是 52此时你是不是有点慌了，但依旧嘴硬的回答：有可能相同
问：那没问题吗，A 服务的线程（
thread-id=52）拿到锁后，正在执行业务处理，B 服务的线程（thread-id=52）也能拿到锁，这不是锁了个寂寞？答：呃...嗯...
很显然漏了个细节，那就是field，其值不是线程id，而是node id:thread-id，例如：b9df1975-5595-42eb-beae-bdc5d67bce49:52 ，而这个node id就是redisson的实例id，用以区分分布式下的redisson实例。
具体来说，在创建RedissonClient时，会生成一个随机的node id，标识当前使用redisson的客户端。参考 Redisson 分布式锁实现之源码篇 → 为什么推荐用 Redisson 客户端。
释放别人的锁
那为什么会释放别人的锁？看下面的代码：
 |
过程如下：
- 构造锁
- 尝试获取锁，等待时间 1s，持锁 3s
- 如果获取到锁，则进行业务处理，没获取到锁，则打印
锁获取失败finally保证异常和非异常情况下，锁都能释放
是不是很正常，但真的没bug吗？
我们调整下代码：
 |
运行multiThreadLock，异常就来了：
 |
从打印信息，我们应该能分析出问题出在哪：
- 线程 52 获取到锁，执行业务中
- 线程 53 尝试获取锁，但锁被线程 52 持有
- 线程 53 1s 内获取锁失败
- 线程 53 来到
finally，判断锁是否被持有，发现是被持有的，释放锁redisson释放锁的时候，发现锁的持有线程并非当前线程，抛出异常
问题修复
既然找到问题了，修复问题就很简单了，方式有以下几种。
提高等待时长
将获取锁的等待时长提高，但这种方式只能减少异常，并不是完全修复异常；因为会有多个线程同时竞争锁，等待时长设置成多少都不合适，除非设置成不超时，但是设置成不超时，可能会导致等待的线程太多，造成线程不够用的情况。不推荐该方式。
自动释放
去掉finally，相当于把产生异常的源头给干掉了，那肯定就不会有异常了嘛。
解决不了问题，那就把提出问题的人解决掉
不主动释放锁，让锁自动到期释放，因为我们设置了锁持有时长是 3s，3s 后就自动到期释放了。但在实际业务中，我们往往会把锁持有时长设置的比较大（远大于业务执行的平均时长），保证业务不会并发执行，如果业务执行完了不主动释放锁，就会导致很长时间内锁被无效占用，后面的线程获取锁也只能白白等待。不推荐该方式。
记录获取状态
下面的代码尝试使用acquired变量记录当前线程是否获取到锁，释放锁的时候，判断是否加锁成功，如果加锁了，才释放锁。
 |
如果业务执行时间超过 3s，会怎么样，我们把睡眠时间改成 5s，执行下testLock，你会发现同样的异常又出现了！！！
 |
我们来分析下，锁持有时长是 3s，而业务执行时长是 5s，也就说业务还没执行完，锁已到期，redis自动释放了，业务执行完之后我们再去释放锁，锁都没了，怎么释放？所以redisson抛出异常了；所以释放锁的时候，还需要加一个条件
if (acquired && lock.isLocked())
acquired表示当前线程是否获取到锁了，而lock.isLocked()表示是否有线程持有锁，如果都为true，那就说明是当前线程持有锁，释放是不是就没问题了？我们继续分析，假设第 4s 的时候，另外一个线程来获取锁，获取成功（因为当前线程的锁 3s 到期自动释放了嘛），第 5s 的时候，当前线程业务执行完成，来到 if 条件进行判断，当前线程的acquired为true（只能表示曾经拥有，而非此刻拥有），lock.isLocked()也为true（另外线程持有，而非当前线程持有），if 条件满足，去释放锁，结果可想而知，当前线程释放别的线程的锁，依旧会抛异常，而这个异常正是文章开头说到的那个异常。同样不推荐该方式。
判断持有者
这种写法更优雅：
 |
就直接判断锁是不是当前线程持有，是就可以释放；就不用去管锁是别的线程持有，还是到期自动释放了。推荐该方式。
持有者释放
如下图所示：
 |
锁不设置过期时间，由看门狗进行续期；当前线程获取锁之后，业务执行期间，锁一直被当前线程持有，业务执行完成之后，再由当前线程进行释放。谁持有谁释放，正是我们需要的，推荐该方式。
标签：释放,Redisson,attempt,thread,java,52,报错,线程,id From： https://www.cnblogs.com/Higurashi-kagome/p/18645356