这里有新鲜出炉的 Java 函数式编程,程序狗速度看过来!
Java 程序设计语言
java 是一种可以撰写跨平台应用软件的面向对象的程序设计语言,是由 Sun Microsystems 公司于 1995 年 5 月推出的 Java 程序设计语言和 Java 平台(即 JavaEE(j2ee), JavaME(j2me), JavaSE(j2se))的总称.
这篇文章主要介绍了浅谈 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 可进行锁消除优化的示例代码
在上面例子中,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 实例.
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();
}
}
锁消除优化所依赖的逃逸分析技术自 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 可进行锁粗化优化的示例代码
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 实例)引导的同步块,于是锁粗化优化便" 粉墨登场 " 了.
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);
}
// ...
}
锁粗化默认是开启的.如果要关闭这个特性,我们可以在 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 虚拟机可能对一个锁实例采用忙等等待策略,而对另外一个锁实例采用暂停等待策略.
从适应性锁优化可以看出,内部锁的使用并不一定会导致上下文切换,这就是我们说锁与上下文切换时均说锁 "可能" 导致上下文切换的原因.
本文选自《Java 多线程编程实战指南(核心篇)》.
来源: http://www.phperz.com/article/18/0118/353059.html