常见面试-JVM-指针压缩

关注

原创最新推荐文章于 2026-02-09 13:09:55 发布 1.7k 阅读 AI 写同款· GEO 优化 ›

jvm 参数 +UseCompressedClassPointers java -XX:+PrintCommandLineFlags -version 注意：最大堆内存和最小堆内存一般设置为统一，避免它自动膨胀缩小浪费资源 //对象头指针的大小可以压缩前两个 object header 为mardword 第三个为 class point 禁止压缩classpoint （从4byte 变为 8byte）前两个 object header 为mardwo... 阅读详情

了解指针压缩前，首先需要了解对象的内存布局结构

对象内存结构

在 Hotspot 虚拟机中，对象在内存中的布局可以分为 3 块区域：

1.对象头

Hotspot 虚拟机的对象头包括两部分信息：

第一部分用于存储对象自身的运行时数据（哈希码、GC 分代年龄、锁状态标志等等）

另一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

其实还有一个数组长度

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

2.实例数据（对象体）

实例数据部分是对象真正存储的有效信息，也是在程序中所定义的各种类型的字段内容。

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

3.对齐填充

对齐填充部分不是必然存在的，也没有什么特别的含义，仅仅起占位作用。 因为 Hotspot 虚拟机的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍。比如对象头+实例数据大小只有30字节，则需要补齐到32字节，换句话说就是对象的大小必须是 8 字节的整数倍。因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

指针压缩

计算机操作系统分32位和64位，即用32个（或64个）二进制0和1的组合来表示内存地址。

以32位为例，在普通的内存中，通过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。

例如：8 = ...00001000, 16 = ...00010000，24 = ...00011000

既然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来说是非常容易且轻量的操作，可谓是一举两得。

常见数据大小

在64位机器上，

开启指针压缩（-XX:-UseCompressedOops）的情况下，对象头占用12bytes

不开启指针压缩（-XX:+UseCompressedOops）则占用16bytes

对象引用（reference）类型在64位机器上，关闭指针压缩时占用8bytes，开启时占用4bytes。

例子：一个包含两个属性的对象：int和byte，并不是占用17bytes(12+4+1)，而是占用24bytes（对17bytes进行8字节对齐）

数组对象的对象头占用24 bytes，启用压缩后占用16字节。比普通对象占用内存多是因为需要额外的空间存储数组的长度。

int[10]:

开启压缩：16 + 10 * 4 = 56 bytes；
关闭压缩：24 + 10 * 4 = 64bytes。

如何进一步扩大寻址空间

前边提到在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压缩指针参数

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

UseCompressedClassPointers：压缩类指针
UseCompressedOops：压缩普通对象指针
Oops是Ordinary object pointers的缩写，这两个参数默认是开启的，也可手动设置，如下所示

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

实例

使用 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()

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

参考转载：https://www.cnblogs.com/star95/p/17512212.html