【一文读懂】 Java并发 - 锁升级原理

要明白锁的原理,首先要知道对象头

Java对象头

在Java中,一个对象一般由两部分组成 :1、对象头 ; 2、对象的成员变量信息

在32位的虚拟机中:

(1)普通对象的对象头长度64bit(8字节):
其中的32bit是Mark Word,另外32位是Klass Word,如下:

Mark Word (32 bits) Klass Word (32 bits)

(2)数组对象的对象头长度96bit(12自己):
除了Mark Word和Klass Word,还有32bit的 array length,如下:

Mark Word(32bits) Klass Word(32bits) array length(32bits)

什么是 Mark Word 什么是 Klass Word 什么是array length ?

  • array length - 很明显这是标明数组长度的字段
  • Klass Word - 对象类型指针,通过该字段标明当前对象所属的类
  • Mark Word - 下面着重介绍

在不同状态下,Mark Word 会有不同的表现形式,对应关系如下:

【一文读懂】 Java并发 - 锁升级原理_第1张图片
Normal 就是对象的正常状态,以该状态为例

  • 25位是对象的hashcode
  • 4位是age,在垃圾回收中的分代年龄
  • 1位biased_lock,标明是否是对象锁
  • 2位(01),表明当前的加锁状态

Biased 是偏向锁状态
Lightweight Locked 是轻量级锁状态
Heavyweight Locked 是重量级锁状态
Marked for GC 是在JVM进行GC时的状态

无论是偏向锁、轻量级锁、重量级锁,都是在对象头中的Mark Word做文章

锁升级

在默认情况下,synchronized 会首先使用偏向锁,当发现存在竞争时,就会升级为轻量级锁,当竞争比较激烈时,轻量级锁就会升级为重量级锁
但是我们可以通过添加 VM 参数 -XX:-UseBiasedLocking 手动关闭偏向锁,那么synchronized 会直接进入轻量级锁

为什么会有锁升级?

因为从偏向锁 - 轻量级锁 - 重量级锁,互斥程度会越来越高,但是性能代价也越来越大,所以在一开始,如果资源竞争不是很激烈,应该优先选择程度较轻的锁,以下是《Java并发编程的艺术》一书中的原话

Java SE 1.6为了减少获得锁和释放锁带来的性能消耗,引入了“偏向锁”和“轻量级锁”,在
Java SE 1.6中,锁一共有4种状态,级别从低到高依次是:无锁状态、偏向锁状态、轻量级锁状
态和重量级锁状态,这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级,意味着偏
向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略,目的是为了提高
获得锁和释放锁的效率,下文会详细分析。

重量级锁原理

操作系统会提供 Monitor 对象,对某个对象加上重量级锁之后,该对象头中的 Mark Word 中就被设置成指向 Monitor 对象的指针 即上图所示的 ptr_to_heavyweight_monitor:30

在Monitor对象中会有两个属性: 1、Owner ;2、EntryList
Owner - 指当前这个对象的锁是由哪个对象持有的
EntryList - 是一个线程队列,当其他线程来竞争该对象锁失败时,就会进入EntryList 中阻塞

因为重量级锁的加锁过程需要使用到操作系统提供的 Monitor 对象,换言之,属于内核级别,因此性能代价是较大的,如果一个对象虽然有多线程要加锁,但加锁的时间是错开的(也就是没有竞争),那么可以使用轻量级锁来优化

重量级锁的自选优化

重量级锁竞争的时候,可以使用自旋来进行优化,如果当前线程自旋成功(即这时候持锁线程已经退出了同步块,释放了锁),当前线程就可以避免阻塞

轻量级锁

每个线程的每个栈帧都会包含一个锁记录的结构

锁记录包含两个部分,其中一个部分用存储上锁对象的 Mark Word,另外一部分是对象指针 Object reference,用于指向上锁对象的地址

上锁过程如下,让锁记录中 Object reference 指向上锁对象,并尝试用 cas 替换 Object 的 Mark Word,将 Mark Word 的值存入锁记录

【一文读懂】 Java并发 - 锁升级原理_第2张图片

如果 cas 替换成功,对象头中存储了 锁记录地址和状态 00 ,表示由该线程给对象加锁,结果如下

【一文读懂】 Java并发 - 锁升级原理_第3张图片

如果cas 失败,有两种情况:

  • 其它线程已经持有了该 Object 的轻量级锁,这时表明有竞争,进入锁膨胀过程
  • 自己执行了 synchronized 锁重入,那么再添加一条 Lock Record 作为重入的计数,如下:

【一文读懂】 Java并发 - 锁升级原理_第4张图片

解锁时有如下两种情况

  • 锁记录的值为 null,表示有重入,这时重置锁记录,表示重入计数减一
  • 锁记录的值不为 null,这时使用 cas 将 Mark Word 的值恢复给对象头,如果失败,说明轻量级锁进行了锁膨胀或已经升级为重量级锁,进入重量级锁解锁流程

锁膨胀过程

假设此时Thread-0已经对某个对象上了轻量级锁,现实Thread-1也尝试对改对象加锁,必然加锁失败,进入锁升级

  1. 即为 Object 对象申请 Monitor 锁,让 Object 指向重量级锁地址
  2. 然后自己进入 Monitor 的 EntryList 阻塞

如下图

【一文读懂】 Java并发 - 锁升级原理_第5张图片

当 Thread-0 退出同步块解锁时,使用 cas 将 Mark Word 的值恢复给对象头,失败。这时会进入重量级解锁流程,即按照 Monitor 地址找到 Monitor 对象,设置 Owner 为 null,唤醒 Entry List 中 的Thread-1 线程

轻量级锁缺点

在很多情况下,一个对象在某段时间内,会不停被同一个线程上锁,即不断发生锁重入,这就会频繁的进行Mark Word的cas操作,这也是存在一定性能损耗的,因此诞生了偏向锁来优化

偏向锁

只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头,之后发现这个线程 ID 是自己的就表示没有竞争,不用重新 CAS。以后只要不发生竞争,这个对象就归该线程所有

比较Normal状态和偏向锁状态的Mark Word:

【一文读懂】 Java并发 - 锁升级原理_第6张图片

我们发现Normal状态下 biased_lock 是0,偏向锁的 biased_lock 是1; biased_lock 是偏向锁的开启标志,0表示禁用,1表示开启

而且对于Normal,用了 31bit 去存储对象的hashcode;
而偏向锁状态下不在记录对象的hashcode,而是记录线程编号:初始状态下 54bit 的thread标记都是0,当有线程对该对象上轻量级锁后, 54bit 的thread标记记录下当前线程编号,而且那么线程出了临界区释放了锁,thread不会发生改变,所以当该线程对该对象进行锁重入或者重新上锁时,发现里面的线程编号就是自己,就表示没有竞争,不用 CAS

而如果有另外一个线程要对该对象上锁时,发现当前记录着其他线程的编号,就进行锁膨胀,升级为轻量级锁

你可能感兴趣的:(Java并发,Java并发)