迁移到 64 位 JVM 的经验答案

【问题标题】：Experience of moving to 64 bit JVM迁移到 64 位 JVM 的经验
【发布时间】：2010-03-31 14:39:33
【问题描述】：

我们公司正计划迁移到 64 位 JVM 以摆脱 2 GB 的最大堆大小限制。谷歌给了我关于 64 位 JVM 性能的非常复杂的结果。有没有人尝试过迁移到 64 位 java 并分享您的经验

【问题讨论】：

x64 还是非 x64？在大多数情况下，它只会增加内存使用量，从而增加内存带宽。对于 x86，AMD 创建的指令集不如 x86 疯狂。
@Anders，并不是每个人都像你一样痴迷于这些数字！ :P 有些人（你能想象吗？）回答只是为了提供帮助。
@Vladimir Dyuzhev：痴迷不是问题。这是社区的运作方式。回答和接受是一个人如何确定谁有好的答案历史。不接受意味着没有好的答案历史。如果没有良好答案的历史，就很难知道对答案的信任程度。
@Vladimir，如果原始发帖人指出哪个答案最适合他/她，stackoverflow 效果最好。
对不起，伙计们。我同意这可能是错误的。我从答案中学习，但忘记接受它们。从现在开始会这样做。

【解决方案1】：

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

更长的答案/评论：

Java是32位的注释设计具有误导性。爪哇内存寻址是 32，或者 64 位，但 VM 规范确保大多数字段（例如 int、long、double、等等）无论如何都是一样的。
另外 - GC 调整 cmets 而与对象的数量有关，可以不相关，GC可以快速启动具有大堆的 JVM（我工作过堆高达 15GB，非常快速GC） - 它更多地取决于如何你和一代人一起玩收集器计划，以及您的对象使用模式是。而在过去的人们花费了大量的精力调参，工作量很大依赖的和现代的（Java 5+）JVM 非常擅长自我调整——除非你有很多数据你更多可能会伤害自己而不是帮助通过积极的 JVM 调优。
正如在 x86 架构中提到的， 64 位 EMT64 或 x64 处理器还包括新的说明做原子写入之类的事情，或者其他可能也会影响的选项高性能应用程序。

【讨论】：

【解决方案2】：

如果您需要更大的堆，那么性能问题就没有实际意义了，不是吗？或者你有横向扩展的计划吗？

我听说 64 位应用程序的主要问题是完整的垃圾收集可能需要很长时间（因为它基于活动对象的数量）。因此，您需要仔细调整 GC 参数以避免完全收集（我听说过一个关于一家拥有 64 Gb 堆的公司的轶事，并调整了他们的 GC，以便他们永远不会使用完整的 GC；他们只是简单地关闭了每周下降一次）。

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

【讨论】：

我们有一个 JVM，其中 gc 并行运行，运行良好，但如果在下一次 gc 启动时 gc 未完成，则 JVM 会暂停，直到第二次 gc 完成。坏的！由于操作系统非常积极地换出内存，因此会发生一些情况。
您能解释一下 Java 设计为 32 位是什么意思吗？据我所知，Java 在设计上是独立于平台的吗？
关于 32 位设计的评论很奇怪。当我们讨论 32/64/128 位时，它通常大约是指针的大小，这会影响工作内存的大小。 Java 将整数用于数组这一事实限制了单个数组的大小，但可以使用像 nio 缓冲区这样的抽象来有效地解决这个问题。由于这并不完美，因此有计划允许索引为多头。但是，这不是技术方面的限制，例如 4Gb 的最大堆。

【解决方案3】：

对我们来说很好。为什么不简单地尝试设置它并在 jvisualvm 之类的分析器下运行负载测试套件？

【讨论】：

【解决方案4】：

我们已直接写入 64 位，我看不到任何不良行为...

【讨论】：

【解决方案5】：

根据我的经验，天真地采用 32 位 JVM 工作负载并将它们置于 64 位上会产生性能和空间损失。

然而，大多数主要的 JVM 供应商现在已经实现了一种很好的技术，它基本上压缩了一些堆 - 它被称为压缩引用或压缩 oop，用于 64 位 JVM，它们并不“大”（即：在 4- 30GB 范围）。

这有很大的不同，应该使 32->64 过渡的影响要小得多。

IBM JVM 参考：link text

【讨论】：