java - 32 位 JVM 提交 >3G 虚拟内存

Question

我们有一个在 64 位 RHEL5 下运行的 32 位 JVM，在一个有足够内存 (32G) 的盒子上。由于不同的原因，这个过程需要相当大的托管堆和 permgen 空间——目前，它使用以下 VM 参数运行:

-Xmx2200M -XX:MaxPermSize=128M -XX:+CMSClassUnloadingEnabled

我最近开始看到 JVM 崩溃，因为它 - 看似 - 耗尽了 native 内存(它无法创建 native 线程，或者无法分配 native 内存等)。这些崩溃与托管堆的状态没有(直接)相关，因为当这些崩溃发生时，托管堆已满 50-70%。 我知道为托管进程保留的内存接近 2.5 G，这为 JVM 本身留下的内存不超过 0.5G，但是 - 我不明白为什么 0.5 对 JVM 来说还不够，即使不断进行 GC - 真正的问题是:当我使用 jconsole 连接到进程时，它会说(当前)

Committed virtual memory: 
3,211,180 kbytes

这比3G还多。我可以想象，出于某种原因，JVM 认为它有 3,211,180 kbytes (3.06G) 的内存是，但是当它试图超过 3G 时，内存分配失败。

任何想法 a) 为什么会这样 b) 如何避免这种情况

谢谢。 配合

Answer 1

典型 VM 中有很多开销未计入 VM 会计，因为它基本上被进程的 native 元素窃取了 - 例如用于为系统库执行 native 级代码的 .so 文件中的映射不计入基本 VM 记账。您的典型共享库映射到内存的顶部 GB，因此如果您尝试将内存分配到该区域，您将被拒绝，因为它会溢出共享库的内存区域 - 大多数操作系统上的内存分配由当您要求更多内存时会出现简单的栏。当您请求内存并且 bar 与其他用途发生冲突时，它就会失败。下面的大部分细节都是关于此的。

您需要避免在 32 位进程中需要如此多的内存。这是根本性的挑战。获得一个 64 位 VM 是微不足道的，它将允许您使用比其他方式可访问的内存更多的内存 - 它只是在这种情况下可用。

如果您使用的是32位进程，很有可能遇到32位进程的有效地址空间限制。对于 Windows，这最大约为 3GB - 超过此空间的任何空间都将保留给 I/O 空间和内核。您可以移动它，但它有可能破坏为 32 位操作系统设计的应用程序/驱动程序。

对于 Linux，每个进程最终有大约 3GB 的可用可寻址 RAM，其余部分被内核等使用并映射到共享库中。该限制称为“地址空间限制”，我认为可以对其进行调整。

如何避免？好吧，在大多数情况下，您不能这样做，这是 32 位地址空间的物理限制，以及内核/IO 与 32 位操作系统进程位于同一地址空间的需要。

对于 64 位操作系统，您可以使用(大部分)所有 64 位地址空间，这远远超过您需要使用的空间。