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