本篇内容介绍了“如何使用lock.lock()”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
lock.lock()
Oracle 文档中在介绍锁的使用时有一段代码,我们以 ReentrantLock 举例,代码如下所示:
ReentrantLock lock = new ReentrantLock(); lock.lock(); try { // access the resource protected by this lock } finally { lock.unlock(); }
Q:为什么要把 lock.unlock() 放到 finally 语句块?
A:为了保证当前线程执行过程中出现异常时,锁依然能被释放掉,避免死锁的产生
我们来改动一下上面的代码,看看会产生什么样的影响
ReentrantLock lock = new ReentrantLock(); try { lock.lock(); // access the resource protected by this lock } finally { lock.unlock(); }
看着没问题呀,为啥文章开始不建议这么用?先说下可能会存在的问题
异常堆栈丢失
假设在 lock.lock 方法中加锁异常(千万不要杠),那么会进入 finally 语句块中进行解锁
继续跟进,看一下 lock.unlock() 源码中是如何处理的
lock.lock() 抛出异常有可能还没获取到锁,那么 解锁源码中将当前线程比较拥有锁线程肯定是不相等的,所以会抛出 IMSE (IllegalMonitorStateException)异常
我重写了 ReentrantLock 加锁代码的逻辑,在里面抛出了异常,一起看下会出现什么情况
final void lock() { // 模拟加锁未成功就抛出异常 if (true) { throw new RuntimeException("报错啦!!!"); } if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); }
根据下图可以看出 加锁时异常堆栈被 "吞掉了",悄无声息的就没了。当然这只是举例,但是谁能保证加锁未成功时不会抛出异常呢
真实存在的 BUG
上面代码示例中都是在 try 的第一行写 lock,出现问题的可能性极低。这里给大家提供一个反面教材,千万千万不要有这种类似行为
示例代码中把 lock 放到了 try 语句块里,然后 lock 加锁前面还有可能会产生异常的代码,这种就凉了,谁用谁凉的那种
“如何使用lock.lock()”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。