Java并发编程锁之独占公平锁与非公平锁比较
Java并发编程锁之独占公平锁与非公平锁比较
公平锁和非公平锁理解:
在上一篇文章中,我们知道了非公平锁。其实Java中还存在着公平锁呢。公平二字怎么理解呢?和我们现实理解是一样的。大家去排队本着先来先得到的原则,在排队中,无论身份贵贱,一律平等对待。这是就是我们现实生活中的公平。大家都喜欢公平的。但是在Java中默认是非公平的,为什么呢?
本文主要内容:公平锁的现实生活理解;公平锁演示;为什么Java中默认是非公平锁(公平锁的非公平锁的比较)
本篇是《凯哥(凯哥Java:kagejava)并发编程学习》系列之《Lock系列》教程的第四篇:《Java并发包下锁学习第五篇:公平锁理解及与非公平锁的比较》。
生活中的例子:
同样还是去ATM机取钱的例子。假设现在有3个人使用ATM取钱。路人甲不会用ATM,自己摸索耗时5min,然后终于学会怎么使用了,但是密码又忘掉了。打电话给家里人咨询耗时1min.当路人甲操作完成之后,后面两个人排队接着依次操作,这种方式是谁先到谁先操作,操作完成之后下一个人才可以操作的,不管贫富贵贱,不管你是取100还是取1W,取1W的人在取100的人后面,就要排着队等着,这种看上去很公平的,无论贵贱,大家依次操作,这种操作模式站在多线程并发角度来看的话,就是公平锁操作。
在路人甲总耗时6min之后,路人乙和路人丁两个人操作耗时3min。也就是三个人总耗时9min.为什么会产生这种情况呢?因为路人甲堵着了。一直占着锁的资源。在路人甲操作的过程中,其他人只能排队等待。如果路人甲不会操作,排在他后面的路人丙插队询问路人甲,自己可以先插队操作ATM,同时教会路人甲。如果甲同意,则丙可以操作完成后,甲可以学着别人操作,有可能路人甲2min也能操作完成。这个时候,三个人总耗时就是5min了;如果甲不同意丙插队操作,那么丙只能回到原来位置上,进行排队等待。这种操作模式站在多线程并发角度来考虑的话,路人甲在模式及和家人通话耗时看着是CPU切换上下文的耗时。路人丙插队后获取ATM资源,这个操作可以看着是非公平的,因为丙的进入时间比路人乙晚,但是丙先操作了。但是从最后三人总耗时来看,路人丙插队,是的效率提高了。这种操作在Java并发中,称之为非公平锁。
需要说明的是,无论是显式锁还是隐式锁默认都是非公平的。因为非公平能够提升系统的吞吐量。
非公平锁的定义:
线程先尝试着获取同步状态操作(丙先尝试着插队),如果获取到,就对共享变量操作(甲同意丙的插队,丙就操作ATM机),如果获取不到,就接着排队。
使用方法二:独占公平演示
需求:控制台打印的结果和线程顺序一致。代码如下:
此时代码和上一次代码唯一区别如上图:在实例化lock的是有个参数,设置了true.
运行结果:
从运行结果中,我们发现控制台打印出的获取锁的顺序和调用锁的时候顺序是一样的, 已经达到我们预期结果了。但是,还是每次只有一个线程操作,等这个线程操作完成释放锁后,其他线程才可以接着获取锁。
公平锁与非公平锁的比较
问题:
为什么并发大师Doug Lea把ReentrantLock设计默认模式是非公平的?
其实要回答这个问题,就需要从公平锁与非公平锁的不同来进行比较了。我们先来看看ATM机操作在公平锁和非公平锁的场景下,如下图:
公平锁:大家都排队,如果一个线程堵着了(路人甲),其他线程只能等待这个。最终,三个线程操作完成,总耗时9min.
非公平锁情况下:多个线程操作的共享资源的时候,发现共享资源还没有被锁定(路人甲还在摸索过程),就尝试插队(路人丙尝试和甲沟通,先插队操作并教会甲),如果插队成功(甲同意了),就操作共享资源(丙先操作ATM机);如果插队失败(甲不同意),接着排队(丙回到队伍中排队)。如果插队成功,最终耗时:5min.
从中我们可以看出公平锁和非公平锁的优缺点了。
优缺点比较:
非公平锁:
优点:效率高;缺点:容易导致线程“饥饿”。当多个线程使用非公平的话,有可能有一个线程一直就获取不到竞争权,导致这个线程会“饥饿而死”。
适用场景:
如果在不考虑TPS(单位时间内成功完成的次数)作为唯一考量指标的场景下,可以使用非公平锁来操作,因为非公平锁能提高系统的吞吐量;
公平锁:
优点:避免了线程的“饥饿”;缺点:性能相对于公平锁会差很多。
欢迎来聊
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Java并非锁之独占非公平锁理解
Java锁系列教程之独占式锁 在Java并发编程中,锁是一个很重要的对象。Java中锁有两种:隐式锁和显式锁。使用synchronized关键字的锁是隐式锁。因为锁的申请和释放都是由JVM来维护的,不用我们来手动处理。使用Java并发包locks包下的锁,需要使用者手动申请和手动关闭。这种形式是显式锁。如果按照多个线程能不能共享同一个锁(资源)来分的话,可以分为独占式(排他)锁和共享锁。其中synchronized关键字的锁和ReentrantLock锁的锁都是独占式锁。 通过前面三篇文章的学习,我们知道了同步组件基础框架-AbstractQueuedSynchronizer(AQS) 同步器。在同步器的方法中有两种方式获取锁:独占式和共享式锁。我们先来学习独占式锁-ReentrantLock。 本篇是《凯哥(凯哥Java:kagejava)并发编程学习》系列之《Lock系列》教程的第四篇:《Java并发包下锁学习第四篇:ReentrantLock》。 编辑 ReentrantLock使用语法 我们知道并发包下的lock是显式锁,需要手动获取锁和手动释放锁。所以语法如下: Reentr...
- 下一篇
GNOME 3.36.1 稳定版发布
GNOME 团队通过邮件列表宣布推出 GNOME 3.36.1,并表示此版本专门献给那些受到 COVID-19 影响的社区成员,“在这个困难的时刻,我们与你们同在”。 上个月发布的GNOME 3.36 带来了许多新功能和性能改进,GNOME 3.36.1在此基础上进行了首次的错误修复和功能更新。例如,GNOME Shell 3.36.1 修复了应用程序面板上 APP 文件夹显示的问题。在这个版本之前,即使屏幕分辨率足以容纳 4 列的图标,但 APP 文件夹有时依然只使用 3 列进行显示。此问题现已修复。 其他视觉方面的调整包括通过减少填充值(padding)来隐藏文件夹中的叠加滚动条(不是变成非透明状态),并恢复网格中文件夹图标的背景色。 其他变化: 改进对屏幕阅读器的支持 修复在 macOS 下构建 Gedit 的问题 修复 GCC 10 下的编译问题 仅在安装了扩展程序的情况下检查扩展程序更新 Mutter 修复了 GPU hot-plug 上的硬件光标支持问题,支持鼠标上的中间点击模拟,并修复了缩放问题,以及修复使用 OpenGL ES 但不使用桌面 OpenGL 进行构建的问题...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Mario游戏-低调大师作品
- 2048小游戏-低调大师作品
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案