JVM指针压缩性能问题

    当前一台个人台式机的内存都能随随便便超过4G内存，所以现在基本上大家用的都是64位的JVM。对于32位的JVM来说，对象引用(指针)的长度是32位，能表示的最大范围是2^32 = 4G，而对于64位的JVM来说，对象应用的长度就变成了2^64...懒得算剋以表示多大的范围了，总之来说就是64位长度的指针有点浪费了，平白增加了内存的损耗和GC开销。

    所以在JDK 1.6的版本后，64位的JVM默认情况下是开启指针压缩（-XX: +UseCompressedOops）来压缩我们对象指针的大小来帮助我们节约内存空间。

 

如何进行指针压缩：

    简单来说就是如何使用32位的指针来指向32G的空间。

    32位的指针只能表示4G的空间，如果32G的空间每8个字节表示一个单元，指针指向的是每个单元，那么32位的指针就可以指向32G的空间了。

    而JVM也正是这么实现的。将最低位空间设置为初始值，其他空间以其作为offset进行表示，从而达到32位指针表示32G空间的效果。

 

指针压缩后的性能：

    注意，如果内存在4G以下，JVM会直接使用低32位，无需指针压缩。如果内存在32G以上，那么JVM就不会进行指针压缩(JVM在40/50G时才能达到32G的效果)。所以我们应当尽量JVM的内存在32G以下。

    以项目中使用Spark为例，相比较于使用一个90G的Executor，分成3个30G的Executor，内存使用率以及计算速度都能提升30%以上。

 

 

 

参考：

    https://www.cnblogs.com/wanhua-wu/p/9305372.html(不分配大内存给ES)

    https://juejin.im/post/5c4c8ad9f265da6179752b03(JVM如何进行指针压缩)