Synchronized的JVM底层实现

SynchronizedJVM中的底层实现

1Java中的两种锁

目前Java中存在两种锁机制:Synchronized(使用广泛)Lock

    数据同步需要依赖锁,而Synchronized锁的同步在软件层面需要依赖JVMLock锁的同步在硬件层面需要依赖特殊的CPU指令。

2Synchronized介绍

① 可把任何非NULL对象作为锁

② 作用在方法上时,锁住的便是对象实例(this)

③ 作用在静态方法时,锁住的便是对象对应的Class实例,因为 Class数据存在于永久带,因此静态方法锁相当于该类的一个全局锁

④ 作用某一对象实例时,锁住的便是对应的代码块

    PS:HotSpot JVM实现中,锁有个专门的名字:对象监视器

3、线程状态及状态转换

当多个线程同时请求某个对象监视器时,对象监视器会设置几种状态来区分请求的线程:

Contention List

所有请求锁的线程将被首先放置到该竞争队列

    Entry List

Contention List中那些有资格成为候选人的线程被移到Entry List

    Wait Set

那些调用wait方法被阻塞的线程被放置到Wait Set

    OnDeck

任何时刻最多只能有一个线程正在竞争锁,该线程称为OnDeck

    Owner

获得锁的线程称为Owner

    !Owner

释放锁的线程

1ContentionList 虚拟队列

    ContentionList不是一个真正的Queue,只是一个虚拟队列,原因是:

    ContentionList是由Node及其next指针逻辑构成,并不存在一个Queue的数据结构。该结构其实是个Lock- Free的队列。【即无锁队列】

    ContentionList是一个后进先出(LIFO)的队列,每次新加入Node时都会在队头进行,通过CASCompare And Swap 比较和交换)改变第一个节点的的指针为新增节点,同时设置新增节点的next指向后续节点,而取得操作则发生在队尾。

2EntryList

    EntryListContentionList逻辑上同属等待队列,ContentionList会被线程并发访问,为了降低对 ContentionList队尾的争用,而建立EntryList

    Owner线程在unlock时会从ContentionList中迁移线程到 EntryList,并会指定EntryList中的某个线程(一般为Head)为ReadyOnDeck)线程。

    Owner线程并不是把锁传递给 OnDeck线程,只是把竞争锁的权利交给OnDeckOnDeck线程需要重新竞争锁。

    如此做法,虽然牺牲了一定的公平性,但极大的提高了整体吞吐量,在 Hotspot中把OnDeck的选择行为称之为“竞争切换”。

    OnDeck线程获得锁后即变为owner线程,无法获得锁则会依然留在EntryList中,考虑到公平性,在EntryList中的位置不发生变化(依然在队头)。

    如果Owner线程被wait方法阻塞,则转移到WaitSet队列;如果在某个时刻被notify/notifyAll唤醒, 则再次转移到EntryList

4、自旋锁

1)使用背景:

    那些处于ContetionListEntryListWaitSet中的线程均处于阻塞状态,阻塞操作由操作系统完成(在Linxu下通 过pthread_mutex_lock函数)。

    线程被阻塞后便进入内核(Linux)调度状态,这个会导致系统在用户态与内核态之间来回切换,严重影响 锁的性能

2)缓解上述问题的办法便是自旋,其原理是:

    当发生争用时,若Owner线程能在很短的时间内释放锁,则那些正在争用线程可以稍微等一等(自旋), 在Owner线程释放锁后,争用线程可能会立即得到锁,从而避免了系统阻塞。

    Owner运行的时间可能会超出了临界值,争用线程自旋一段时间后还是无法 获得锁,这时争用线程则会停止自旋进入阻塞状态(后退)。

基本思路就是自旋,不成功再阻塞,尽量降低阻塞的可能性,这对那些执行时间很短的代码块来说有非常重要的性能提高。

    PS:自旋锁别称:自旋-指数后退锁【复合锁】

3)自旋优化策略

    自旋锁周期选择:HotSpot认为最佳时间应是一个线程上下文切换的时间,但目前并没有做到。

    实际做法是利用汇编暂停几个CPU周期,除了自旋周期选择,还进行了其他的自旋优化策略:

    Ø 如果平均负载小于CPUs则一直自旋

    Ø 如果有超过(CPUs/2)个线程正在自旋,则后来线程直接阻塞

    Ø 如果正在自旋的线程发现Owner发生了变化则延迟自旋时间(自旋计数)或进入阻塞

    Ø 如果CPU处于节电模式则停止自旋

自旋时间的最坏情况是CPU的存储延迟,自旋时会适当放弃线程优先级之间的差异。

    synchronized实现何时使用了自旋锁?

    在线程进入ContentionList时,也即第一步操作前。

5、偏向锁

 在JVM1.6中引入了偏向锁,偏向锁主要解决无竞争下的锁性能问题。

1CAS(Compare-And-Swap)SMP(对称多处理器)架构

 

    SMP:所有的CPU会共享一条系统总线(BUS),靠此总线连接主存。每个核都有自己的一级缓存,各核相对于BUS对称分布,因此这种结构称为“对称多处理器”。

    CAS:是一条CPU的原子指令,其作用是让CPU比较后原子地更新某个位置的值

    Core1Core2可能会同时把主存中某个位置的值Load到自己的L1 Cache中,当Core1在自己的L1 Cache中修改这个位置的值时,会通过总线,使Core2L1 Cache对应的值“失效”,而Core2一旦发现自己L1 Cache中的值失效(称为Cache命中缺失)则会通过总线从内存中加载该地址最新的值,大家通过总线的来回通信称为Cache一致性流量

    CAS恰好会导致Cache一致性流量,如果有很多线程都共享同一个对象,当某个Core CAS成功时必然会引起总线风暴,这就是所谓的本地延迟本质上偏向锁就是为了消除CAS,降低Cache一致性流量。

2Cache一致性:

    Cache一致性,其实是有协议支持的,现在通用的协议是MESI(最早由Intel开始支持)

3Cache一致性流量的例外情况:

    其实也不是所有的CAS都会导致总线风暴,这跟Cache一致性协议有关

4NUMA(Non Uniform Memory Access Achitecture)架构:

    与SMP对应还有【非对称多处理器架构】,现在主要应用在一些高端处理器上,主要特点是没有总线,没有公用主存,每个Core有自己的内存

6、小结

    Synchronized的底层实现主要依靠Lock-Free的队列,基本思路是自旋后阻塞,竞争切换后继续竞争锁,稍微牺牲了公平性,但获得了高吞吐量。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值