java中锁的四种状态

前言

在多线程并发编程中Synchronized一直是元老级角色，很多人都会称它为重量级锁，但是随着 Java SE1.6 对 Synchronized 进行了各种优化之后，有些情况下它并不那么重了，本文详细介绍了 Java SE1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。

---

叙述

首先我们以一张思维导图大概的了解一下锁状态，接下来将进行具体的阐述。

---

Synchronized

synchronized,所谓的重量级锁。Java中每一个对象都可以作为一个锁，表现为：

• 对于普通方法的同步，锁是当前实例对象。
• 对于静态方法的同步，锁是当前类的Class对象。
• 对于同步方法块，锁是Synchronized括号里配置的对象。

JVM基于进入和退出Monitor对象来实现方法同步和代码同步。代码块同步是使用monitorenter和monitorexit指令实现的，monitorenter指令是在编译后插入到同步代码块开始的位置，monitorexit是插在方法结束处和异常处。

方法级的同步是隐式的。同步方法的常量池中会有一个ACC_SYNCHRONIZED标志。当某个线程要访问某个方法的时候，会检查是否有ACC_SYNCHRONIZED，如果有设置，则需要先获得监视器锁，然后开始执行方法，方法执行之后再释放监视器锁。这时如果其他线程来请求执行方法，会因为无法获得监视器锁而被阻断住。值得注意的是，如果在方法执行过程中，发生了异常，并且方法内部并没有处理该异常，那么在异常被抛到方法外面之前监视器锁会被自动释放。

volatile

volatile是轻量级的synchronized,它在多处理器开发中保证了共享变量的可见性。对一个volatile变量的读，总是能看到任意线程对这个volatile变量最后的写入，对单个volatile变量的读写具有原子性。就是说，线程对volatile变量本地内存的写入会被更新到主内存，其他线程对同个volatile的读取，会先将本地的设为无效，必须从主内存中读取。

---

锁的状态

锁是存在哪里的呢？

锁存在Java的对象头中的Mark Work。Mark Work默认不仅存放着锁标志位，还存放对象hashCode等信息。运行时，会根据锁的状态，修改Mark Work的存储内容。如果对象是数组类型，则虚拟机用3个字宽存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，一字宽等于四字节，即32bit。

• 字宽（Word）: 内存大小的单位概念， 对于 32 位处理器 1 Word = 4 Bytes， 64 位处理器 1 Word = 8 Bytes
• 每一个 Java 对象都至少占用 2 个字宽的内存(数组类型占用3个字宽)。
  • 第一个字宽也被称为对象头Mark Word。 对象头包含了多种不同的信息， 其中就包含对象锁相关的信息。
  • 第二个字宽是指向定义该对象类信息（class metadata）的指针
    

---

四种状态

锁有四种状态：无锁状态、偏向锁、轻量级锁、重量级锁

随着锁的竞争，锁的状态会从偏向锁到轻量级锁，再到重量级锁。而且锁的状态只有升级，没有降级。也就是只有偏向锁->轻量级锁->重量级锁，没有重量级锁->轻量级锁->偏向锁。

锁状态的改变是根据竞争激烈程度进行的，在几乎无竞争的条件下，会使用偏向锁，在轻度竞争的条件下，会由偏向锁升级为轻量级锁， 在重度竞争的情况下，会升级到重量级锁。

下图展现了一个对象在创建（allocate）后，根据偏斜锁机制是否打开，对象 MarkWord 状态以不同方式转换的过程。

锁名称	描述	应用场景
偏向锁	线程在大多数情况下并不存在竞争条件，使用同步会消耗性能，而偏向锁是对锁的优化，可以消除同步，提升性能。当一个线程获得锁，会将对象头的锁标志位设为01,进入偏向模式.偏向锁可以在让一个线程一直持有锁，在其他线程需要竞争锁的时候，再释放锁。	只有一个线程进入临界区
轻量级锁	当线程A获得偏向锁后，线程B进入竞争状态，需要获得线程A持有的锁，那么线程A撤销偏向锁，进入无锁状态。线程A和线程B交替进入临界区，偏向锁无法满足，膨胀到轻量级锁，锁标志位设为00。	多个线程交替进入临界区
重量级锁	当多线程交替进入临界区，轻量级锁hold得住。但如果多个线程同时进入临界区，hold不住了，膨胀到重量级锁	多个线程同时进入临界区

---

锁状态转换过程

无锁 -> 偏向锁

从上图可以看到 ， 偏向锁的获取方式是将对象头的 MarkWord 部分中， 标记上线程ID， 以表示哪一个线程获得了偏向锁。 具体的赋值逻辑如下：

• 首先读取目标对象的 MarkWord, 判断是否处于可偏向的状态
  
  下面是 Open Jdk/ JDK 8 源码 中检测一个对象是否处于可偏向状态的源码

  // Indicates that the mark has the bias bit set but that it has not
  // yet been biased toward a particular thread
  bool is_biased_anonymously() const {
    return (has_bias_pattern() && (biased_locker() == NULL));
  }

• has_bias_pattern() 返回 true 时代表 markword 的可偏向标志 bit 位为 1 ，且对象头末尾标志为 01。

• biased_locker() == NULL 返回 true 时代表对象 Mark Word 中 bit field 域存储的 Thread Id 为空。

• 如果为可偏向状态, 则尝试用 CAS 操作， 将自己的线程 ID 写入MarkWord

  • 如果 CAS 操作成功（状态转变为下图）， 则认为已经获取到该对象的偏向锁， 执行同步块代码 。 注意， age 后面的标志位中的值并没有变化， 这点之后会用到
  • 补充： 一个线程在执行完同步代码块以后， 并不会尝试将 MarkWord 中的 thread ID 赋回原值 。这样做的好处是： 如果该线程需要再次对这个对象加锁，而这个对象之前一直没有被其他线程尝试获取过锁，依旧停留在可偏向的状态下， 即可在不修改对象头的情况下， 直接认为偏向成功。
    
  • 补充如果 CAS 操作失败， 则说明， 有另外一个线程 Thread B 抢先获取了偏向锁。 这种状态说明该对象的竞争比较激烈， 此时需要撤销 Thread B 获得的偏向锁，将 Thread B 持有的锁升级为轻量级锁。 该操作需要等待全局安全点 JVM safepoint ( 此时间点， 没有线程在执行字节码)

• 如果是已偏向状态， 则检测 MarkWord 中存储的 thread ID 是否等于当前 thread ID

  • 如果相等， 则证明本线程已经获取到偏向锁，可以直接继续执行同步代码块
  • 如果不等， 则证明该对象目前偏向于其他线程， 需要撤销偏向锁

从上面的偏向锁机制描述中，可以注意到

• 偏向锁的 撤销（revoke） 是一个很特殊的操作， 为了执行撤销操作， 需要等待全局安全点（Safe Point）， 此时间点所有的工作线程都停止了字节码的执行

偏向锁的撤销（Revoke）
如上文提到的， 偏向锁的撤销（Revoke） 操作并不是将对象恢复到无锁可偏向的状态， 而是在偏向锁的获取过程中， 发现了竞争时， 直接将一个被偏向的对象“升级到” 被加了轻量级锁的状态。 这个操作的具体完成方式如下：

• 在偏向锁 CAS 更新操作失败以后， 等待到达全局安全点。
  • 通过 MarkWord 中已经存在的 Thread Id 找到成功获取了偏向锁的那个线程, 然后在该线程的栈帧中补充上轻量级加锁时， 会保存的锁记录（Lock Record）， 然后将被获取了偏向锁对象的 MarkWord 更新为指向这条锁记录的指针。
  • 至此， 锁撤销操作完成， 阻塞在安全点的线程可以继续执行。

偏向锁的批量再偏向（Bulk Rebias）机制

偏向锁这个机制很特殊， 别的锁在执行完同步代码块后， 都会有释放锁的操作， 而偏向锁并没有直观意义上的“释放锁”操作。

那么作为开发人员， 很自然会产生的一个问题就是， 如果一个对象先偏向于某个线程， 执行完同步代码后， 另一个线程就不能直接重新获得偏向锁吗？ 答案是可以， JVM 提供了批量再偏向机制（Bulk Rebias）机制

该机制的主要工作原理如下：

• 引入一个概念 epoch, 其本质是一个时间戳 ， 代表了偏向锁的有效性
• 从前文描述的对象头结构中可以看到， epoch 存储在可偏向对象的 MarkWord 中。
• 除了对象中的 epoch, 对象所属的类 class 信息中， 也会保存一个 epoch 值
• 每当遇到一个全局安全点时， 如果要对 class C 进行批量再偏向， 则首先对 class C 中保存的 epoch 进行增加操作， 得到一个新的 epoch_new
• 然后扫描所有持有 class C 实例的线程栈， 根据线程栈的信息判断出该线程是否锁定了该对象， 仅将 epoch_new 的值赋给被锁定的对象中。
• 退出安全点后， 当有线程需要尝试获取偏向锁时， 直接检查 class C 中存储的 epoch 值是否与目标对象中存储的 epoch 值相等， 如果不相等， 则说明该对象的偏向锁已经无效了， 可以尝试对此对象重新进行偏向操作。

偏向锁 -> 轻量级锁
从之前的描述中可以看到， 存在超过一个线程竞争某一个对象时， 会发生偏向锁的撤销操作。 有趣的是， 偏向锁撤销后， 对象可能处于两种状态。

• 一种是不可偏向的无锁状态， 如下图（之所以不允许偏向， 是因为已经检测到了多于一个线程的竞争， 升级到了轻量级锁的机制）
  

• 另一种是不可偏向的已锁 ( 轻量级锁) 状态
  
  之所以会出现上述两种状态， 是因为偏向锁不存在解锁的操作， 只有撤销操作。 触发撤销操作时：

  • 原来已经获取了偏向锁的线程可能已经执行完了同步代码块， 使得对象处于 “闲置状态”，相当于原有的偏向锁已经过期无效了。此时该对象就应该被直接转换为不可偏向的无锁状态。
  • 原来已经获取了偏向锁的线程也可能尚未执行完同步代码块， 偏向锁依旧有效， 此时对象就应该被转换为被轻量级加锁的状态

轻量级加锁过程：
首先根据标志位判断出对象状态处于不可偏向的无锁状态( 如下图）

• 在当前线程的栈桢（Stack Frame）中创建用于存储锁记录（lock record）的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。如果在此过程中发现，
• 然后线程尝试使用 CAS 操作将对象头中的 Mark Word 替换为指向锁记录的指针。
  • 如果成功，当前线程获得锁
  • 如果失败，表示该对象已经被加锁了， 先进行自旋操作， 再次尝试 CAS 争抢， 如果仍未争抢到， 则进一步升级锁至重量级锁。

下图展示了两个线程竞争锁， 最终导致锁膨胀为重量级锁的过程。
注意： 下图中第一个标绿 MarkWord 的起始状态是错误的， 正确的起始状态应该是 ThreadId(空)|age|1|01， HashCode|age|0|01 是偏向锁未被启用时， 分配对象后的状态

轻量级锁-> 重量级锁
重量级锁依赖于操作系统的互斥量（mutex） 实现，该操作会导致进程从用户态与内核态之间的切换， 是一个开销较大的操作。

---

锁的优缺点

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁撤销的消耗	适用于只有一个线程访问同步块场景
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度	如果始终得不到锁竞争的线程使用自旋会消耗CPU	追求响应时间。同步块执行速度非常快
重量级锁	线程竞争不使用自旋，不会消耗CPU	线程阻塞，响应时间缓慢	追求吞吐量。同步块执行速度较长

参考文章

Java中的偏向锁，轻量级锁， 重量级锁解析

---

小结

锁的状态转换的过程需要认真的细究一下，加油。

感谢您的阅读~~