一、前言
相信大家如果在看JDK源码时，比如：ConcurrentHashMap 源码时，一定见过如下代码：
public class ConcurrentHashMap<K,V> extends AbstractMap<K,V>
implements ConcurrentMap<K,V>, Serializable {
// Unsafe mechanics
private static final sun.misc.Unsafe U;
private static final long SIZECTL;
private static final long TRANSFERINDEX;
private static final long BASECOUNT;
private static final long CELLSBUSY;
private static final long CELLVALUE;
private static final long ABASE;
private static final int ASHIFT;
static {
try {
U = sun.misc.Unsafe.getUnsafe();
Class<?> k = ConcurrentHashMap.class;
SIZECTL = U.objectFieldOffset(k.getDeclaredField("sizeCtl"));
TRANSFERINDEX = U.objectFieldOffset(k.getDeclaredField("transferIndex"));
BASECOUNT = U.objectFieldOffset(k.getDeclaredField("baseCount"));
CELLSBUSY = U.objectFieldOffset(k.getDeclaredField("cellsBusy"));
Class<?> ck = CounterCell.class;
CELLVALUE = U.objectFieldOffset(ck.getDeclaredField("value"));
Class<?> ak = Node[].class;
ABASE = U.arrayBaseOffset(ak);
int scale = U.arrayIndexScale(ak);
if ((scale & (scale - 1)) != 0)
throw new Error("data type scale not a power of two");
ASHIFT = 31 - Integer.numberOfLeadingZeros(scale);
} catch (Exception e) {
throw new Error(e);
}
}
}
这段代码大家难道不好奇是什么意思么？我们写段测试代码，来查看如上这些值（通过反射）：
public class Main {
public static void main(String[] args) {
ConcurrentHashMap<String, String> map = new ConcurrentHashMap<>();
reflect(map, "SIZECTL");
reflect(map, "TRANSFERINDEX");
reflect(map, "BASECOUNT");
reflect(map, "CELLSBUSY");
reflect(map, "CELLVALUE");
reflect(map, "ABASE");
reflect(map, "ASHIFT");
}
private static void reflect(Object object, String name) {
Class clazz = object.getClass();
try {
Field field = clazz.getDeclaredField(name);
field.setAccessible(true);
System.out.println(field.getName() + " = " + field.get(object));
} catch (Exception e) {
e.printStackTrace();
}
}
}
结果打印如下：
SIZECTL = 20
TRANSFERINDEX = 32
BASECOUNT = 24
CELLSBUSY = 36
CELLVALUE = 144
ABASE = 16
ASHIFT = 2
为何要用反射，而不直接用『Unsafe』？因为这个类不允许JDK包以外的代码直接调用：
public final class Unsafe {s
private Unsafe() {
}
@CallerSensitive
public static Unsafe getUnsafe() {
Class var0 = Reflection.getCallerClass();
// 这里做了判断，会报 SecurityException !
if (!VM.isSystemDomainLoader(var0.getClassLoader())) {
throw new SecurityException("Unsafe");
} else {
return theUnsafe;
}
}
}
相信大家也注意到了这行代码，类似这样：
SIZECTL = U.objectFieldOffset(k.getDeclaredField("sizeCtl"));
直译就是：获取对象的偏移值！
啥叫对象的偏移值？
可能大家做了太久的 Java，已经忘记了 C/C++ 时代，对象在内存中的地址，或者这么说：变量在对象实例中的内存地址。即变量相对于对象的内存地址的偏移量！
比较绕口，没事，咱们今天就聊聊这个话题：
二、JOL（Java Object Layout）
在正式聊这个话题前，希望大家看一下这篇文章《父类引用可以指向子类对象，子类引用不能指向父类对象》。
2.1、再谈初始化过程
这篇文章其实还告诉我们一个大家都知道的结论：
子类初始化时，会先初始化父类；
如果父类还有父类，则重复第 1 步；
直到 Object ；
这也就是为何，子类可以强转成父类（因为子类内存空间含有父类的那一块初始化好的内存）！
2.2、类型占用内存大小
我们知道，每个类型的对象，其所占用的内存是不一样的，例如：
int 占 4字节，long 占8字节
我们还知道，JVM要求字节对齐，根据 32位/64位 的 JVM来决定，即 8的倍数（4字节 or 8字节）。
根据 2.1 小节中所说的，子类有自己的内存空间，还含有父类、祖父类等等直到 Object 类为止的所有内存空间，那这些内存空间是如何分布的呢？
我们来看个例子：
public class G {
private long gl;
private int gi;
}
public class P extends G {
private long pl;
private int pi;
}
打印内存分布：
com.layout.java.P object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 81 c1 00 f8 (10000001 11000001 00000000 11111000) (-134168191)
12 4 int G.gi 0
16 8 long G.gl 0
24 8 long P.pl 0
32 4 int P.pi 0
36 4 (loss due to the next object alignment)
Instance size: 40 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
我们看到了 『object header』，有没有什么印象？如果有印象，那我的《Java小白系列（三）：Synchronized进阶》也就没有白讲。
对的，obejct header 就是我们说的『对象头』，再来回忆下：
2.3、再谈『对象头』
我们先看看，上面中的例子，对象头大小是12字节，那我们的 JVM 是 32位呢还是64位呢？
首先，P对象不是数组，因此只有『Mark Word』和『Class Metadata Address』：
如果 JVM 是32位，则 4 + 4 = 8字节 < 12字节；
如果 JVM 是64位，则 8 + 8 = 16字节 > 12字节；
难不成还有48位的 JVM ？
当然没有 48位的 JVM，那这 12字节如何而来？这就涉及到一个新的词『压缩指针』
2.4、压缩指针的作用
在 64 位的 Java 虚拟机中，对象头的标记字段占 64 位，而类型指针又占了 64 位。也就是说，每一个 Java 对象在内存中的额外开销就是 16 个字节。以 Integer 类为例，它仅有一个 int 类型的私有字段，占 4 个字节。因此，每一个 Integer 对象的额外内存开销至少是 400%。这也是为什么 Java 要引入基本类型的原因之一。
为了尽量较少对象的内存使用量，64 位 Java 虚拟机引入了压缩指针 [1] 的概念（对应虚拟机选项 -XX:+UseCompressedOops，默认开启），将堆中原本 64 位的 Java 对象指针压缩成 32 位的。
这样一来，对象头中的类型指针也会被压缩成 32 位，使得对象头的大小从 16 字节降至 12 字节。当然，压缩指针不仅可以作用于对象头的类型指针，还可以作用于引用类型的字段，以及引用类型数组。
2.5、压缩指针的原理
先来举个例子，方便后续讲解：
打个比方，路上停着的全是卡车，而且每辆卡车恰好占据两个停车位。现在，我们按照顺序给它们编号。也就是说，停在 0 号和 1 号停车位上的叫 0 号车，停在 2 号和 3 号停车位上的叫 1 号车，依次类推。
原本的内存寻址用的是车位号。比如说我有一个值为 6 的指针，代表第 6 个车位，那么沿着这个指针可以找到 3 号车。现在我们规定指针里存的值是车号，比如 3 指代 3 号车。当需要查找 3 号车时，我便可以将该指针的值乘以 2，再沿着 6 号车位找到 3 号车。
这样一来，32 位压缩指针最多可以标记 2 的 32 次方辆车，对应着 2 的 33 次方个车位。当然，卡车也有大小之分。大卡车占据的车位可能是三个甚至是更多。不过这并不会影响我们的寻址算法：我们只需跳过部分车号，便可以保持原本车号 *2 的寻址系统。
上述模型有一个前提，就是每辆车都从偶数号车位停起。这个概念我们称之为内存对齐（对应虚拟机选项 -XX:ObjectAlignmentInBytes，默认值为 8）。
默认情况下，Java 虚拟机堆中对象的起始地址需要对齐至 8 的倍数。如果一个对象用不到 8N 个字节，那么空白的那部分空间就浪费掉了。这些浪费掉的空间我们称之为对象间的填充（padding）。
在默认情况下，Java 虚拟机中的 32 位压缩指针可以寻址到 2 的 35 次方个字节，也就是 32GB 的地址空间（超过 32GB 则会关闭压缩指针）。
在对压缩指针解引用时，我们需要将其左移 3 位，再加上一个固定偏移量，便可以得到能够寻址 32GB 地址空间的伪 64 位指针了。
此外，我们可以通过配置刚刚提到的内存对齐选项（-XX:ObjectAlignmentInBytes）来进一步提升寻址范围。但是，这同时也可能增加对象间填充，导致压缩指针没有达到原本节省空间的效果。
当然，就算是关闭了压缩指针，Java 虚拟机还是会进行内存对齐。此外，内存对齐不仅存在于对象与对象之间，也存在于对象中的字段之间。比如说，Java 虚拟机要求 long 字段、double 字段，以及非压缩指针状态下的引用字段地址为 8 的倍数。
字段内存对齐的其中一个原因，是让字段只出现在同一 CPU 的缓存行中。如果字段不是对齐的，那么就有可能出现跨缓存行的字段。也就是说，该字段的读取可能需要替换两个缓存行，而该字段的存储也会同时污染两个缓存行。这两种情况对程序的执行效率而言都是不利的。
2.6、字段重排列
字段重排列，顾名思义，就是 Java 虚拟机重新分配字段的先后顺序，以达到内存对齐的目的。Java 虚拟机中有三种排列方法（对应 Java 虚拟机选项 -XX:FieldsAllocationStyle，默认值为 1），但都会遵循如下两个规则。
如果一个字段占据 C 个字节，那么该字段的偏移量需要对齐至 NC。这里偏移量指的是字段地址与对象的起始地址差值。
以 long 类为例，它仅有一个 long 类型的实例字段。在使用了压缩指针的 64 位虚拟机中，尽管对象头的大小为 12 个字节，该 long 类型字段的偏移量也只能是 16，而中间空着的 4 个字节便会被浪费掉。
其二，子类所继承字段的偏移量，需要与父类对应字段的偏移量保持一致。
在具体实现中，Java 虚拟机还会对齐子类字段的起始位置。对于使用了压缩指针的 64 位虚拟机，子类第一个字段需要对齐至 4N；而对于关闭了压缩指针的 64 位虚拟机，子类第一个字段则需要对齐至 8N。
再来看看之前的例子打印出来的字段排列顺序：
# 启用压缩指针时
com.layout.java.P object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 81 c1 00 f8 (10000001 11000001 00000000 11111000) (-134168191)
12 4 int G.gi 0
16 8 long G.gl 0
24 8 long P.pl 0
32 4 int P.pi 0
36 4 (loss due to the next object alignment)
Instance size: 40 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
当启用压缩指针时，可以看到 Java 虚拟机将 A 类的 int 字段放置于 long 字段之前，以填充因为 long 字段对齐造成的 4 字节缺口。由于对象整体大小需要对齐至 8N，因此对象的最后会有 4 字节的空白填充。
# 关闭压缩指针时
com.layout.java.P object internals:
OFFSET SIZE TYPE DESCRIPTION
0 4 (object header)
4 4 (object header)
8 4 (object header)
12 4 (object header)
16 8 long G.gl
24 4 int G.gi
28 4 (alignment/padding gap)
32 8 long P.pl
40 4 int P.pi
44 4 (loss due to the next object alignment)
Instance size: 48 bytes
Space losses: 4 bytes internal + 4 bytes external = 8 bytes total
当关闭压缩指针时，B 类字段的起始位置需对齐至 8N。这么一来，B 类字段的前后各有 4 字节的空白。那么我们可不可以将 B 类的 int 字段移至前面的空白中，从而节省这 8 字节呢？
2.7、虚共享（false sharing）
Java 8 还引入了一个新的注解 @Contended，用来解决对象字段之间的虚共享（false sharing）问题 。这个注解也会影响到字段的排列。
虚共享是怎么回事呢？假设两个线程分别访问同一对象中不同的 volatile 字段，逻辑上它们并没有共享内容，因此不需要同步。
然而，如果这两个字段恰好在同一个缓存行中，那么对这些字段的写操作会导致缓存行的写回，也就造成了实质上的共享。（volatile 字段和缓存行的故事我会在之后的篇章中详细介绍。）
Java 虚拟机会让不同的 @Contended 字段处于独立的缓存行中，因此会看到大量的空间被浪费掉。具体的分布算法属于实现细节，随着 Java 版本的变动也比较大。
三、JOL工具
本篇例子中的工具就叫：JOL，它是由 openjdk 官方提供，专门用于查看 openjdk/JOL
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.14</version>
</dependency>
使用方式：
private static void print(Object o) {
String classLayout = ClassLayout.parseInstance(o).toPrintable();
System.out.println(classLayout);
}
