synchronized凭什么锁得住?

相关链接:

《synchronized锁住的是谁?》

我们知道synchronized是重量级锁,我们知道synchronized锁住的是一个对象上的Monitor对象,我们也知道synchronized用于同步代码块时会执行monitorenter和monitorexit等。

上面几个问题仅仅是校招级。

那么synchronized为什么“重”呢?Monitor对象从何而来呢?synchronized用于实例方法或者静态方法又是怎么锁住的呢?

《synchronized锁住的是谁?》中我们明确了,synchronized锁住的对象,本文讲述synchronized凭什么锁得住。

首先我们需要知道的是在Hotspot虚拟机实现中,对象实例在堆内存中结构分为3个部分:对象头、实例数据、对其填充字节。在Java中万物皆为对象。就算一个Java类被编译称为class二进制文件在被加载到内存时,它仍然会在堆内存中创建一个Class对象。这也就解释了,为什么synchronized能对类加锁(因为每个类在堆内存中有一个Class对象,对于类synchronized锁的实际上是Class对象,下文会继续解释)。

在解释了Java中对象实例在Hotspot中的内存结构(对象头、实例数据、对其填充字节)后,synchronized锁住的Monitor对象就存在于对象头之中。对象头又分为:Mark Word、指向类的指针、数组长度(数组对象)。

对象头在Hotspot虚拟机实现中,分为32位和64位的实现,实际上Hotspot源代码实现中的注释已经解释得非常清楚了(openjdk/hotspot/share/oops/markOop.hpp),对象头的Mark Word位格式在32位机器中是32位长,在64位机器中是64位长(采用 big endian ,低地址存放最高有效字节,即低位在左,高位再右)。

32bit位虚拟机Mark Word

锁状态

25bit

4bit

1bit

2bit

23bit

2bit

是否是偏向锁

锁标志位

无锁状态

对象的hashcode

分代年龄

0

01

偏向锁

线程ID

偏向时间戳

分代年龄

1

01

轻量级锁

指向栈中锁记录的指针

00

重量级锁

指向重量级锁(Monitor)的指针

10

GC标记

11

和synchronized相关的就是Java在Hotspot虚拟机实现中对象头中的Mark Word。

在以前(JDK5之前),synchronized被称为重量级锁是无可厚非的,但在JDK6后,JVM对其进行了一系列优化,尽量使得synchronized不再那么重。之所以synchronized重,是因为它涉及到了操作系统用户态与核心态的转换,下文再详细解释。这里我们从最轻的偏向锁->轻量级锁->重量级锁的过程,注意他们只能升级加锁的强度,不能降级。

偏向锁

上面提到了JDK6过后优化了synchronized的加锁过程,尽量使得synchronized不再那么重。偏向锁即是如此。

JVM的研究者表明,大多数情况下锁的竞争不是那么激励,在不那么激励的时候如果通过获取Monitor来进行同步访问,会造成线程在操作系统用户态和核心态的转换,这会使得系统性能下降。偏向锁表示,当只有一个线程进入同步方法或同步代码块时,并不会直接获取Monitor锁,而是先判断对象头中Mark Word部分的锁标志位是否处于“01”,如果处于“01”,此时再判断线程ID是否是本线程ID,如果是则直接进入方法进行后续操作;如果不是,此时则通过CAS(无锁机制竞争)如果竞争成功,此时将线程ID设置为本线程ID,如果竞争失败,说明造成了有了较为强烈的锁竞争,偏向锁已不能满足,此时偏向锁晋级为轻量级锁。

轻量级锁

当锁发生竞争时,持有偏向锁的线程会撤销偏向锁,转而晋级为轻量级锁(状态)。轻量级锁的核心是,不让未获取锁的线程进入阻塞状态,因为这会使得线程由用户态转为核心态,这会造成很大的性能损失,而是采用“死循环”的方式不断的获取锁,这种采用“死循环”获取的锁的方式称为——锁自旋。它不会让线程陷入阻塞,但同时仅适用于持有锁时间较短的场景。那么轻量级锁升级为重量级锁的条件就是,自旋等待的时间过长,并且又有了新的线程来竞争。

重量级锁

这种锁,就是地地道道原原本本synchronized的本意了。线程会去抢夺对象上的一个互斥量(这个互斥量就是Monitor),每个对象都会有,就算是类也有一个Monitor互斥量(因为类在堆内存中有一个Class对象)。当一个线程获取到对象的Monitor锁时,其余线程会被阻塞挂起,并且由用户态转为核心态。

上文提到在锁的竞争状态晋级为重量级锁时,Java对象头中的Mark Word前30位存储的是Monitor对象的指针。Monitor对象定义在openjdk/hotspot/share/runtime/objectMonitor.hpp中,在ObjectMonitor中定义了:计数器、持有Monitor的线程、处于wait状态的线程、处于阻塞状态的线程等等。

synchronized无论是普通实例还是同步代码块,它所获取的锁是对象实例中的Monitor锁,而对象的Monitor又是存在于Java对象头的Mark Work之中,所以可以这么说,synchronized获取的锁在Java对象头中。对于普通实例或者静态方法,JVM并没有显示的指令进入临界区,而是在方法上标识了“ACC_SYNCHRONIZED”,标识是synchronized同步方法,方法内部都是临界区。而对于同步代码块,则在synchronized代码块开始执行了monitorenter,结束或者抛出异常时执行了monitorexit指令。

synchronized凭借的就是Monitor锁住的对象,Monitor又是借助于操作系统的mutex lock,之所以它重是因为它被挂起后线程会由用户态转换为内核态,这个转换会带来性能损耗。JDK6开始对其进行了优化,提出了偏向锁和轻量级锁,针对锁竞争较为激烈的场景不会直接去获取Monitor对象,减少性能损耗。因此在现如今的synchronized实现中,它的性能劣势也已不再那么明显。

 

 

这是一个能给程序员加buff的公众号 (CoderBuff)

 

posted @ 2019-06-19 00:12 OKevin 阅读(...) 评论(...) 编辑 收藏