转载

JDK1.6 对 synchronized 的锁优化

1. 背景

在 JDK 1.6 中对锁的实现引入了大量的优化。

目的

减少锁操作的开销。

2. 锁优化

在看下面的内容之间，希望大家对 Mark Word 有个大体的理解。Java 中一个对象在堆中的内存结构是这样的：

JDK1.6 对 synchronized 的锁优化

Mark Word 是这样的：

JDK1.6 对 synchronized 的锁优化

2.1 适应性自旋锁

自旋锁的思想： 让一个线程在请求一个共享数据的锁时执行忙循环（自旋）一段时间，如果在这段时间内能获得锁，就可以 避免进入阻塞状态 。

自旋锁的缺点： 需要进行忙循环操作 占用 CPU 时间 ，它只适用于 共享数据的锁定状态很短的场景 。

若锁被其他线程长时间占用，会带来许多性能上的开销。所以自旋的次数不再固定。由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

如果共享数据的锁定状态持续时间较短，切换线程不值得（会有上下文切换），可以利用自旋锁尝试一定的次数。

2.2 锁消除

JIT 编译时，会去除不可能存在竞争的锁。通过 JIT 的逃逸分析 来消除一些没有在当前同步块以外被其他线程共享的数据的锁的保护，通过逃逸分析在 TLAB 来分配对象，这样就不存在共享数据带来的线程安全问题。

2.3 锁粗化

减少不必要的紧连在一起的 lock，unlock 操作， 将多个连续的锁扩展成一个范围更大的锁 。

2.4 偏向锁（重入锁）

为了在无线程竞争的情况下避免在锁获取过程中执行不必要的 CAS 原子指令，因为 CAS 原子指令虽然相对于重量级锁来说开销比较小但还是存在非常可观的本地延迟（因为 C AS 的底层是利用 LOCK 指令 + cmpxchg 汇编指令来保证原子性的，LOCK 指令会锁总线，其他 CPU 的内存操作将会被阻塞，因为 CPU 架构如果是 CMU 的话，控制信号、数据信号等是通过共享总线传到内存控制器中）。减少同一线程获取锁的代价，省去了大量有关 锁申请 的操作。

核心思想

如果一个线程获得了锁，那么锁就进入偏向模式，此时 Mark Word 的结构也变为偏向锁结构，当该线程再次请求锁时，无需再做任何同步操作，即获取锁的过程只需要检查 Mark Word 的锁标记位为偏向锁以及当前线程 Id 等于 Mark Word 的 ThreadId 即可，这样就 省去了大量有关锁申请的操作 。

2.5 轻量级锁

这种锁实现的背后基于这样一种假设，即在真实的情况下我们程序中的大部分同步代码一般都处于无锁竞争状态（即单线程执行环境），在无锁竞争的情况下完全可以 避免调用操作系统层面的重量级互斥锁 (重量级锁的底层就是这样实现的)，只需要依靠一条 CAS 原子指令就可以完成锁的获取及释放。当存在锁竞争的情况下，执行 CAS 指令失败的线程将调用操作系统互斥锁进入到阻塞状态，当锁被释放的时候被唤醒。

2.5.1 加锁的过程

主要分为 3 步：

1、在线程进入同步块的时候，如果同步对象状态为 无锁状态 （锁标志为 01），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录的空间，用来存储锁对象目前的 Mark Word 的拷贝。拷贝成功后，虚拟机将使用 CAS 操作尝试将对象的 Mark Word 更新为指向 Lock Record 的指针，并将 Lock Record 里的 owner 指针指向锁对象的 Mark Word。如果更新成功，则执行 2，否则执行 3。

JDK1.6 对 synchronized 的锁优化

2、如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且锁 对象的 Mark Word 中的锁标志位设置为 "00" ，即表示此对象处于轻量级锁定状态，这时候虚拟机线程栈与堆中锁对象的对象头的状态如图所示。

JDK1.6 对 synchronized 的锁优化

3、如果这个更新操作失败了，虚拟机首先会检查锁对象的 Mark Word 是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重要量级锁，锁标志的状态值变为 "10"，Mark Word 中存储的就是指向重量级锁的指针，后面等待锁的线程也要进入阻塞状态。而当前线程便尝试使用自旋来获取锁。 自旋失败后膨胀为重量级锁 ，被阻塞。