Java 32位与64位优化模式（-XX:-UseCompressedOops）内存开销

当我在配置为使用超过32GB内存的JVM中运行Java应用程序时，我试图预测堆内存需求的变化

我希望在将Xmx参数从32GB重新配置到64GB之后，内存中保留的“有用”对象数量相同，内存开销也会很大

我试图通过在本地机器上应用

-XX:-UserCompressedOps

来模拟和估计差异，但还不能得出结论。 根据运行时计算，我的对象在这两种情况下占用的内存量相同。使用的带有关闭优化功能的堆往往要多一点，但决不会比我在阅读一些解释时预期的多出一倍

在我的用例中，我只是在程序的整个生命周期中，将大量相对较大的POJO对象（每个对象100-1K）保存在堆中

是否有一个经验法则来说明内存需求如何通过超过32GB限制而增长（当32bit优化不再适用时）

但是，我读到的解释决不会比预期的多出一倍

我的理解是，禁用CompressedOops只会使指针大小（引用类型）增加一倍，而不会使基元类型增加一倍，尤其是字符串、字节数组等。 因此，如果堆由基元类型的数组控制，那么增加可能很难注意到

---

对齐要求也会使大小差异变得不直接，因为较大的指针可能只会填充一些对齐填充。

所以问题是，当您关闭CompressedOops时会发生什么？或者，当您只使用这一个参数set/unset进行I-only测试时，JVM是否还应用了任何其他优化，其余都是Deafolt HotSpot 1.7参数。我还试图比较只有最大堆从小于32GB增加到大于32GB的情况。据说（）丢失CompresseDoop意味着堆大小在32GB和48GB之间是没有意义的。你需要超过48GB来弥补更长的指针。另一个线程（）提到了一个有趣的新Java 8选项（-XX:ObjectAlignmentInBytes），它允许你以16字节而不是8字节对齐对象，这样你就可以使用高达64GB（而不仅仅是32GB）的压缩doop。谢谢@Thilo！我听说过32-48GB的争论。这实际上是让我害怕的，尽管我还不能重现负面影响。这个答案总结了这一点。甲骨文详细信息：没错，但这不是估算的经验法则。我在考虑使用jmap，计算对象的数量并从中得出数字。这只会给出下限，因为每个对象都必须被引用一次/至少作为一个指针本身。另一方面，如果堆仅由引用数组组成，则会看到堆几乎完全加倍。