当今，Java已经成为了世界上最流行的编程语言之一。在Java的生态系统中，JVM（Java虚拟机）是至关重要的组成部分。JVM 是 Java 程序运行的环境，它负责将 Java 字节码翻译成机器码，并执行程序。在 JVM 中，内存使用以及分配一直是个重要的问题。

在 32 位系统中，一枚指针占用 4 字节，随着 64 位系统的逐渐普及，指针的大小也增长到了 8 个字节，JVM 为了降低内存占用，使用了指针压缩技术来降低内存的占用，接下来，我们将自顶向下的深入探讨 JVM 指针压缩的工作原理。

在计算机中，指针的大小通常取决于计算机的字长。例如，在 32 位系统一字长为 4 字节，即一枚指针的占用内存空间大小为 4 字节。随着计算机性能的提升，内存价格的降低，64 位系统也开始逐渐普及。而在 64 位系统中，字长和指针也由原来的增长到 8 个字节，JVM 为了降低内存占用，开发了指针压缩算法，即：在 64 位系统中，指针依然使用 4 字节存储。

字长是指一台计算机中处理器可以一次性处理的二进制数字的位数。它通常是 8 位、16 位、32 位或 64 位，这意味着在一次处理中可以处理 8 个、16 个、32 个或 64 个二进制数字。字长越长，计算机处理数据的能力越强，但同时也会增加计算机的成本和复杂度。

CPU 的上下文是寄存器，CPU 运算的本质就是不断从 CS IP 寄存器中取指令然后执行，CPU 运算所需的数据也是放在寄存器里，CPU 一次性处理的数据大小就是寄存器的大小。

上图左侧是一段简单的 C 语言代码片段，右侧是该代码的汇编代码（即 CPU 执行这段代码的实际机器码的解释）。

CPU 执行计算时，需要先将数据读取到寄存器，存取内存中的变量时，是直接操作变量所在地址及偏移量，而变量所在地址（即指针）也是存储在寄存器中的，因此寄存器大小直接决定了 CPU 所能访问内存的地址空间。因此，在 32 位系统中，寄存器的最大长度是 32 bit（即 4 个字节），因此最大支持访问 4GB 的内存空间，在 64 位系统中，寄存器最大 64 bit（即 8 字节）。而数据的指针由于需要指向整个内存空间，因此也就是 8 字节。8 字节大小的指针所能允许访问的最大地址为：16EB（16384PB=16777216TB=17179869184GB）的内存空间。

所以字长其实就等于寄存器的大小，指针为了能指向整个内存空间，通常也等于字长大小。

这是一段简单的 C 语言代码：

#include <stdio.h>struct Test {    int a;    char b;    int c;} test;
int main(void) {    test.a = 1;    test.b = 2;    test.c = 3;    printf("struct Test size: %d\n", sizeof(test));    return 0;}

在 C 语言中，结构体数据是连续的，Int 为 4 字节，Char 为 1 字节，所以 Struct Test 为 9 字节。

但是实际输出结果却是 12 字节：

通过汇编指令可以分析出，结构体 Test 的内存布局如下：

可以看出，在 Char 类型数据后面被空出了 3 个字节的位置，原因如下：

计算机只能从 4 字节的整数倍开始寻址，如果在 Char b 后不进行空数据填充，则编译后的指令会很长，极大的降低 CPU 执行效率：

所以在 JVM 中，对象的存储也是如此设计：

class Test {    int a;    char b;    int c;}

对象布局如下：

可以看出 Char b 数据后空出了 3 个字节的内存空间作为 Padding， 以供后面的对象进行内存对齐。

计算机之所以只能从特定地址开始读取数据，是由于在内存中存储的物理位置导致的。

这是一根内存条，上面有 4 个内存颗粒（Chip），在我们声明一个变量 Int a = 1;时，CPU 想一次从内存中同时取出 32 位数据，为了发挥并行传输数据的能力，同时与 4 个内存颗粒进行交互肯定比一个内存交互要快，因此数据 a 分别在 4 个颗粒中存储 0x01 0x00 0x00 0x00。

每个内存颗粒 Chip 中有 8 个 bank，每次同时从 8 个 bank 中取一位数据。

为了尽可能节约地址总线位数，变量 a 的每字节数据在各 Chip 中相对位置是相同的，每字节中的每位数据在 bank 中的行数和列数也是相同的。

总结，为了能利用有限的地址总线，尽量快速寻址到尽可能多的数据，在设计计算机时取了巧，CPU 同时只能访问 32 个相对地址相同的数据位，表现上就是只能从被 4 字节整除的地址开始寻址。

在 64 位系统中，JVM 为了降低 8 字节的指针对内存的占用，使用了指针压缩的技术，将 8 字节的指针压缩为 4 字节。

前面说到，JVM 出于性能考虑，对数据做了对齐到 4 字节的处理，因此指针的值末尾 5 bit 始终为 0B11111。JVM 的指针压缩算法就是，把本来应该使用 8 个字节的指针，直接改为 4 字节的进行代替，那么 4 字节的指针实际最高可以表示 32G 的内存空间。这也就是为什么当物理内存超过 32G 时，需要关闭 JVM 指针压缩。

HSDB

HSDB（HotSpot Debugger），是一个用于 HotSpot 虚拟机的调试工具。它提供了一种可视化的方式来查看和调试 Java 应用程序在 JVM 上的运行情况。HSDB 可以用于分析线程、堆、类、对象、方法、编译器和代码缓存等方面的信息。它还可以用于监视虚拟机性能和调试垃圾回收器。HSDB 是一个非常强大的工具，可以帮助开发人员更好地理解和优化 Java 应用程序的性能。

官方提供的 HSDB 命令行不是很好用，比如命令补全、命令提示、光标移动、命令历史记录等都不存在，所以本次分享讲利用 PerfMa 开源的 XPocket 工具，配合 HSDB 插件来操作。

XPocket 工具

XPocket 是 PerfMa 为解决性能问题而生的开源的插件容器，它是性能领域的乐高，将定位或者解决各种性能问题的常见的 Linux 命令，JDK 工具，知名性能工具等适配成各种 XPocket 插件，并让它们可以相互联动一键解决特定的性能问题。目前 XPocket 插件生态已经实现了 HSDB、JDB、JConsole、Perf、Arthas 等多个优秀的开源性能工具的插件化集成。

下载 XPocket，然后解压运行。

wget https://a.perfma.net/xpocket/download/XPocket.tar.gztar -xvf  XPocket.tar.gzsh xpocket/xpocket.sh

# 切换至 HSDB 插件空间XPocket [system] > use jhsdb@JDK# 启动 clhsdb 命令行XPocket [jhsdb] > clhsdb# attach 到目标进程XPocket [jhsdb] > attach 29516

准备工作

编写一个测试类，启动 JVM 进程。

@Data@Componentpublic class BeanTest {    private long l = 1;    private BeanTest pointer = this;    private int i = 2;    private boolean b = false;    private char c = 3;    private BeanTest[] arr = {this};}

想要查看对象的内存布局，首先要找到这个对象所在位置，JVM 的对象分布在堆上，可以通过 Universe 命令确定堆内的相关区域对应位置。

# 执行以下命令，切换至 HSDB 插件XPocket [system] > use jhsdb@JDK# 启动 HSDB 插件XPocket [jhsdb] > clhsdb# 通过 jps 命令，查询 JVM 进程的 pid，attach 到这个 JVM 进程XPocket [jhsdb] > attach 29516# 执行 universe 命令，查看堆内存分布情况XPocket [jhsdb : 29516] > universe

内存分布情况如下：

括号内的第一个值为内存起始位置，第二个值为已使用的位置，第三个值为该区域最大地址。以上图 eden 区为例：

eden 区空间范围为：0x00000000fab00000 ～ 0x00000000fef00000，相减得到 71303168，68MB。

eden 区已使用空间为：0x00000000fab00000 ～ 0x00000000fafd2a60，相减得到 5057120，4.82M。

找到我们定义的对象

我们要找的对象是受 Spring 管理的，所以很容易判断，通常情况下都会在老年代里。那么我们直接在老年代内检索这个对象即可。由于 Oop（简单对象指针）是所有 Java 对象的基类，所以我们可以利用 Scanoops 命令来检索这个对象。

XPocket [jhsdb : 29516] > scanoops 0x00000000f0000000 0x00000000f1265ca8 com.poizon.robot.test.BeanTest

检索到的结果如下：

0x00000000f1060898 是这个对象实例的内存地址，也就是该对象的指针值。

查看对象内存布局

然后我们就可以通过 Inspect 命令来查看该对象的内存布局了。

XPocket [jhsdb : 29516] > inspect 0x00000000f1060898

得到结果如下：

注意：这里显示的数据是按照类变量顺序来展示的，并非实际结构

由图返回结果可以看出， BeanTest 对象大小为 40 字节，当前系统为 X64 架构，一个字长为 8 字节，即此对象占用 5 个字长。执行 Mem 命令，获取整个对象（5 个字长）的数据。

XPocket [jhsdb : 29516] > mem 0x00000000f1060898 5

得到结果如下：

左侧为当前字长的数据起始地址，右侧为数据值。

我们再来复习一遍对象头（Oop数据），前 8 位是 Mark Word，后 8 位中，如果开启了指针压缩，则前 4 位为当前实例所在类的指针，后 4 位填充当前对象 <=4 字节的数据（Gap Padding）；如果未开启指针压缩，则该 8 位为当前实例对所在类的指针。

查找类的指针

我们这次启动的进程开启了指针压缩，把第二个字长的数据（0x000000022007a2bb）按 4 字节拆成两部分：

0x00000002：BeanTest 对象中只有一个值为 2 ，所以该值是Int i = 2；

0x2007a2bb（类指针）：前面说过，指针压缩的原理只是简单的把 8 字节指针削减为 4 字节，因为后 5 位始终为 0，因此若要还原压缩后的指针实际内存地址，直接把指针值 * 8即可。

BeanTest 类所在地址为：0x2007a2bb * 8 = 0x1003D15D8

执行 Inspect 命令，查看 BeanTest 类结构。

XPocket [jhsdb : 29516] > inspect 0x1003D15D8

结果如下：

证实

BeanTest 在 JVM 对象为 c++ 的 InstanceKlass 实例，可以看出 _name 属性为 Symbol，接下来查看 InstanceKlass _name 属性，证实当前为 BeanTest 类的实例，执行 Symbol 命令查看 _name 的值：

XPocket [jhsdb : 29516] > symbol 0x00007f1838abb740

证实 0x1003D15D8 所在的内存地址，即是 com.poizon.robot.test.BeanTest 的 Class 对象。

在我们日常开发中遇到的一点小小的，看似不起眼的奇怪的规范，深挖之下往往能够牵扯出一大串知识体系，保持好奇心刨根问底同样也是很重要学习方法。有兴趣的同学也可以自己尝试找一下示例类中其他属性所对应的 Class 指针，说不定还可以对网上的一些文章做一次勘误呢～

点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦