多线程之锁优化

多线程之锁优化（上）：深入了解Synchronized同步锁的优化方法

在并发编程中，多个线程访问同一个共享资源时，我们必须考虑如何维护数据的原子性。在
JDK1.5 之前，Java 是依靠 Synchronized 关键字实现锁功能来做到这点的。
Synchronized 是 JVM 实现的一种内置锁，锁的获取和释放是由 JVM 隐式实现

到了 JDK1.5 版本，并发包中新增了 Lock 接口来实现锁功能，它提供了与 Synchronized
关键字类似的同步功能，只是在使用时需要显示获取和释放锁.

Lock 同步锁是基于 Java 实现的，而 Synchronized 是基于底层操作系统的 Mutex Lock
实现的，每次获取和释放锁操作都会带来用户态和内核态的切换，从而增加系统性能开销

因此，在锁竞争激烈的情况下，Synchronized 同步锁在性能上就表现得非常糟糕，它也常
被大家称为重量级锁.

特别是在单个线程重复申请锁的情况下，JDK1.5 版本的 Synchronized 锁性能要比 Lock
的性能差很多。例如，在 Dubbo 基于 Netty 实现的通信中，消费端向服务端通信之后，
由于接收返回消息是异步，所以需要一个线程轮询监听返回信息。而在接收消息时，就需要
用到锁来确保 request session 的原子性。如果我们这里使用 Synchronized 同步锁，那么
每当同一个线程请求锁资源时，都会发生一次用户态和内核态的切换

到了 JDK1.6 版本之后，Java 对 Synchronized 同步锁做了充分的优化，甚至在某些场景
下，它的性能已经超越了 Lock 同步锁。这一讲我们就来看看 Synchronized 同步锁究竟是
通过了哪些优化，实现了性能地提升。

Synchronized 同步锁实现原理
了解 Synchronized 同步锁优化之前，我们先来看看它的底层实现原理，这样可以帮助我
们更好地理解后面的内容

通常 Synchronized 实现同步锁的方式有两种，一种是修饰方法，一种是修饰方法块。以
下就是通过 Synchronized 实现的两种同步方法加锁的方式：

// 关键字在实例方法上，锁为当前实例
public synchronized void method1() {
	// code
}
// 关键字在代码块上，锁为括号里面的对象
public void method2() {
	Object o = new Object();
	synchronized (o) {
	// code
	}
}

通过输出的字节码，你会发现：Synchronized 在修饰同步代码块时，是由 monitorenter
和 monitorexit 指令来实现同步的。进入 monitorenter 指令后，线程将持有 Monitor 对
象，退出 monitorenter 指令后，线程将释放该 Monitor 对象

再来看以下同步方法的字节码，你会发现：当 Synchronized 修饰同步方法时，并没有发 现 monitorenter 和 monitorexit 指令，而是出现了一个 ACC_SYNCHRONIZED 标志

这是因为 JVM 使用了 ACC_SYNCHRONIZED 访问标志来区分一个方法是否是同步方法。
当方法调用时，调用指令将会检查该方法是否被设置 ACC_SYNCHRONIZED 访问标志。
如果设置了该标志，执行线程将先持有 Monitor 对象，然后再执行方法。在该方法运行期
间，其它线程将无法获取到该 Mointor 对象，当方法执行完成后，再释放该 Monitor 对
象。

通过以上的源码，我们再来看看 Synchronized 修饰方法是怎么实现锁原理的

VM 中的同步是基于进入和退出管程（Monitor）对象实现的。每个对象实例都会有一个
Monitor，Monitor 可以和对象一起创建、销毁。Monitor 是由 ObjectMonitor 实现，而
ObjectMonitor 是由 C++ 的 ObjectMonitor.hpp 文件实现，如下所示：

ObjectMonitor() {
	_header = NULL;
	_count = 0; // 记录个数
	_waiters = 0,
	_recursions = 0;
	_object = NULL;
	_owner = NULL;
	_WaitSet = NULL; // 处于 wait 状态的线程，会被加入到 _WaitSet
	_WaitSetLock = 0 ;
	_Responsible = NULL ;
	_succ = NULL ;
	_cxq = NULL ;
	FreeNext = NULL ;
	_EntryList = NULL ; // 处于等待锁 block 状态的线程，会被加入到该列表
	_SpinFreq = 0 ;
	_SpinClock = 0 ;
	OwnerIsThread = 0 ;
}

当多个线程同时访问一段同步代码时，多个线程会先被存放在 EntryList 集合中，处于
block 状态的线程，都会被加入到该列表。接下来当线程获取到对象的 Monitor 时，
Monitor 是依靠底层操作系统的 Mutex Lock 来实现互斥的，线程申请 Mutex 成功，则持
有该 Mutex，其它线程将无法获取到该 Mutex

如果线程调用 wait() 方法，就会释放当前持有的 Mutex，并且该线程会进入 WaitSet 集合
中，等待下一次被唤醒。如果当前线程顺利执行完方法，也将释放 Mutex。

看完上面的讲解，相信你对同步锁的实现原理已经有个深入的了解了。总结来说就是，同步
锁在这种实现方式中，因 Monitor 是依赖于底层的操作系统实现，存在用户态与内核态之
间的切换，所以增加了性能开销。

锁升级优化

为了提升性能，JDK1.6 引入了偏向锁、轻量级锁、重量级锁概念，来减少锁竞争带来的上
下文切换，而正是新增的 Java 对象头实现了锁升级功能。
当 Java 对象被 Synchronized 关键字修饰成为同步锁后，围绕这个锁的一系列升级操作都
将和 Java 对象头有关.

Java 对象头

在 JDK1.6 JVM 中，对象实例在堆内存中被分为了三个部分：对象头、实例数据和对齐填
充。其中 Java 对象头由 Mark Word、指向类的指针以及数组长度三部分组成。
Mark Word 记录了对象和锁有关的信息。Mark Word 在 64 位 JVM 中的长度是 64bit，
我们可以一起看下 64 位 JVM 的存储结构是怎么样的。如下图所示：

锁升级功能主要依赖于 Mark Word 中的锁标志位和释放偏向锁标志位，Synchronized 同
步锁就是从偏向锁开始的，随着竞争越来越激烈，偏向锁升级到轻量级锁，最终升级到重量
级锁。下面我们就沿着这条优化路径去看下具体的内容。

1. 偏向锁

偏向锁主要用来优化同一线程多次申请同一个锁的竞争。在某些情况下，大部分时间是同一
个线程竞争锁资源，例如，在创建一个线程并在线程中执行循环监听的场景下，或单线程操
作一个线程安全集合时，同一线程每次都需要获取和释放锁，每次操作都会发生用户态与内
核态的切换.

偏向锁的作用就是，当一个线程再次访问这个同步代码或方法时，该线程只需去对象头的
Mark Word 中去判断一下是否有偏向锁指向它的 ID，无需再进入 Monitor 去竞争对象
了。当对象被当做同步锁并有一个线程抢到了锁时，锁标志位还是 01，“是否偏向锁”标
志位设置为 1，并且记录抢到锁的线程 ID，表示进入偏向锁状态。

一旦出现其它线程竞争锁资源时，偏向锁就会被撤销。偏向锁的撤销需要等待全局安全点，
暂停持有该锁的线程，同时检查该线程是否还在执行该方法，如果是，则升级锁，反之则被
其它线程抢占

下图中红线流程部分为偏向锁获取和撤销流程：

因此，在高并发场景下，当大量线程同时竞争同一个锁资源时，偏向锁就会被撤销，发生
stop the word 后， 开启偏向锁无疑会带来更大的性能开销，这时我们可以通过添加 JVM
参数关闭偏向锁来调优系统性能，示例代码如下：

-XX:-UseBiasedLocking // 关闭偏向锁（默认打开）
 -XX:+UseHeavyMonitors // 设置重量级锁

多线程之锁优化（中）：深入了解Lock同步锁的优化方法

多线程之锁优化（下）：使用乐观锁优化并行操作