深入理解Java虚拟机锁优化&逃逸分析技术

引言

HotSpot虚拟机团队在1.5 -> 1.6版本演进中,进行了大量的锁优化技术,相应的jdk6并发包也推出了很多并发容器&API,所以JDK6是高效并发大放异彩的一个关键版本。本文主要介绍一下java虚拟机中对于锁的优化技术、逃逸分析技术。

锁优化:适应性自旋、锁消除、锁粗化、轻量级锁和偏向锁等

逃逸分析:栈上分配、同步消除、标量替换等

理论基础

在进行锁优化介绍&逃逸分析介绍之前,先回顾一下以下基础概念,是有必要的。

·synchronized同步方法基于ACC_SYNCHRONIZED关键字隐式对方法进行加锁,同步代码块基于monitorenter&monitorexit进行加锁与释放锁。在锁优化技术还未成熟之前,synchronized实现是直接通过ObjectMonitor调用enter&exit进行“重量级锁”操作。

·对象头中主要包含了GC分代年龄、锁状态标记、哈希码、epoch等信息。对象的状态一共有五种,分别是无锁态、轻量级锁、重量级锁、GC标记和偏向锁

·在HotSpot虚拟机中,使用oop-klass模型来表示对象

图转自https://blog.csdn.net/linxdcn/article/details/73287490

·线程五种基本状态,锁与线程&线程状态的切换息息相关。

对于线程来说,一共有五种状态,分别为:初始状态(New) 、就绪状态(Runnable) 、运行状态(Running) 、阻塞状态(Blocked) 和死亡状态(Dead) 。

图转自https://www.cnblogs.com/aspirant/p/8900276.html

·java多线程模型

·使用内核线程 1:1

·使用用户线程 1:n

·使用用户线程加轻量级进程混合实现  m&n


锁优化

自旋锁

基于java多线程模型、线程状态切换与互斥原理,可以得知对性能最大的影响是阻塞的实现,挂起和恢复线程需要映射到OS内核态中完成,同时,虚拟机团队发现在许多应用上,共享数据的锁定状态只会持续很短一段时间,为了这段时间去挂起和恢复线程很没有性价比。如果物理机有一个以上处理器,可以实现并行操作,那么我们就可以让后面请求锁的那个线程'稍等一下',但不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁。这个“稍微等一下”的过程就是自旋。

自旋锁在JDK1.4已经引入进来,但是默认关闭,JDK6默认开启。

在JDK1.4版本,可以通过参数-XX:UseSpinning选择开启自旋,-XX:PreBlockSpin来更改自旋的时间,默认值是10次。

自适应自旋锁

JDK6引入了自适应的自旋锁,于是我们不需要再固定指定一个自旋时间,虚拟机会有算法策略智能的选择时间,随着程序运行和性能监控信息不断完善,虚拟机的预测会越来越精准,越来越'聪明'。

自旋与阻塞的区别在于是否放弃处理器的执行时间,自旋比较适合竞争不激烈,并且保持锁的时间短的场景。


锁消除

锁消除是JIT编译器优化功能之一,也是逃逸分析下面要讲到的。

顾名思义,就是JIT编译同步代码块的时候,会使用逃逸分析技术来判断当前代码块,是否是局部变量等,只会被一个线程访问到。打个比方


在上面代码块中,StringBuffer内部是synchronized修饰的,但是它在代码块中属于局部变量,是线程私有的。还有例子2,也是局部变量,所以这种情况,JIT会帮我们进行优化,进行锁消除,加锁完全没有意义。

由于synchronized是基于moniotor指令实现的,可能有人就想javap试一下是不是真的锁消除了,这里需要提一下,JIT编译阶段的优化,javap无法查看具体结果,如果读者感兴趣,还是可以看的,只是会复杂一点,首先你要自己build一个fasttest版本的jdk,然后在使用java命令对.class文件进行执行的时候加上-XX:+PrintEliminateLocks参数。而且jdk的模式还必须是server模式。


锁粗化

锁的细化老生常谈的问题了,在使用锁的时候,控制粒度有利于提升性能,在真正竞态条件发生的地区才用锁。

那为什么会有锁粗化这一说呢,很简单,同样的道理我们一定有经验且碰到过。

在你写一段try catch异常处理的时候,如果代码块中有循环操作,你会把try catch写在循环里面还是循环外面?


所以这就是锁粗化关注的点了,当JIT发现一系列连续的操作都对同一个对象反复加锁和解锁,甚至加锁操作出现在循环体中的时候,会将加锁同步的范围扩散(粗化)到整个操作序列的外部。


轻量级锁

轻量级锁是JDK 1.6之中加入的新型锁机制,它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的,因此传统的锁机制就称为“重量级”锁。 首先需要强调一点的是,轻量级锁并不是用来代替重量级锁的,它的本意是在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

在代码进入同步块的时候,如果此同步对象没有被锁定(锁标志位为“01”状态),虚拟机首先将在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间,用于存储锁对象目前的Mark Word的拷贝(官方把这份拷贝加了一个Displaced前缀,即Displaced Mark Word),这时候线程堆栈与对象头的状态如下图所示:


然后,虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功了,那么这个线程就拥有了该对象的锁,并且对象Mark Word的锁标志位(Mark Word的最后2bit)将转变为“00”,即表示此对象处于轻量级锁定状态,这时候线程堆栈与对象头的状态如下图所示:


如果这个更新操作失败了,虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧,如果只说明当前线程已经拥有了这个对象的锁,那就可以直接进入同步块继续执行,否则说明这个锁对象已经被其他线程抢占了。 如果有两条以上的线程争用同一个锁,那轻量级锁就不再有效,要膨胀为重量级锁,锁标志的状态值变为“10”,Mark Word中存储的就是指向重量级锁(互斥量)的指针,后面等待锁的线程也要进入阻塞状态。

上面描述的是轻量级锁的加锁过程,它的解锁过程也是通过CAS操作来进行的,如果对象的Mark Word仍然指向着线程的锁记录,那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来,如果替换成功,整个同步过程就完成了。 如果替换失败,说明有其他线程尝试过获取该锁,那就要在释放锁的同时,唤醒被挂起的线程。

轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁,在整个同步周期内都是不存在竞争的”,这是一个经验数据。 如果没有竞争,轻量级锁使用CAS操作避免了使用互斥量的开销,但如果存在锁竞争,除了互斥量的开销外,还额外发生了CAS操作,因此在有竞争的情况下,轻量级锁会比传统的重量级锁更慢。


偏向锁

偏向锁也是JDK 1.6中引入的一项锁优化,它的目的是消除数据在无竞争情况下的同步原语,进一步提高程序的运行性能。 如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量,那偏向锁就是在无竞争的情况下把整个同步都消除掉,连CAS操作都不做了。

偏向锁的“偏”,就是偏心的“偏”、 偏袒的“偏”,它的意思是这个锁会偏向于第一个获得它的线程,如果在接下来的执行过程中,该锁没有被其他的线程获取,则持有偏向锁的线程将永远不需要再进行同步。

如果读懂了前面轻量级锁中关于对象头Mark Word与线程之间的操作过程,那偏向锁的原理理解起来就会很简单。 假设当前虚拟机启用了偏向锁(启用参数-XX:+UseBiasedLocking,这是JDK 1.6的默认值),那么,当锁对象第一次被线程获取的时候,虚拟机将会把对象头中的标志位设为“01”,即偏向模式。 同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中,如果CAS操作成功,持有偏向锁的线程以后每次进入这个锁相关的同步块时,虚拟机都可以不再进行任何同步操作(例如Locking、 Unlocking及对Mark Word的Update等)。

当有另外一个线程去尝试获取这个锁时,偏向模式就宣告结束。 根据锁对象目前是否处于被锁定的状态,撤销偏向(Revoke Bias)后恢复到未锁定(标志位为“01”)或轻量级锁定(标志位为“00”)的状态,后续的同步操作就如上面介绍的轻量级锁那样执行。 偏向锁、 轻量级锁的状态转化及对象Mark Word的关系如下图所示:


偏向锁可以提高带有同步但无竞争的程序性能。 它同样是一个带有效益权衡(Trade Off)性质的优化,也就是说,它并不一定总是对程序运行有利,如果程序中大多数的锁总是被多个不同的线程访问,那偏向模式就是多余的。 在具体问题具体分析的前提下,有时候使用参数-XX:-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。


逃逸分析

栈上分配

顾名思义,当虚拟机确定一个对象不会逃逸出方法之外,那么让对象在栈上分配内存,对象所占用的内存空间就可以随着栈帧的出栈而销毁

我们先来看一段代码的测试结果


我们使用上述jvm参数(开启逃逸分析,关闭TLAB优化,分配1g堆内存,打开gc日志打印),执行以上代码


再来调整一下jvm参数(仅关闭逃逸分析),重新执行一次


可以看到,逃逸分析在判定局部变量testObject不会逃逸出当前方法作用域以后,会进行栈上分配优化,但是由于我jdk使用的是混合模式,所以还是有gc日志打印。

mixed mode代表混合模式

在Hotspot中采用的是解释器和编译器并行的架构,所谓的混合模式就是解释器和编译器搭配使用,当程序启动初期,采用解释器执行(同时会记录相关的数据,比如函数的调用次数,循环语句执行次数),节省编译的时间。在使用解释器执行期间,记录的函数运行的数据,通过这些数据发现某些代码是热点代码,采用编译器对热点代码进行编译,以及优化(逃逸分析就是其中一种优化技术)。


标量替换

标量(Scalar)是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。相对的,那些还可以分解的数据叫做聚合量(Aggregate),Java中的对象就是聚合量,因为他可以分解成其他聚合量和标量。

在JIT阶段,如果经过逃逸分析,发现一个对象不会被外界访问的话,那么经过JIT优化,就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

还是上面的例子,我们再调整一下jvm参数(开启逃逸分析、关闭TLAB、关闭标量替换)


上面的例子说明,栈上分配是通过标量替换实现的。

锁消除

同虚拟机锁优化中的锁消除。


总结

Java虚拟机屏蔽了与具体操作系统平台相关的信息之外,还为程序员做了很多优化,除了本文提到的优化之外,还有公共子表达式消除、数组边界检查消除、方法内联、内存及代码位置变换优化、TLAB、PLAB等优化技术,读者有兴趣可深入研究


参考:

<深入理解java虚拟机>

<Java虚拟机规范第2版>

<Hotspot实战>

https://www.hollischuang.com/archives/tag/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3%E5%A4%9A%E7%BA%BF%E7%A8%8B

https://www.jianshu.com/p/04fcd0ea5af7

https://blog.csdn.net/hollis_chuang/article/details/80922794

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,530评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,403评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,120评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,770评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,758评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,649评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,021评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,675评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,931评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,751评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,410评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,004评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,969评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,042评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,493评论 2 343

推荐阅读更多精彩内容