JVM之指针压缩

做java开发的同学一般都比较熟悉JVM，那么关于指针压缩这块内容是不是也了解呢，不熟悉的小伙伴往下看吧。

首先说明，本文涉及的JDK版本是1.8，JVM虚拟机是64位的HotSpot实现为准。

java对象结构

了解指针压缩前，需要先搞懂java的实例对象在JVM虚拟机中内存结构是什么样的。

java对象由三部分构成：

1. 对象头

对象头里也有三部分构成。

• Markword

存储对象的hashCode、垃圾回收对象的年龄以及锁信息等。

• 类型指针

对象指向的类信息地址即元数据指针，比如User对象指针指向User.class的JVM内存地址。注意：jdk1.8以后元数据是存在Metaspace里的，jdk1.8之前是在方法区里

• 数组长度

只有对象是数组的情况下，才有这部分数据，若对象不是数组，则没有这部分，不分配空间。

1. 对象体

对象里的非静态属性占用的空间（包括父类的所有属性，不区分修饰类型），不包括方法，注意：是非静态属性，属于对象的属性，静态属性是属于类的不在对象上分配空间。如果属性是基本数据类型，则直接存对象本身，如果是引用类型，则存的是对象的指针。

1. 对齐填充

如果对象头+对象体大小不是8字节的倍数，则通过该部分进行补齐，比如对象头+对象体大小只有30字节，则需要补齐到32字节，这里的对齐填充就是2字节。默认情况下，JVM中对象是以8字节对齐的，若对象头加上对象体是8的倍数时，则不存在字节对齐，否则会填充补齐到8的倍数。

对象结构如下图所示（默认情况下）。

压缩指针的由来

计算机操作系统分32位和64位，这里的位在计算机里是用0和1来表示的，用32个（或64个）二进制0和1的组合来表示内存地址。以32位为例，在普通的内存中，对象的大小最小是以1字节来计算的，通过0和1的排列组合，能够表示寻址的内存空间最大就是2^32个，换算成内存空间就是2 ^ 32 / 1024 / 1024 / 1024 = 4G，也就是说32位的操作系统最大能寻址的内存空间只有4G，同理，64位的操作系统（查阅资料显示其实没有用到64位，最多只用到了48位，这个可自行查阅资料，反正肯定比32位大的多）2 ^ 48 / 1024 / 1024 / 1024 / 1024 = 256TB，这样内存就足够大了，但是目前还没有厂商能生产出这么大的内存。

4G对于现在的java应用系统来说，内存已经算小的了，那我们就会想到使用64位的系统，这样内存就可以更大了，但是当我们准备将32位系统切换到64位系统，起初我们可能会期望系统性能会立马得到提升，但现实情况可能并不是这样的，为什么呢？

（1）32位系统对象指针是4字节，64位系统对象指针是8字节（1位表示1bit，8个bit表示1字节），这样64位系统中的对象引用占用的内存空间是32位系统中的两倍大小，因此间接的导致了在64位系统中更多的内存消耗以及更频繁的GC发生，GC占用的CPU时间越多，那么我们的应用程序占用CPU的时间就越少，响应会变慢，吞吐量会降低。

（2）对象的引用变大了，那么CPU可缓存的对象相对就少了，降低了CPU缓存命中率，增加了对内存的访问，CPU对CPU缓存的访问速度可比对内存的访问速度快太多了，所以大量的对内存访问，会降低CPU的执行效率，增加了执行时间，从而影响性能。

既然32位系统内存不够，64位内存够但又影响性能，那有没有折中方案来解决这两个问题呢，于是聪明的JVM开发者想到了利用压缩指针，在64位的操作系统中利用32位的对象指针引用获得超过4G的内存寻址空间。

如何压缩指针

由于在JVM里，对象都是以8字节对齐的即对象的大小都是8的倍数，所以不管用32位还是64位的二进制表示，末尾3位始终都是0。既然JVM已经知道了这些对象的内存地址后三位始终是0，那么这些无意义的0就没必要在堆中继续存储。相反，我们可以利用存储0的这3位bit存储一些有意义的信息，这样我们就多出3位bit的寻址空间，也就是说如果我们继续使用32位来存储指针，只不过后三位原本用来存储0的bit现在被我们用来存放有意义的地址空间信息，当寻址的时候，JVM将这32位的对象引用左移3位即可（后三位补0）。我们原本32位的内存寻址空间一下变成了35位，可寻址的内存空间变为2 ^ 35 / 1024 / 1024 / 1024 = 32G，也就是说在64位系统JVM的内存可扩大到32G了，基本上可满足大部分应用的使用了。

所以在64位系统下，通过压缩指针我们可以继续使用32位来处理（引用指针由8字节可降低到4字节），存储的时候右移3位，寻址的时候左移3位，如下图所示。

这样一来，JVM虽然额外的执行了一些位运算但是极大的提高了寻址空间，并且将对象引用占用内存大小降低了一半，节省了大量空间，况且这些位运算对于CPU来说是非常容易且轻量的操作，可谓是一举两得。

如何进一步扩大寻址空间

前边提到我们在Java虚拟机堆中对象起始地址均需要对其至8的倍数，不过这个数值我们可以通过JVM参数-XX:ObjectAlignmentInBytes 来改变（默认值为8）。当然这个数值的必须是2的次幂，数值范围需要在8 - 256之间。

正是因为对象地址对齐至8的倍数，才会多出3位bit让我们存储额外的地址信息，进而将4G的寻址空间提升至32G。

同样的道理，如果我们将ObjectAlignmentInBytes的数值设置为16呢？

对象地址均对齐至16的倍数，那么就会多出4位bit让我们存储额外的地址信息。寻址空间变为2 ^ 36 / 1024 / 1024 / 1024 = 64G。

通过以上规律，我们就能知道，在64位系统中开启压缩指针的情况，寻址范围的计算公式：4G * ObjectAlignmentInBytes = 寻址范围。

但是并不建议大家贸然这样做，因为增大了ObjectAlignmentInBytes虽然能扩大寻址范围，但是这同时也可能增加了对象之间的字节填充，导致压缩指针没有达到原本节省空间的效果。

JVM压缩指针参数

可以通过以下命令查看java命令默认的启动参数：

java -XX:+PrintCommandLineFlags -version

通过下面这个命令，可以看到所有JVM参数的默认值。

java -XX:+PrintFlagsFinal -version

关于压缩指针的两个参数：

UseCompressedClassPointers：压缩类指针

UseCompressedOops：压缩普通对象指针

Oops是Ordinary object pointers的缩写，这两个参数默认是开启的，即-XX:+UseCompressedClassPointers，-XX:+UseCompressedOops，也可手动设置，如下所示

-XX:+UseCompressedClassPointers //开启压缩类指针
-XX:-UseCompressedClassPointers //关闭压缩类指针
-XX:+UseCompressedOops  //开启压缩普通对象指针
-XX:-UseCompressedOops  //关闭压缩普通对象指针

32位HotSpot VM是不支持UseCompressedOops参数的，只有64位HotSpot VM才支持。

Oracle JDK从6 update 23开始在64位系统上会默认开启压缩指针。

实例

使用 JOL 工具分析 Java 对象

maven依赖

<dependency>
  <groupId>org.openjdk.jol</groupId>
  <artifactId>jol-core</artifactId>
  <version>0.17</version>
</dependency>

常用类及方法

查看对象内部信息： ClassLayout.parseInstance(obj).toPrintable()

查看对象外部信息：GraphLayout.parseInstance(obj).toPrintable()

查看对象占用空间总大小：GraphLayout.parseInstance(obj).totalSize()

查看类内部信息：ClassLayout.parseClass(Object.class).toPrintable()

JOL使用

public class ObjectLayOut1 {
    public static void main(String[] args) {
        Goods goods = new Goods();
        goods.setAge((short) 10);
        goods.setNo(123456);
        goods.setId(111L);
        goods.setGoodsName("方便面");
        goods.setFlag(true);
        goods.setB((byte)1);
        goods.setPrice(1.5d);
        goods.setProduceTime(LocalDateTime.now());
        goods.setType('A');
        goods.setWeight(0.065f);
        System.out.println(ClassLayout.parseInstance(goods).toPrintable());
    }

}

@Setter
class Goods {
    private byte b;
    private char type;
    private short age;
    private int no;
    private float weight;
    private double price;
    private long id;
    private boolean flag;
    private String goodsName;
    private LocalDateTime produceTime;
}

输出：

com.star95.study.jvm.Goods object internals:
OFF  SZ                      TYPE DESCRIPTION               VALUE
  0   8                           (object header: mark)     0x0000000000000001 (non-biasable; age: 0)
  8   4                           (object header: class)    0xf800c143
 12   4                       int Goods.no                  123456
 16   8                    double Goods.price               1.5
 24   8                      long Goods.id                  111
 32   4                     float Goods.weight              0.065
 36   2                      char Goods.type                A
 38   2                     short Goods.age                 10
 40   1                      byte Goods.b                   1
 41   1                   boolean Goods.flag                true
 42   2                           (alignment/padding gap)
 44   4          java.lang.String Goods.goodsName           (object)
 48   4   java.time.LocalDateTime Goods.produceTime         (object)
 52   4                           (object alignment gap)
Instance size: 56 bytes
Space losses: 2 bytes internal + 4 bytes external = 6 bytes total

OFF：表示偏移量

SZ：占用字节大小

TYPE DESCRIPTION：类型描述

VALUE：取值，基本类型存的就是实际值，引用类型存的是指针

压缩指针参数组合

以以上代码配合以下jvm参数设置，看压缩的不同结果

一、-XX:+UseCompressedOops -XX:+UseCompressedClassPointers

类指针压缩和普通对象压缩都开启，这个也是jdk1.8默认的，不加这两个参数，压缩也是生效的。



输出：



这里类指针和引用类型的属性都压缩到以4字节保存了，对象占用56个字节，对象大小计算公式：

对象大小=对象头+实例数据+（填充数据）

二、-XX:+UseCompressedOops -XX:-UseCompressedClassPointers

开启普通对象压缩，关闭类指针压缩。

输出：



类指针占8个字节，普通对象指针是4个字节，对象占用56个字节，这里我们也可以看到保存到的顺序改变了，这就是重排序，JVM会根据类型及对齐字节大小合理优化。

三、-XX:-UseCompressedOops -XX:-UseCompressedClassPointers

类指针和普通对象指针压缩都关闭。

输出：



类指针和普通对象指针都占8字节，压缩均关闭的情况下，我们看到对象大小变成了64字节。

四、-XX:-UseCompressedOops -XX:+UseCompressedClassPointers

关闭普通对象压缩，开启类指针压缩。

输出：



我们看到，类指针占8字节，对象指针占8字节，底部还有一个警告，意思是说类指针压缩依赖普通对象压缩，这种相当于关闭了类指针压缩和普通对象压缩。

• 开启 UseCompressedOops 时,UseCompressedClassPointers 会默认自动开启，可手工设置UseCompressedClassPointers的开启或关闭。
• 关闭 UseCompressedOops 时,UseCompressedClassPointers 也会默认自动关闭，无法设置UseCompressedClassPointers，设置了也不会生效。

内存大小对压缩的影响

结合以上代码例子，我们通过设置jvm堆内存大小，看看是否影响类指针压缩和普通对象压缩。

设置jvm参数：

-Xmx31g -Xms31g -XX:+UseCompressedOops -XX:+UseCompressedClassPointers

类指针和对象指针都被压缩到4字节了。

接着我们把堆内存加到32g试试。

-Xmx32g -Xms32g -XX:+UseCompressedOops -XX:+UseCompressedClassPointers

堆内存加到32g，虽然类指针压缩和对象压缩都开启了，但是输出的还是各占8字节，说明压缩失效了，而且最后JVM还会发出警告，意思是64位的虚拟机，对开启压缩来说堆内存太大了。

为什么呢？

我们来算一下，既然指针压缩到了4byte，也就是32bit，同样按照之前算的，用排列组合的方式可以识别2^32个对象，也就是4G个对象，刚才同样也说了，在Java中，非简单对象都是必须以8byte对齐。

因此，其能够识别的最大内存就是4G*8byte=32GB，所以内存过大，压缩自动失效了。

这也是为什么很多Java服务在运行中，官方都建议单个运行实例的内存设置不要超过32GB的根本原因。典型的如Elasticsearch，很多资料都说设置JVM大小不要超过32G，但是很少有提到为什么。

总结

• 通过指针压缩，利用对齐填充特性，通过映射方式达到了内存地址扩展的效果
• 指针压缩能够节省内存空间，同时提高了程序的寻址效率
• 堆内存设置最好不要超过32GB，这时指针压缩将会失效，造成空间的浪费
• 指针压缩不仅可以作用于对象头的类型指针，还可以作用于引用类型的字段指针（包括引用类型的数组指针）
• -XX:ObjectAlignmentInBytes，默认是 8，也就是 8 字节对齐