转向64位JVM的经验分享

Question

转向64位JVM的经验分享

java64-bitjvm

5

我们公司计划使用64位JVM以避免2GB最大堆大小限制。我在谷歌上搜索了关于64位JVM性能的结果却参差不齐。有没有人尝试过使用64位java并分享你的经验呢？

- Fazal

x64还是非x64？大多数情况下，它只会增加内存使用量和内存带宽。对于x86，AMD创建了一个比x86不那么疯狂的指令集。 - Tom Hawtin - tackline

1

@Anders，不是每个人都像你那样着迷于这些数字！ :P 有些人（你能想象吗？）只是为了帮助而回答。 - Vladimir Dyuzhev

2

@Vladimir Dyuzhev：沉迷并不是问题。这是社区的工作方式。回答和接受是确定谁有良好回答历史记录的方式。没有接受意味着没有良好回答历史记录。没有良好回答历史记录，很难知道要对答案放多少信任。 - S.Lott

1

@Vladimir，stackoverflow最好的工作方式是原帖发布者指出哪个答案对他/她来说是最好的。 - Thorbjørn Ravn Andersen

抱歉各位..我同意这可能是我的错误。我从答案中学到了东西，但忘记接受它们了..从现在开始会注意的。 - Fazal

@Fazal：你现在可以对你的所有7个问题进行过去式的修改。 - S.Lott

5个回答

3

我们使用这个工具是没有问题的。为什么不试着设置它，并在像jvisualvm这样的分析器下运行您的负载测试套件呢？

- Thorbjørn Ravn Andersen

3

如果您需要更大的堆，那么性能问题就不太重要了，对吗？或者你有一个水平扩展的计划吗？

我听说64位应用程序的主要问题是完整的垃圾回收可能需要很长时间（因为它基于活动对象的数量）。因此，您需要仔细调整GC参数以避免进行完整的回收（我听说过一家公司拥有64 GB的堆，并调整了他们的GC，使他们从不进行完整的GC; 他们每周只关闭一次）。

除此之外，请认识到Java是32位的设计，因此您不太可能从一次性移动64位的数据中看到任何巨大的性能提升。而且您仍然受到32位数组索引的限制。

- Anon

我们有一个JVM，其中gc并行运行得很好，但是如果下一个gc计划开始时上一个gc还没有完成，JVM会停止运行直到第二个gc完成。这很糟糕！由于操作系统非常积极地将内存交换出去，这种情况经常发生。 - Thorbjørn Ravn Andersen

你能解释一下Java是32位设计的意思吗？据我所知，Java的设计是跨平台的，不是吗？ - Pacerier

关于设计为32位的评论有些奇怪。当我们讨论32/64/128位时，通常是关于指针的大小，这会影响工作内存的大小。Java使用int来限制单个数组的大小，但像nio缓冲区这样的抽象可以用来有效地解决这个问题。由于这并不完美，因此计划允许索引为long。然而，这不是像4Gb最大堆一样的技术限制。 - Peter Kriens

1

我们已经直接编写了64位代码，我没有看到任何不良行为...

- Yaneeve

1

根据我的经验，将32位JVM工作负载直接放到64位上会导致性能和空间损失。

然而，大多数主要的JVM供应商现在已经实现了一种称为压缩引用或压缩oops的良好技术，可以在64位JVM中压缩部分堆内存，前提是它们不是“大型”的（即：在4-30GB范围内）。

这会产生很大的影响，并且应该使得从32位到64位的转换影响更小。

IBM JVM的参考资料：链接文本

- Trent Gray-Donald

我认为这是 Oracle JVM 的 -XX:+UseCompressedOops 选项。 - Karussell

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- jayshao · Accepted Answer

简而言之：64位JVM将会为对象引用和其他一些类型（通常不重要）消耗更多的内存，每个线程将会消耗更多的内存（在高并发站点上通常很重要），并且使您能够拥有更大的堆（通常只有在您拥有许多长寿命对象时才重要）。

更长的回答/评论：

- Java是32位或64位，但VM规范确保大多数字段（例如int、long、double等）都是相同的。因此，说Java是32位的设计是误导性的。 - 此外，在GC调优方面的评论可能与对象数量无关。虽然过去人们花费了大量精力来调整参数，但现代的（Java 5+）JVM非常擅长自我调整，除非您拥有大量数据，否则您更有可能通过激进的JVM调整来伤害自己。 - 如上所述，在x86架构中，64位EMT64或x64处理器还包括执行原子写入或其他选项的新指令，这也可能影响高性能应用程序。