Java 迁移到64位JVM的经验

我们公司计划迁移到64位JVM，以摆脱2GB最大堆大小限制。谷歌给了我关于64位JVM性能的非常复杂的结果。

---

是否有人尝试使用64位java并分享您的经验

我们直接使用64位编写，我看不到任何不良行为…

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

如果需要更大的堆，那么性能问题就相当没有意义了，不是吗？或者你有水平缩放的计划吗

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

---

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

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

更长的答案/评论：

• Java是32位的注释 设计具有误导性 内存寻址为32，或 64位，但VM规范确保 大多数字段（例如int、long、double、， 等）都是一样的

• 另外-GC调优注释 与对象数量相关，可以 不相关，GC可以快速启动 具有大堆的JVM（我曾经工作过 堆高达15GB，具有非常高的可用性 快速GC）-这更多地取决于如何 你玩弄这一代人 收藏家计划，你的计划是什么 对象使用模式为 过去的人们花费了很多精力 调整参数，工作量很大 依赖和现代（Java5+）JVM 非常擅长自调整-除非 你有很多数据，你更 可能会伤害你自己而不是帮助你 使用积极的JVM调优

• 如x86体系结构所述， 64位EMT64或x64处理器 此外，还包括以下方面的新说明： 做一些事情，比如原子写，或者 其他可能也会产生影响的选择 高性能应用程序

---

根据我的经验，天真地接受32位JVM工作负载并将其置于64位会对性能和空间产生影响

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

这会产生很大的不同，并且应该使32->64转换的影响小得多

---

IBM JVM参考：

x64或非x64？在大多数情况下，它只会增加内存使用量，从而增加内存带宽。对于x86，AMD创建的指令集没有x86那么疯狂。@Anders，并不是每个人都像你一样痴迷于这些数字！：p有些人（你能想象吗？）回答只是为了帮助。@Vladimir Dyuzhev:问题不在痴迷。这是社区的工作方式。回答和接受是一个人如何决定谁有好答案的历史。不接受意味着没有好答案的历史。没有好答案的历史，很难知道对答案有多大的信任。@Vladimir，stackoverflow如果原始海报指出哪个答案最适合他/她。对不起，伙计们。我同意这可能是错误的。我从答案中学到了东西，但忘记了接受它们。从现在开始，我会这样做。我们有一个JVM，gc并行运行，运行得很好，但是如果在下一个gc启动时没有完成gc，JVM会停止，直到第二个gc完成。糟糕！发生了一点，因为操作系统在交换内存方面非常激进。你能解释一下你所说的Java设计为32位是什么意思吗？据我所知，Java设计独立于平台吗？不是吗？关于设计为32位的评论很奇怪。当我们讨论32/64/128位时，通常是关于指针的大小，这会影响工作的大小内存。事实上，Java对数组使用INT限制了单个数组的大小，但是可以使用nio缓冲区之类的抽象来有效地解决这个问题。因为这并不完美，所以有计划允许索引为长。但是，这在技术上并不是像4Gb的最大堆那样的限制。我认为这是-XX:+UseCompressDoops对于oracle JVM，您能解释一下“字段（如int、long、double等）是什么意思吗？”？