如何使用lock.lock()

本篇内容介绍了"如何使用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()"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！