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）