Java---synchronized锁的优化

前言

一、锁升级原理

java对象头

二、优化

锁升级

1.偏向锁

2.轻量级锁

3.自旋锁/重量级锁

锁消除

锁粗化

适应性自旋

总结


前言

关于synchronized / Lock

1.JDK 1.5之前,Java通过synchronized关键字来实现锁的功能

  • synchronized是JVM实现的内置锁,锁的获取和释放都是由JVM隐式实现的

2.JDK 1.5,并发包中新增了Lock接口来实现锁功能

  • 提供了与synchronized类似的同步功能,但需要显式获取和释放锁

3. Lock同步锁是基于Java实现的,而synchronized是基于底层操作系统的Mutex Lock实现的

  • 每次获取和释放锁都会带来用户态和内核态的切换,从而增加系统的性能开销
  • 在锁竞争激烈的情况下,synchronized同步锁的性能很糟糕
  • JDK 1.5,在单线程重复申请锁的情况下,synchronized锁性能要比Lock的性能差很多

4.为了提升性能,在JDK 1.6引入偏向锁、轻量级锁、重量级锁,用来减少锁竞争带来的上下文切换

5.借助JDK 1.6新增的Java对象头,实现了锁升级功能

一、锁升级原理

synchronized 锁升级原理:在锁对象的对象头里面有一个 threadid 字段,在第一次访问的时候 threadid 为空,jvm 让其持有偏向锁,并将 threadid 设置为其线程 id,再次进入的时候会先判断 threadid 是否与其线程 id 一致,如果一致则可以直接使用此对象,如果不一致,则升级偏向锁为轻量级锁,通过自旋循环一定次数来获取锁,执行一定次数之后,如果还没有正常获取到要使用的对象,此时就会把锁从轻量级升级为重量级锁,此过程就构成了 synchronized 锁的升级。

锁的升级的目的:锁升级是为了减低了锁带来的性能消耗。在 Java 6 之后优化 synchronized 的实现方式,使用了偏向锁升级为轻量级锁再升级到重量级锁的方式,从而减低了锁带来的性能消耗。

java对象头

1.在JDK 1.6的JVM中,对象实例在堆内存中被分为三部分:对象头实例数据对齐填充

2.对象头的组成部分:Mark Word指向类的指针数组长度(可选,数组类型时才有)

3.Mark Word记录了对象有关的信息,在64位的JVM中,Mark Word为64 bit

4.锁升级功能主要依赖于Mark Word中锁标志位是否偏向锁标志位

5.synchronized同步锁的升级优化路径:偏向锁->轻量级锁->重量级锁

二、优化

锁升级

1.偏向锁

引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径,因为轻量级锁的获取及释放依赖多次CAS原子指令,而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令(由于一旦出现多线程竞争的情况就必须撤销偏向锁,所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗)。轻量级锁是为了在线程交替执行同步块时提高性能,而偏向锁则是在只有一个线程执行同步块时进一步提高性能。

偏向锁获取过程

1.访问Mark Word中偏向锁的标识是否设置成1,锁标志位是否为01——确认为可偏向状态。

2.如果为可偏向状态,则锁对象头线程ID是否指向当前线程ID,如果是,进入步骤 5 ,否则进入步骤 3 。

3.如果线程ID并未指向当前线程,则通过CAS操作竞争锁。如果竞争成功,则将Mark Word中线程ID设置为当前线程ID,然后执行 5 ;如果竞争失败,执行 4 。

4.如果CAS获取偏向锁失败,则表示有竞争。当到达全局安全点(safepoint)时获得偏向锁的线程被挂起,偏向锁升级为轻量级锁,然后被阻塞在安全点的线程继续往下执行同步代码。

5.执行同步代码。

偏向锁的释放

偏向锁的撤销在上述第四步骤中有提到偏向锁只有遇到其他线程尝试竞争偏向锁时,持有偏向锁的线程才会释放锁,线程不会主动去释放偏向锁。偏向锁的撤销,需要等待全局安全点(在这个时间点上没有字节码正在执行),它会首先暂停拥有偏向锁的线程,判断锁对象是否处于被锁定状态,撤销偏向锁后恢复到未锁定(标志位为“01”)或轻量级锁(标志位为“00”)的状态。 

2.轻量级锁

“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。但是,首先需要强调一点的是,轻量级锁并不是用来代替重量级锁的,它的本意是在没有多线程竞争的前提下,减少传统的重量级锁使用产生的性能消耗。在解释轻量级锁的执行过程之前,先明白一点,轻量级锁所适应的场景是线程交替执行同步块的情况,如果存在同一时间访问同一锁的情况,就会导致轻量级锁膨胀为重量级锁。 

轻量级锁加锁过程

1.在代码进入同步块的时候,如果同步对象锁状态为无锁状态(锁标志位为“01”状态,是否为偏向锁为“0”),虚拟机首先将在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间,用于存储锁对象目前的Mark Word的拷贝,官方称之为 Displaced Mark Word。这时候线程堆栈与对象头的状态如图2.1所示。

2.拷贝对象头中的Mark Word复制到锁记录中。

3.拷贝成功后,虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针,并将Lock record里的owner指针指向object mark word。

4.如果这个更新动作成功了,那么这个线程就拥有了该对象的锁,并且对象Mark Word的锁标志位设置为“00”,即表示此对象处于轻量级锁定状态,这时候线程堆栈与对象头的状态如图2.2所示。

5.如果这个更新操作失败了,虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧,如果是就说明当前线程已经拥有了这个对象的锁,那就可以直接进入同步块继续执行。否则说明多个线程竞争锁,轻量级锁就要膨胀为重量级锁,锁标志的状态值变为“10”,Mark Word中存储的就是指向重量级锁(互斥量)的指针,后面等待锁的线程也要进入阻塞状态。 而当前线程便尝试使用自旋来获取锁,自旋就是为了不让线程阻塞,而采用循环去获取锁的过程。

 

轻量级锁的解锁过程 

1.通过CAS操作尝试把线程中复制的Displaced Mark Word对象替换当前的Mark Word。

2.如果替换成功,整个同步过程就完成了。

3.如果替换失败,说明有其他线程尝试过获取该锁(此时锁已膨胀),那就要在释放锁的同时,唤醒被挂起的线程。

3.自旋锁/重量级锁

1.轻量级锁CAS抢占失败,线程将会被挂起进入阻塞状态如果正在持有锁的线程在很短的时间内释放锁资源,那么进入阻塞状态的线程被唤醒后又要重新抢占锁资源。

2.JVM提供了自旋锁,可以通过自旋的方式不断尝试获取锁,从而避免线程被挂起阻塞JDK 1.7开始,自旋锁默认启用,自旋次数不建议设置过大(意味着长时间占用CPU)。

3.自旋锁重试之后如果依然抢锁失败,同步锁会升级至重量级锁,锁标志位为10在这个状态下,未抢到锁的线程都会进入Monitor,之后会被阻塞在WaitSet中。

4.在锁竞争不激烈锁占用时间非常短的场景下,自旋锁可以提高系统性能一旦锁竞争激烈或者锁占用的时间过长,自旋锁将会导致大量的线程一直处于CAS重试状态占用CPU资源。

锁消除

消除锁是虚拟机另外一种锁的优化,这种优化更彻底,在JIT编译时,对运行上下文进行扫描,去除不可能存在竞争的锁。

锁粗化

锁粗化是虚拟机对另一种极端情况的优化处理,通过扩大锁的范围,避免反复加锁和释放锁。

自适应自旋锁

适应性自旋

从轻量级锁获取的流程中我们知道当线程在获取轻量级锁的过程中执行CAS操作失败时,是要通过自旋来获取重量级锁的。问题在于,自旋是需要消耗CPU的,如果一直获取不到锁的话,那该线程就一直处在自旋状态,白白浪费CPU资源。解决这个问题最简单的办法就是指定自旋的次数,例如让其循环10次,如果还没获取到锁就进入阻塞状态。但是JDK采用了更聪明的方式——适应性自旋,简单来说就是线程如果自旋成功了,则下次自旋的次数会更多,如果自旋失败了,则自旋的次数就会减少。


总结

加油哦~~

  • 3
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值