没有合适的资源?快使用搜索试试~ 我知道了~
synchronized和LOCK的实现原理深入JVM锁机制比较好.docx
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 98 浏览量
2022-07-09
12:34:38
上传
评论
收藏 439KB DOCX 举报
温馨提示
试读
13页
synchronized和LOCK的实现原理深入JVM锁机制比较好.docx
资源推荐
资源详情
资源评论
JVM 底层又是如何实现 synchronized 的?
目前在 Java 中存在两种锁机制:synchronized 和 Lock,Lock 接口及其实现类是 JDK5
增加的内容,其作者是大名鼎鼎的并发专家Doug Lea。本文并不比较 synchronized 与 Lock
孰优孰劣,只是介绍二者的实现原理。
数据同步需要依赖锁,那锁的同步又依赖谁?synchronized 给出的答案是在软件层面依
赖
JVM,而
Lock 给出的方案是在硬件层面依赖特殊的 CPU 指令
,大家可能会进一步追问
:JVM 底层又是如何实现 synchronized 的?
本文所指说的 JVM 是指 Hotspot 的6u23版本,下面首先介绍 synchronized 的实现:
synrhronized 关键字简洁、清晰、语义明确,因此即使有了Lock 接口,使用的还是非常
广泛。其应用层的语义是可以把任何一个非 null 对象 作为"锁",当 synchronized 作用在方
法上时,锁住的便是对象实例(
this
);当作用在静态方法时锁住的便是对象对应的
Class
实
例,因为 Class 数据存在于永久带,因此静态方法锁相当于该类的一个全局锁;当
synchronized 作用于某一个对象实例时,锁住的便是对应的代码块。在 HotSpot JVM 实现中,
锁有个专门的名字:对象监视器。
1.
线程状态及状态转换
当多个线程同时请求某个对象监视器时,对象监视器会设置几种状态用来区分请求的线程:
Contention List:所有请求锁的线程将被首先放置到该竞争队列
Entry List:Contention List 中那些有资格成为候选人的线程被移到Entry List
Wait Set:那些调用 wait 方法被阻塞的线程被放置到 Wait Set OnDeck
:任何时刻最多只能有一个线程正在竞争锁,该线程称为OnDeck Owner
:获得锁的线程称为 Owner
!Owner:释放锁的线程
下图反映了个状态转换关系:
新请求锁的线程将首先被加入到 ConetentionList 中,当某个拥有锁的线程(Owner 状态)
调用 unlock 之后,如果发现 EntryList 为空则从 ContentionList 中移动线程到 EntryList,下
面说明下 ContentionList 和 EntryList 的实现方式:
1.1
ContentionList 虚拟队列
ContentionList
并不是一个真正的
Queue
,而只是一个虚拟队列,原因在于
ContentionList
是由 Node 及其 next 指 针逻辑构成,并不存在一个Queue 的数据结构。ContentionList 是一
个后进先出(LIFO)的队列,每次新加入Node 时都会在队头进行, 通过 CAS 改变第一个
节点的的指针为新增节点,同时设置新增节点的 next 指向后续节点,而取得操作则发生在
队尾。显然,该结构其实是个 Lock- Free 的队列。
因为只有 Owner 线程才能从队尾取元素,也即线程出列操作无争用,当然也就避免了
CAS 的 ABA 问题。
1.2
EntryList
EntryList 与 ContentionList 逻辑上同属等待队列,ContentionList 会被线程并发访问,为
了降低对 ContentionList 队尾的争用,而建立 EntryList。Owner 线程在 unlock 时会从
ContentionList 中迁移线程到 EntryList,并会指定 EntryList 中的某个线程(一般为 Head)
为 Ready(OnDeck)线程。Owner 线程并不是把锁传递给 OnDeck 线程,只是把竞争锁的
权利交给 OnDeck,OnDeck 线程需要重新竞争锁。这样做虽然牺牲了一定的公平性,但极
大的提高了整体吞吐量,在 Hotspot 中把 OnDeck 的选择行为称之为“竞争切换”。
OnDeck 线程获得锁后即变为 owner 线程,无法获得锁则会依然留在 EntryList 中,考虑
到公平性,在EntryList 中的位置不 发生变化(依然在队头)。如果 Owner 线程被 wait 方法
阻塞,则转移到 WaitSet 队列;如果在某个时刻被 notify/notifyAll 唤醒, 则再次转移到
EntryList。
2.
自旋锁
那些处于 ContetionList、EntryList、WaitSet 中的线程均处于阻塞状态,阻塞操作由操作
系统完成(在 Linxu 下通 过 pthread_mutex_lock 函数)。线程被阻塞后便进入内核(Linux)
调度状态,这个会导致系统在用户态与内核态之间来回切换,严重影响锁的性能
缓解上述问题的办法便是自旋,其原理是:当发生争用时,若 Owner 线程能在很短的
时间内释放锁,则那些正在争用线程可以稍微等一等(自旋),
在
Owner
线程释放锁后,
争用线程可能会立即得到锁,从而避免了系统阻塞。但 Owner 运行的时间可能会超出了临
界值,争用线程自旋一段时间后还是无法获得锁,这时争用线程则会停止自旋进入阻塞状态
(后退)。基本思路就是自旋,不成功再阻塞,尽量降低阻塞的可能性,这对那些执行时间
很短的代码块来说有非 常重要的性能提高。自旋锁有个更贴切的名字:自旋-指数后退锁,
也即复合锁。很显然,自旋在多处理器上才有意义。
还有个问题是,线程自旋时做些啥?其实啥都不做,可以执行几次for 循环,可以执行几
条空的汇编指令,目的是占着 CPU 不放,等待获取锁的机 会。所以说,自旋是把双刃剑, 如
果旋的时间过长会影响整体性能,时间过短又达不到延迟阻塞的目的。显然,自旋的周期 选择显
得非常重要,但这与操作系统、硬件体系、系统的负载等诸多场景相关,很难选择, 如果选择不当
,不但性能得不到提高,可能还会下降,因此大家普遍认为自旋锁不具有扩展 性。
自旋优化策略
对自旋锁周期的选择上,HotSpot 认为最佳时间应是一个线程上下文切换的时间,但目
前并没有做到。经过调查,目前只是通过汇编暂停了几个 CPU 周期,除了自旋周期选择,
HotSpot 还进行许多其他的自旋优化策略,具体如下:
如果平均负载小于 CPUs 则一直自旋
如果有超过(CPUs/2)个线程正在自旋,则后来线程直接阻塞
如果正在自旋的线程发现 Owner 发生了变化则延迟自旋时间(自旋计数)或进入阻塞
如果 CPU 处于节电模式则停止自旋
自旋时间的最坏情况是 CPU 的存储延迟(CPU A 存储了一个数据,到 CPU B 得知这个
剩余12页未读,继续阅读
资源评论
Cheng-Dashi
- 粉丝: 108
- 资源: 1万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功