学向勤中得,萤窗万卷书。这篇文章主要讲述Java有了synchronized,为什么还要提供Lock相关的知识,希望能为你提供帮助。
摘要:在java中提供了synchronized关键字来保证只有一个线程能够访问同步代码块。既然已经提供了synchronized关键字,那为何在Java的SDK包中,还会提供Lock接口呢?本文分享自华为云社区《??Java中提供了synchronized,为什么还要提供Lock呢???》,作者: 冰 河。
在Java中提供了synchronized关键字来保证只有一个线程能够访问同步代码块。既然已经提供了synchronized关键字,那为何在Java的SDK包中,还会提供Lock接口呢?这是不是重复造轮子,多此一举呢?今天,我们就一起来探讨下这个问题。
再造轮子?既然JVM中提供了synchronized关键字来保证只有一个线程能够访问同步代码块,为何还要提供Lock接口呢?这是在重复造轮子吗?Java的设计者们为何要这样做呢?让我们一起带着疑问往下看。
为何提供Lock接口?很多小伙伴可能会听说过,在Java 1.5版本中,synchronized的性能不如Lock,但在Java 1.6版本之后,synchronized做了很多优化,性能提升了不少。那既然synchronized关键字的性能已经提升了,那为何还要使用Lock呢?
如果我们向更深层次思考的话,就不难想到了:我们使用synchronized加锁是无法主动释放锁的,这就会涉及到死锁的问题。
死锁问题如果要发生死锁,则必须存在以下四个必要条件,四者缺一不可。
- 互斥条件
- 不可剥夺条件
- 请求与保持条件
- 循环等待条件
synchronized的局限性如果我们的程序使用synchronized关键字发生了死锁时,synchronized关键是是无法破坏“不可剥夺”这个死锁的条件的。这是因为synchronized申请资源的时候, 如果申请不到, 线程直接进入阻塞状态了, 而线程进入阻塞状态, 啥都干不了, 也释放不了线程已经占有的资源。
然而,在大部分场景下,我们都是希望“不可剥夺”这个条件能够被破坏。也就是说对于“不可剥夺”这个条件,占用部分资源的线程进一步申请其他资源时, 如果申请不到, 可以主动释放它占有的资源, 这样不可剥夺这个条件就破坏掉了。
如果我们自己重新设计锁来解决synchronized的问题,我们该如何设计呢?
解决问题了解了synchronized的局限性之后,如果是让我们自己实现一把同步锁,我们该如何设计呢?也就是说,我们在设计锁的时候,要如何解决synchronized的局限性问题呢?这里,我觉得可以从三个方面来思考这个问题。
(1)能够响应中断。 synchronized的问题是, 持有锁A后, 如果尝试获取锁B失败, 那么线程就进入阻塞状态, 一旦发生死锁, 就没有任何机会来唤醒阻塞的线程。 但如果阻塞状态的线程能够响应中断信号, 也就是说当我们给阻塞的线程发送中断信号的时候, 能够唤醒它, 那它就有机会释放曾经持有的锁A。 这样就破坏了不可剥夺条件了。
(2)支持超时。 如果线程在一段时间之内没有获取到锁, 不是进入阻塞状态, 而是返回一个错误, 那这个线程也有机会释放曾经持有的锁。 这样也能破坏不可剥夺条件。
(3)非阻塞地获取锁。 如果尝试获取锁失败, 并不进入阻塞状态, 而是直接返回, 那这个线程也有机会释放曾经持有的锁。 这样也能破坏不可剥夺条件。
体现在Lock接口上,就是Lock接口提供的三个方法,如下所示。
// 支持中断的API
void lockInterruptibly() throws InterruptedException;
// 支持超时的API
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
// 支持非阻塞获取锁的API
boolean tryLock();
- lockInterruptibly()
- tryLock()方法
- tryLock(long time, TimeUnit unit)方法
也就是说,对于死锁问题,Lock能够破坏不可剥夺的条件,例如,我们下面的程序代码就破坏了死锁的不可剥夺的条件。
public class TansferAccount
private Lock thisLock = new ReentrantLock();
private Lock targetLock = new ReentrantLock();
//账户的余额
private Integer balance;
//转账操作
public void transfer(TansferAccount target, Integer transferMoney)
boolean isThisLock = thisLock.tryLock();
if(isThisLock)
try
boolean isTargetLock = targetLock.tryLock();
if(isTargetLock)
try
if(this.balance > = transferMoney)
this.balance -= transferMoney;
target.balance += transferMoney;
finally
targetLock.unlock
finally
thisLock.unlock();
例外,Lock下面有一个ReentrantLock,而ReentrantLock支持公平锁和非公平锁。
在使用ReentrantLock的时候, ReentrantLock中有两个构造函数, 一个是无参构造函数, 一个是传入fair参数的构造函数。 fair参数代表的是锁的公平策略, 如果传入true就表示需要构造一个公平锁, 反之则表示要构造一个非公平锁。如下代码片段所示。
//无参构造函数: 默认非公平锁
public ReentrantLock()
sync = new NonfairSync();
//根据公平策略参数创建锁
public ReentrantLock(boolean fair)
sync = fair ? new FairSync() : new NonfairSync();
锁的实现在本质上都对应着一个入口等待队列, 如果一个线程没有获得锁, 就会进入等待队列, 当有线程释放锁的时候, 就需要从等待队列中唤醒一个等待的线程。 如果是公平锁, 唤醒的策略就是谁等待的时间长, 就唤醒谁, 很公平; 如果是非公平锁, 则不提供这个公平保证, 有可能等待时间短的线程反而先被唤醒。 而Lock是支持公平锁的,synchronized不支持公平锁。
最后,值得注意的是,在使用Lock加锁时,一定要在finally代码块中释放锁,例如,下面的代码片段所示。
try
lock.lock();
finally
lock.unlock();
注:其他synchronized和Lock的详细说明,小伙伴们自行查阅即可。
??点击关注,第一时间了解华为云新鲜技术~??
推荐阅读
- 聊聊程序员面试时,那些必须注意的事情
- #yyds干货盘点# Java 基础 - 反射机制详解
- Python 中的函数式编程三大法宝(mapfilterreduce)
- ASP.NET Core 自动刷新JWT Token #yyds干货盘点#
- Python 从底层结构聊 Beautiful Soup4(内置豆瓣最新电影排行榜爬取案例)!
- 游戏开发新手入门教程13:从想法到设计的过程
- 多图预警! Multi-HeadAttention | 多头注意力#51CTO博主之星评选#
- #yyds干货盘点#剑指 Offer 04. 二维数组中的查找
- #yyds干货盘点# 解决华为机试(配置文件恢复)