Java虚拟机对内部锁的四种优化方式
自Java 6/Java 7开始,Java虚拟机对内部锁的实现进行了一些优化。这些优化主要包括锁消除(Lock Elision)、锁粗化(Lock Coarsening)、偏向锁(Biased Locking)以及适应性锁(Adaptive Locking)。这些优化仅在Java虚拟机server模式下起作用(即运行Java程序时我们可能需要在命令行中指定Java虚拟机参数“-server”以开启这些优化)。
1 锁消除
锁消除(Lock Elision)是JIT编译器对内部锁的具体实现所做的一种优化。
锁消除(Lock Elision)示意图
在动态编译同步块的时候,JIT编译器可以借助一种被称为逃逸分析(Escape Analysis)的技术来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果同步块所使用的锁对象通过这种分析被证实只能够被一个线程访问,那么JIT编译器在编译这个同步块的时候并不生成synchronized所表示的锁的申请与释放对应的机器码,而仅生成原临界区代码对应的机器码,这就造成了被动态编译的字节码就像是不包含monitorenter(申请锁)和monitorexit(释放锁)这两个字节码指令一样,即消除了锁的使用。这种编译器优化就被称为锁消除(Lock Elision),它使得特定情况下我们可以完全消除锁的开销。
Java标准库中的有些类(比如StringBuffer)虽然是线程安全的,但是在实际使用中我们往往不在多个线程间共享这些类的实例。而这些类在实现线程安全的时候往往借助于内部锁。因此,这些类是锁消除优化的常见目标。
清单12-1 可进行锁消除优化的示例代码 public class LockElisionExample { public static String toJSON(ProductInfo productInfo) { StringBuffer sbf = new StringBuffer(); sbf.append("{\"productID\":\"").append(productInfo.productID); sbf.append("\",\"categoryID\":\"").append(productInfo.categoryID); sbf.append("\",\"rank\":").append(productInfo.rank); sbf.append(",\"inventory\":").append(productInfo.inventory); sbf.append('}'); return sbf.toString(); } }
在上面例子中,JIT编译器在编译toJSON方法的时候会将其调用的StringBuffer.append/toString方法内联(Inline)到该方法之中,这相当于把StringBuffer.append/toString方法的方法体中的指令复制到toJSON方法体之中。这里的StringBuffer实例sbf是一个局部变量,并且该变量所引用的对象并没有被发布到其他线程,因此sbf引用的对象只能够被sbf所在的方法(toJSON方法)的当前执行线程(一个线程)访问。所以,JIT编译器此时可以消除toJSON方法中从StringBuffer.append/toString方法的方法体复制的指令所使用的内部锁。在这个例子中,StringBuffer.append/toString方法本身所使用的锁并不会被消除,因为系统中可能还有其他地方在使用StringBuffer,而这些代码可能会共享StringBuffer实例。
锁消除优化所依赖的逃逸分析技术自Java SE 6u23起默认是开启的,但是锁消除优化是在Java 7开始引入的。
从上述例子可以看出,锁消除优化还可能需要以JIT编译器的内联优化为前提。而一个方法是否会被JIT编译器内联取决于该方法的热度以及该方法对应的字节码的尺寸(Bytecode Size)。因此,锁消除优化能否被实施还取决于被调用的同步方法(或者带同步块的方法)是否能够被内联。
锁消除优化告诉我们在该使用锁的情况下必须使用锁,而不必过多在意锁的开销。开发人员应该在代码的逻辑层面考虑是否需要加锁,而至于代码运行层面上某个锁是否真的有必要使用则由JIT编译器来决定。锁消除优化并不表示开发人员在编写代码的时候可以随意使用内部锁(在不需要加锁的情况下加锁),因为锁消除是JIT编译器而不是javac所做的一种优化,而一段代码只有在其被执行的频率足够大的情况下才有可能会被JIT编译器优化。也就是说在JIT编译器优化介入之前,只要源代码中使用了内部锁,那么这个锁的开销就会存在。另外,JIT编译器所执行的内联优化、逃逸分析以及锁消除优化本身都是有其开销的。
在锁消除的作用下,利用ThreadLocal将一个线程安全的对象(比如Random)作为一个线程特有对象来使用,不仅仅可以避免锁的争用,还可以彻底消除这些对象内部所使用的锁的开销。
2 锁粗化
锁粗化(Lock Coarsening/Lock Merging)是JIT编译器对内部锁的具体实现所做的一种优化。
锁粗化(Lock Coarsening)示意图
对于相邻的几个同步块,如果这些同步块使用的是同一个锁实例,那么JIT编译器会将这些同步块合并为一个大同步块,从而避免了一个线程反复申请、释放同一个锁所导致的开销。然而,锁粗化可能导致一个线程持续持有一个锁的时间变长,从而使得同步在该锁之上的其他线程在申请锁时的等待时间变长。例如上图中,第1个同步块结束和第2个同步块开始之间的时间间隙中,其他线程本来是有机会获得monitorX的,但是经过锁粗化之后由于临界区的长度变长,这些线程在申请monitorX时所需的等待时间也相应变长了。因此,锁粗化不会被应用到循环体内的相邻同步块。
相邻的两个同步块之间如果存在其他语句,也不一定就会阻碍JIT编译器执行锁粗化优化,这是因为JIT编译器可能在执行锁粗化优化前将这些语句挪到(即指令重排序)后一个同步块的临界区之中(当然,JIT编译器并不会将临界区内的代码挪到临界区之外)。
实际上,我们写的代码中可能很少会出现上图中那种连续的同步块。这种同一个锁实例引导的相邻同步块往往是JIT编译器编译之后形成的。
例如,在下面的例子中
清单12-2 可进行锁粗化优化的示例代码 public class LockCoarseningExample { private final Random rnd = new Random(); public void simulate() { int iq1 = randomIQ(); int iq2 = randomIQ(); int iq3 = randomIQ(); act(iq1, iq2, iq3); } private void act(int... n) { // ... } // 返回随机的智商值 public int randomIQ() { // 人类智商的标准差是15,平均值是100 return (int) Math.round(rnd.nextGaussian() * 15 + 100); } // ... }
simulate方法连续调用randomIQ方法来生成3个符合正态分布(高斯分布)的随机智商(IQ)。在simulate方法被执行得足够频繁的情况下,JIT编译器可能对该方法执行一系优化:首先,JIT编译器可能将randomIQ方法内联(inline)到simulate方法中,这相当于把randomIQ方法体中的指令复制到simulate方法之中。在此基础上,randomIQ方法中的rnd.nextGaussian()调用也可能被内联,这相当于把Random.nextGaussian()方法体中的指令复制到simulate方法之中。Random.nextGaussian()是一个同步方法,由于Random实例rnd可能被多个线程共享(因为simulate方法可能被多个线程执行),因此JIT编译器无法对Random.nextGaussian()方法本身执行锁消除优化,这使得被内联到simulate方法中的Random.nextGaussian()方法体相当于一个由rnd引导的同步块。经过上述优化之后,JIT编译器便会发现simulate方法中存在3个相邻的由rnd(Random实例)引导的同步块,于是锁粗化优化便“粉墨登场”了。
锁粗化默认是开启的。如果要关闭这个特性,我们可以在Java程序的启动命令行中添加虚拟机参数“-XX:-EliminateLocks”(开启则可以使用虚拟机参数“-XX:+EliminateLocks”)。
3 偏向锁
偏向锁(Biased Locking)是Java虚拟机对锁的实现所做的一种优化。这种优化基于这样的观测结果(Observation):大多数锁并没有被争用(Contented),并且这些锁在其整个生命周期内至多只会被一个线程持有。然而,Java虚拟机在实现monitorenter字节码(申请锁)和monitorexit字节码(释放锁)时需要借助一个原子操作(CAS操作),这个操作代价相对来说比较昂贵。因此,Java虚拟机会为每个对象维护一个偏好(Bias),即一个对象对应的内部锁第1次被一个线程获得,那么这个线程就会被记录为该对象的偏好线程(Biased Thread)。这个线程后续无论是再次申请该锁还是释放该锁,都无须借助原先(指未实施偏向锁优化前)昂贵的原子操作,从而减少了锁的申请与释放的开销。
然而,一个锁没有被争用并不代表仅仅只有一个线程访问该锁,当一个对象的偏好线程以外的其他线程申请该对象的内部锁时,Java虚拟机需要收回(Revoke)该对象对原偏好线程的“偏好”并重新设置该对象的偏好线程。这个偏好收回和重新分配过程的代价也是比较昂贵的,因此如果程序运行过程中存在比较多的锁争用的情况,那么这种偏好收回和重新分配的代价便会被放大。有鉴于此,偏向锁优化只适合于存在相当大一部分锁并没有被争用的系统之中。如果系统中存在大量被争用的锁而没有被争用的锁仅占极小的部分,那么我们可以考虑关闭偏向锁优化。
偏向锁优化默认是开启的。要关闭偏向锁优化,我们可以在Java程序的启动命令行中添加虚拟机参数“-XX:-UseBiasedLocking”(开启偏向锁优化可以使用虚拟机参数“-XX:+UseBiasedLocking”)。
4 适应性锁
适应性锁(Adaptive Locking,也被称为 Adaptive Spinning )是JIT编译器对内部锁实现所做的一种优化。
存在锁争用的情况下,一个线程申请一个锁的时候如果这个锁恰好被其他线程持有,那么这个线程就需要等待该锁被其持有线程释放。实现这种等待的一种保守方法——将这个线程暂停(线程的生命周期状态变为非Runnable状态)。由于暂停线程会导致上下文切换,因此对于一个具体锁实例来说,这种实现策略比较适合于系统中绝大多数线程对该锁的持有时间较长的场景,这样才能够抵消上下文切换的开销。另外一种实现方法就是采用忙等(Busy Wait)。所谓忙等相当于如下代码所示的一个循环体为空的循环语句:
// 当锁被其他线程持有时一直循环 while (lockIsHeldByOtherThread){}
可见,忙等是通过反复执行空操作(什么也不做)直到所需的条件成立为止而实现等待的。这种策略的好处是不会导致上下文切换,缺点是比较耗费处理器资源——如果所需的条件在相当长时间内未能成立,那么忙等的循环就会一直被执行。因此,对于一个具体的锁实例来说,忙等策略比较适合于绝大多数线程对该锁的持有时间较短的场景,这样能够避免过多的处理器时间开销。
事实上,Java虚拟机也不是非要在上述两种实现策略之中择其一 ——它可以综合使用上述两种策略。对于一个具体的锁实例,Java虚拟机会根据其运行过程中收集到的信息来判断这个锁是属于被线程持有时间“较长”的还是“较短”的。对于被线程持有时间“较长”的锁,Java虚拟机会选用暂停等待策略;而对于被线程持有时间“较短”的锁,Java虚拟机会选用忙等等待策略。Java虚拟机也可能先采用忙等等待策略,在忙等失败的情况下再采用暂停等待策略。Java虚拟机的这种优化就被称为适应性锁(Adaptive Locking),这种优化同样也需要JIT编译器介入。
适应性锁优化可以是以具体的一个锁实例为基础的。也就是说,Java虚拟机可能对一个锁实例采用忙等等待策略,而对另外一个锁实例采用暂停等待策略。
从适应性锁优化可以看出,内部锁的使用并不一定会导致上下文切换,这就是我们说锁与上下文切换时均说锁“可能”导致上下文切换的原因。
本文出处http://geek.csdn.net/news/detail/238518
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
双11知识狂欢,一天不学习,浑身都难受
双11的活动已经开始啦 去年剁掉的手 今天竟然神奇般的长出来啦,哈哈哈 苦哈哈赚了一年的钱 不就是为了这几天的放纵嘛 绝对不能错过这囤货的最佳时期哟~ 各种漂亮衣服、生活用品、家具用品,相信大家已经囤了满满一堆 但是物品总有不喜欢的一天,而生活“物资”也会在一天天减少 难免会觉得空虚与落寞 那么,总会有一些东西不会随着时间的流逝而贬值 反而会充实你的大脑,让你的薪资蹭蹭涨起来! 它,就是龙果学院——IT精品课程! 那么,怎样才能买到最适合你的课程呢? 如何才能花最少的钱,增最多的值呢? 请收好这份攻略 活动多样化 攻略一:精品课程乐享直降盛惠 购买热门精品课程,即可以享受立减哦!大数据课程立减高达1020元,微服务架构课程立减高达900元! 深入大数据架构师之路,问鼎40万年薪 原价:1699元 11.9-12日下单立减1020元 双11狂欢价:679 基于Flink流处理的动态实时电商实时分析系统 原价:699元 11.9-12日下单立减400元 双11狂欢价:299元 大数据DMP画像系统 原价:699元 11.9-12日下单立减200元 双11狂欢价:499元 从无到有构建大型电...
- 下一篇
利用cobbler定义一个装机平台
最近对于CMDB平台做了一次功能增加,把具体实现再往下细分就是:运维人员对设备申请,申请好之后跟网络部需要需要提前分配一个IP地址网段等 等,然后通过从厂商获取的MAC地址号,咱们可以根据cobbler 的API实现一个装机方式,给主机分配好IP地址,装机完成之后再同步到咱们的CMDB平台: 前提条件是cobbler得安装完成,并且咱们提前写好ks文件,生成profile等等。接下来就是咱们运维平台,根据获取的MAC地址给服务器定义一个IP信息录入,然后定制安装操作系统即可: 第一步:添加主机分配IP,最主要是MAC地址: 第二步:默认刚开始添加的适合都是等待装机状态,当点击开始装机时候,后台根据MAC地址定义操作系统的profile和生成IP地址,这个时候装机状态就变成装机中,然后开启服务器电源执行装机即可: 第三步:启动虚拟机开始装机: 到此安装完成;装机状态可变成装机完成,这里实现的思路咱们可以这样,写一个脚本久不久去ping 这个刚刚分配的IP地址,等真正可以Ping通之后,可以向这个IP发送某条命令然后根据返回值就能判断是否已经完成装机操作。 不足,这里我没有运用ipmi...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS8编译安装MySQL8.0.19