线程并发redisson使用遇到的坑

为防止超卖,项目采用Redission作为库存保护工具。但在并发场景下,线程在未获得锁时被中断,尝试释放其他线程持有的锁,导致运行时异常。分析发现,应在解锁时判断是否为锁的所有者。解决方案是在调用`lock.unlock()`时确保当前线程是锁的所有者,从而避免并发问题。
背景

因为业务上的一个购买需求,需要对库存进行行程保护,防止超卖的出现(我们不是电商公司),经过调研,最终选择使用Redission来进行控制。主要因为Redission丰富的API,开源框架,已经被广泛应用于实际生产环境。

问题描述

当我们使用Ression中Lock.lock()方法之后,如果存在线程并发常见情况下,会出现如下异常:
java.lang.IllegalMonitorStateException: attempt to unlock lock, not locked by current thread by node id: 9f178836-f7e1-44fe-a89d-2db52f399c0d thread-id: 22

问题分析

在thread-1还没有结束的时候,也就是在thread-1在获得锁但是还没有释放锁的时候, `thread-2由于被别的线程中断停止了等待从lock.tryLock的阻塞状态中返回继续执行接下来的逻辑,并且由于尝试去释放一个属于线程thread-1的锁而抛出了一个运行时异常导致该线程thread-2结束了, 然而thread-2完成了一系列操作后,线程thread-1才释放了自己的锁. 所以thread-2并没有获得锁,却执行了需要同步的内容,还尝试去释放锁。那解决方式我们就知道了,当前线程加的锁由当前线程去解锁,也就是说当我们使用lock.unlock的时候加上线程的判断即可。

问题解决
 RLock lock = redissonClient.getLock(key);
    if(lock.isLocked()){ // 是否还是锁定状态
      if(lock.isHeldByCurrentThread()){ // 时候是当前执行线程的锁
        lock.unlock(); // 释放锁
      }
    }

微信公众号

评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值