文章来源：https://dwz.cn/7YcSeVQk

作者：占小狼

看ES官方文档时，提到的一个观点：

Don’t Cross 32 GB！

因为当JVM堆少于32G时，HotSpot虚拟机会启用一个压缩对象指针，而如果超过32G，这个压缩对象指针就会失效。

那么，纠结这个临界值的精确值是多大呢？

开启压缩指针相比没有开启，能节省多少内存呢？

让我们一探究竟！

不要超过32 GB!

在Java的世界里，绝大部分对象分配在堆里，并且被一个指针引用（Student stu = new Student()，new的这个Student对象就是分配在堆里，stu就是持有这个对象的引用）。

32位的操作系统，最大只支持4G内存（即2^32）。当然，对于当下来说，32位服务器应该是绝种了，所以本文讨论的是64位操作系统。对于64位操作系统来说，理论上分配的堆可以非常非常大。但是，64位指针的开销就意味着有更多的浪费空间，这仅仅是因为指针更大。比浪费空间更糟糕的是，64位指针在主内存和多级缓存之间移动数据的时候，还会消费更多的带宽。

Java用"compressed oops"术解决了这个问题，指针不再是指向内存中精确位置，而是对象的偏移量（原文：Instead of pointing at exact byte locations in memory, the pointers reference object offsets）。这就意味着，32位指针能引用2^32个对象（大约43亿个对象），而不是引用总计2^32个字节大小对象。基本上，堆大小直到32G左右还能保持32位指针。

一旦你越过这个32G--一个具有魔法般的数值。指针将切回到普通的对象指针。每个指针变大，意味着需要更多的CPU，内存和带宽，真正用来保持对象的内存就会更少。这就可能导致一种奇怪的现象，使用compressed oops的32G的堆和40~50G没有使用compressed oops的堆保存的对象数量是一样的。

这个事实告诉我们：即使你有多余的内存，也应该尽量避免超过32G这个界限。它会浪费内存，降低CPU性能，并且大堆情况下GC表现也一般般。更麻烦的是，那么大的堆，DUMP分析将是一件极其痛苦，极其麻烦的事情。相信我，你一定不想碰到那种局面。

应该设置多大？

32G是个近似值，这个临界值跟JVM和平台有关。如果不想精确设置的话，31G是个决定安全的数值，31G肯定默认开启compressed oops。我们可以通过增加JVM参数-XX:+PrintFlagsFinal，验证UseCompressedOops的值，从而得知，到底是不是真的开启了压缩指针，还是压缩指针失效！

实践才是检验真理的唯一标准！JUST DO IT！让我们动手验证这个临界值吧！

验证情况--JDK8前提下，32760m的堆是开启压缩指针的，32770m的堆压缩指针已经关闭：

32G，即32*1024=32768M，刚好在范围[32760, 32770]中。

土豪我有1T内存

JVM大堆的缺点太多了；

超过32G压缩指针失效；

DUMP分析将是灾难；

堆越大，GC表现越差；

总之，不要尝试吃这个螃蟹！那如果我是在一家有钱任性的公司，服务器牛逼的不要不要的，都是128G起步！毕竟不要让贫穷限制了想象！

这种情况下，我有小建议：开多个32G的JVM实例。4个32G的JVM实例绝对比1个128G实例表现要好。

简单测试验证

笔者做了一个简单测试，（测试源码请看原文）验证一下这个问题：分配设置Xmx为Xmx32760m和Xmx32770m，Xmn都是100M（S0:S1:Eden默认1:1:8）。总结分配一个包含8个对象类型和8个原子类型以及String，总计17个类型属性的对象1kw次。看它们分别触发了多少YGC，结论如下表所示：

由执行结果可知，Young区完全一样的情况下，开启压缩指针相比关闭压缩指针，能节省20%多的内存。由此可知，32G还真是一个奇妙的魔法数值！另外需要说明的是YGC次数有小数，是表示Eden区占用比例，比如17.52次YGC表示发生了17次YGC别切Eden还占了52%。

执行的命令：

说明：

-Xmx32760m -Xms32760m即表示开启压缩指针；

-Xmx32770m -Xms32770m即表示关闭压缩指针。