抛出错误异常：attempt to unlock lock, not locked by current thread by node id
根据意思大概就是：thread-1还没有结束的时候,也就是在thread-1在获得锁但是还没有释放锁的时候，thread-2由于尝试去释放一个属于线程thread-1的锁而抛出了一个运行时异常
thread-1的线程作为了Key，thread-2无法获取该锁去执行了释放锁的操作
猜想：
当同一个线程中去加锁和解锁，这个主要也是出于分布式锁安全设计，只有加锁的人才能解锁自己加的锁，别人是无法来中断自己加的锁，当然如果是考虑到需要别人来操作我这边锁，可以自己手写一个锁
当前被改为：
优点和缺点
优点：
1. Redisson 通过 Watch Dog 机制很好的解决了锁的续期问题。
2. 和 Zookeeper 相比较，Redisson 基于 Redis 性能更高，适合对性能要求高的场景。
3. 通过 Redisson 实现分布式可重入锁，比原生的 SET mylock userId NX PX milliseconds + lua 实现的效果更好些，虽然基本原理都一样，但是它帮我们屏蔽了内部的执行细节。
4. 在等待申请锁资源的进程等待申请锁的实现上也做了一些优化，减少了无效的锁申请，提升了资源的利用率。
缺点：
1、使用 Redisson 实现分布式锁方案最大的问题就是如果你对某个 Redis Master 实例完成了加锁，此时 Master 会异步复制给其对应的 slave 实例。但是这个过程中一旦 Master 宕机，主备切换，slave 变为了 Master。接着就会导致，客户端 2 来尝试加锁的时候，在新的 Master 上完成了加锁，而客户端 1 也以为自己成功加了锁，此时就会导致多个客户端对一个分布式锁完成了加锁，这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。所以这个就是 Redis Cluster 或者说是 Redis Master-Slave 架构的主从异步复制导致的 Redis 分布式锁的最大缺陷（在 Redis Master 实例宕机的时候，可能导致多个客户端同时完成加锁）（后面有Redission红锁可以解决）
结束
整理不易，记得点个赞，你的支持是我最大的动力