2.4　synchronzied同步锁标记存储分析

如果synchronized同步锁想要实现多线程访问的互斥性，就必须保证多个线程竞争同一个资源，这个资源有点类似于生活中停车位上的红绿指示灯，绿灯表示车位闲置可以停车，红灯表示车位繁忙不能停车。在synchronized中，这个共享资源就是synchronized(lock)中的lock锁对象。

这就是对象锁和类锁能够影响锁的作用范围的原因，如果多个线程访问多个锁资源，就不存在竞争关系，也达不到互斥的效果，就像生活中两个停车位上的两个红绿指示灯，此时如果有两辆车停车，这两辆车之间就不会有竞争关系。

所以，从这个层面来看，要实现锁互斥要满足如下两个条件。

• 必须竞争同一个共享资源。

• 需要有一个标记来识别当前锁的状态是空闲还是繁忙。

第一个条件通过lock锁对象来实现即可，第二个条件需要有一个地方来存储抢占锁的标记，否则当其他线程来抢占资源时，不知道当前是应该正常执行还是应该排队，实际上，这个锁标记是存储在对象头中的，下面来简单分析一下对象头。

2.4.1　揭秘Mark Word的存储结构

一个Java对象被初始化之后会存储在堆内存中，那么这个对象在堆内存中存储了哪些信息呢？

Java对象存储结构可以分为三个部分：对象头、实例数据、对齐填充。当我们构建一个Object lock=new Object()对象实例时，这个lock实例最终的存储结构就对应如图2-6所示的模型。

下面分别针对对象头、实例数据、对齐填充的作用和存储结构进行详细的说明。

2.4.1.1　对象头

Java中对象头由三个部分组成：Mark Word、Klass Pointer、Length。

Mark Word

Mark Word记录了与对象和锁相关的信息，当这个对象作为锁对象来实现synchronized的同步操作时，锁标记和相关信息都是存储在Mark Word中的，具体的相关存储结构如图2-7所示。

在32位系统中，Mark Word的长度是4字节，在64位系统中，Mark Word的长度是8字节，如图2-8所示。

不管在32位还是64位系统中，Mark Word中都会包含GC分代年龄、锁状态标记、hashCode、epoch等信息。从图中可以看到一个锁状态的字段，它包含五种状态分别是无锁、偏向锁、轻量级锁、重量级锁、GC标记。Mark Word使用2bit来存储这些锁状态，但是我们都知道2bit最多只能表达四种状态：01、00、10、11，那么第五种状态如何表达呢？Mark Word额外通过1bit来表达无锁和偏向锁，其中0表示无锁、1表示偏向锁。

关于不同锁的状态，笔者在后续的内容中会详细说明。

Klass Pointer

Klass Pointer表示指向类的指针，JVM通过这个指针来确定对象具体属于哪个类的实例。

它的存储长度根据JVM的位数来决定，在32位的虚拟机中占4字节，在64位的虚拟机中占8字节，但是在JDK 1.8中，由于默认开启了指针压缩，所以压缩后在64位系统中只占4字节。

Length

表示数组长度，只有构建对象数组时才会有数组长度属性。

2.4.1.2　实例数据

实例数据其实就是类中所有的成员变量，比如，一个对象中包含int、boolean、long等类型的成员变量，这些成员变量就存储在实例数据中。

实例数据占据的存储空间是由成员变量的类型决定的，比如boolean占1字节、int占4字节、long占8字节。如果成员变量是引用类型，那么它的数据大小与虚拟机位数和是否开启压缩指针有关系。

2.4.1.3　对齐填充

对齐填充本身没有任何含义，其目的是使得当前对象实例占用的存储空间是8字节的倍数，所以如果一个对象的字节大小不是8字节的整数倍，会使用对齐填充来达到这一目的。

为什么要通过增加存储空间来做填充呢？其实，这类的设计基本上都离不开空间换时间的理念。深层次的原因在于减少CPU访问内存的频率，从而达到性能提升的效果，对于这部分的分析，笔者会在第3章中详细说明。

2.4.2　图解分析对象的实际存储

为了让读者更好地理解对象在内存中的布局，我们使用下面这个程序来进行详细说明。

从上述代码中可以看到，在main()方法中定义了MarkWordExample对象实例，并且该对象包含两个成员变量：id和name。在main()方法运行之后，就会形成如图2-9所示的存储结构。

2.4.3　通过ClassLayout查看对象内存布局

为了更加直观地看到一个对象的内存布局信息，OpenJDK官方提供了一个JOL（Java Object Layout）工具，使用步骤如下。

第一步，通过maven依赖引入JOL工具。

第二步，创建一个普通对象。

第三步，通过JOL工具打印对象的内存布局。

第四步，运行结果如下。

字段说明：

• OFFSET：偏移地址，单位为字节。

• SIZE：占用的内存大小，单位为字节。

• TYPE DESCRIPTION：类型描述，其中object header为对象头。

• VALUE：对应内存中当前存储的值。

上述内容的解读如下：

• TYPE DESCRIPTION字段对应的部分表示对象头（object header），一共占12字节，前面的8字节对应的是对象头中的Mark Word，最后4字节表示类型指针，它只占4字节是因为默认对指针进行了压缩。

• TYPE DESCRIPTION字段对应的（loss due to the next object alignment）描述部分，表示对齐填充，这里填充了4字节，从而保证最终的内存大小是8字节的整数倍。最终输出的Instance size: 16 bytes表示当前对象实例占16字节。

由于ClassLayoutExample只是一个空对象定义，因此在打印结果中只有对象头和对齐填充，没有实例数据部分。

2.4.3.1　关于压缩指针

在默认打印的对象内存布局信息中，Klass Pointer被压缩成4字节，如果我们不希望开启压缩指针功能，则可以增加一个JVM参数-XX:-UseCompressedOops。再次运行ClassLayoutExample，得到的结果如下。

从结果来看，Klass Pointer由4字节变成了8字节，而此时该对象的大小正好是16字节，是8字节的整数倍，因此不需要进行填充了。

2.4.3.2　详述对齐填充的作用

CPU在访问内存读取数据时，并不是按照逐个字节来访问的，而是以字长（Word Size）为单位来访问的。简单地说，字长是指CPU一次能够并行处理的二进制位数，字长总是8字节的整数倍。

比如在64位的操作系统中，CPU访问内存读取数据的单位就是8字节，在32位的操作系统中，CPU访问内存读取数据的单位是4字节，这样设计的目的是减少CPU访问内存的次数，提升CPU的使用率。

假设一个变量在内存中的存储跨越两个字长，形成如图2-10所示的结构，比如一个int类型的变量y占4字节，图2-8左边表示未对齐填充的内存布局，它会存在跨字长存储，右边表示对齐填充后的内存布局，不存在跨字长存储的情况。

如图2-11所示，在未对齐填充的内存布局中，CPU要读取变量y，由于跨越了两个字长，所以需要访问两次内存，第一次读取第一个字长获得最后三个有效字节，第二次读取第二个字长获得第二个字长的第一个有效字节，然后在寄存器中进行拼接。

但是在对齐填充的内存布局中，CPU读取变量x或者y，都只需要一次内存访问，虽然做了无效填充，但是访问内存的次数减少了，这种方式的计算性能更高，因此本质上来说这就是一种空间换时间的设计方式。

2.4.4　Hotspot虚拟机中对象存储的源码

在Hotspot虚拟机中，我们在使用new来创建一个普通对象实例的时候，实际上在JVM层面会创建一个instanceOopDesc对象，而如果对象实例是数组类型，则会创建一个arrayOopDesc对象。instanceOopDesc对象的定义在Hotspot源码的instanceOop.hpp文件中，arrayOopDesc对象定义在Hotspot源码的arrayOop.hpp文件中。

当在Java中实例化一个对象时，在JVM中会创建一个instanceOopDesc对象，该对象定义在instanceOopDesc.hpp文件中，核心代码如下。

instanceOopDesc继承了oopDesc，oopDesc的定义在oop.hpp文件中，代码如下。

这种写法给出了C++中的继承关系，在普通实例对象中，oopDesc的定义包含两个成员，分别是_mark和_metadata，Hotspot虚拟机采用OOP-Klass模型来描述Java对象实例，OOP（Ordinary Object Point）指的是普通对象指针，Klass用来描述对象实例的具体类型。

• _mark表示对象标记，属于markOop类型，也就是前面提到的Mark Word，它记录了对象和锁有关的信息。

• _metadata表示类元信息，类元信息存储的是对象指向它的类元数据（Klass）的首地址。

○ Klass表示普通指针，指向该对象的类元信息，也就是属于哪一个Class实例。

○ _compressed_klass表示压缩指针，默认开启了压缩指针，在开启压缩指针之后，存储中占用的字节数会被压缩。

接着我们重点关注markOop这个对象属性，markOop是一个markOopDesc类型的指针，它的定义在oopsHierarchy.hpp文件中。

在Hotspot中，markOopDesc这个类的定义在markOop.hpp文件中，代码如下：

实际上，在markOop.hpp文件的注释中，同样可以看到Mark Word在32位和64位虚拟机上的存储布局。

至此，我们从JVM的源码中完整地验证了与对象头相关的存储信息。