引言

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

www.jianshu.com/p/04fcd0ea5…

blog.csdn.net/hollis_chua…