Java 拒绝启动-无法为对象堆保留足够的空间

问题描述：

背景

我们拥有大约 20 个 Linux 刀片池。一些运行 Suse，一些运行 Redhat。所有共享 NAS 空间包含以下 3 个文件夹：

• /NAS/app/java - 指向 Java JDK 安装的符号链接。当前版本为 1.5.0_10

• /NAS/app/lib-指向我们应用程序版本的符号链接。

• /NAS/data - 写入输出的目录

我们所有的机器都有 2 个处理器（超线程），4GB 物理内存和 4GB 交换空间。我们将每台机器在给定时间内可以处理的“作业”数量限制为 6 个（这个数字可能需要更改，但这与当前问题无关，因此请暂时忽略它）。

我们的一些作业将最大堆大小设置为 512mb，其他一些作业将最大堆大小保留为 2048mb。同样，我们意识到，如果在同一台机器上启动 6 个作业并将堆大小设置为 2048，我们可能会超出可用内存，但据我们所知，这种情况尚未发生。

问题

有时，作业会立即失败，并显示以下消息：

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

我们过去常常将此归咎于在同一台机器上同时运行了太多作业。问题很少发生（可能一个月一次），我们只需重新启动它，一切就会正常。

这个问题最近变得更加严重。我们所有请求最大堆大小为 2048m 的作业几乎每次都会立即失败，并且需要重新启动几次才能完成。

我们已经尝试使用各个机器并手动执行它们，结果相同。

调试

事实证明，该问题只存在于我们的 SuSE 机器上。该问题之所以发生得更频繁，是因为我们一直在添加更多机器，而新机器都是 SuSE。

SuSE 机器上的‘cat /proc/version’给出：

Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005

RedHat 机器上执行‘cat /proc/version’得到的结果为：

Linux version 2.4.21-32.0.1.ELsmp (bhcompile@bugs.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52)) #1 SMP Tue May 17 17:52:23 EDT 2005

'uname -a' 在两种类型的机器上都给出以下信息：

UTC 2005 i686 i686 i386 GNU/Linux

机器上没有正在运行的作业，也没有其他进程占用大量内存。当前正在运行的所有进程可能总共使用 100mb。

‘top’ 当前显示以下内容：

Mem:   4146528k total,  3536360k used,   610168k free,   132136k buffers
Swap:  4194288k total,        0k used,  4194288k free,  3283908k cached

'vmstat' 当前显示以下内容：

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
0  0      0 610292 132136 3283908    0    0     0     2   26    15  0  0 100  0

如果我们使用以下命令行启动一项作业（最大堆容量为 1850mb），那么它会正常启动：

java/bin/java -Xmx1850M -cp helloworld.jar HelloWorld
Hello World

如果我们将最大堆大小增加到 1875mb，则会失败：

java/bin/java -Xmx1875M -cp helloworld.jar HelloWorld
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

很明显，当前使用的内存用于缓冲/缓存，这就是为什么显示为“可用”的内存如此之少。不清楚的是，为什么会有神奇的 1850mb 线，任何更高的值都意味着 Java 无法启动。

如能得到任何解释我将非常感激。

解决方案 1：

您使用的是 32 位操作系统，因此您将看到总大小受到限制。其他答案对此进行了更详细的介绍，因此我将避免重复他们的信息。

我最近注意到我们的服务器的一个行为是，使用 指定最大堆大小-Xmx而不使用 指定最小堆大小-Xms会导致 Java 的服务器 VM 立即尝试分配最大堆大小所需的所有内存。当然，如果应用程序达到该堆大小，那么这就是您需要的内存量。但很有可能，您的应用程序一开始的堆比较小，以后可能需要更大的堆。此外，指定最小堆大小将允许您从较小的堆开始启动应用程序，然后逐渐增加该堆。

所有这些都不会帮助您增加最大堆大小，但我认为它可能会有所帮助，所以......

解决方案 2：

正如其他回复所建议的那样，该问题是由于虚拟地址空间耗尽而引起的。 32 位 Linux 用户空间程序通常限制为 3GB 的 AS；其余 1GB 由内核使用（理由：由于前 1GB 是内核固定映射，因此在提供系统调用时无需触及页表）。

然而，RHEL 内核实现了所谓的 4GB/4GB 分割，其中完整的 4GB AS 可供用户空间进程使用，但需要付出轻微的运行时开销（内核位于单独的 4GB 虚拟 AS 中）

解决方案 3：

运行 32 位操作系统是一个错误；您绝对应该尽早升级。

我不知道 Java 是否要求其堆位于单个连续块中，但如果是，那么在 32 位机器上要求 1.8G 的堆听起来要求太高了。您假设在 JVM 启动时有一大块地址空间（几乎一半）是空闲的。

根据当时加载的其他库，可能没有。库可以在任何它们喜欢的地方分配内存，因此它可能会将您的地址空间分割得足够多，以至于 1.8G 无法在一个块中可用。

无论如何，Linux 32 位上最多只有 3G 的地址空间可用。库和 JVM 本身会使用一些地址空间。

解决方案 4：

对于 32 位服务器，似乎存在无法克服的 JVM 限制（除非找到不施加 2GB 或更少限制的特殊 32 位 JVM）。

服务器端的这个主题有更多详细信息，其中包括几个人在 32 位架构上测试了各种 JVM。IBM 的 JVM 似乎允许多 100 MB，但这并不能真正满足您的需求。

http://www.theserverside.com/discussions/thread.tss?thread_id=26347

“真正的”解决方案是使用带有 64 位 JVM 的 64 位服务器来获得每个进程大于 2GB 的堆。但是，还必须考虑使用 64 位 JVM 增加地址大小（而不仅仅是可寻址空间）的影响。使用少于 4GB 的内存进行处理可能会对性能和内存产生影响。

值得深思的是：这些作业中的每一个真的都需要 2GB 内存吗？有没有办法修改作业以在 1.8GB 内运行，这样这个限制就不成问题了？

解决方案 5：

ulimit 最大内存大小和虚拟内存设置为无限制？

解决方案 6：

我编写了两个应用程序，一个中等大小，另一个相当小。我会启动中等大小的应用程序（在 Linux、Centos 上），没有任何参数（Java 服务器），它会运行得很好。但是当我用“Java 客户端”启动较小的应用程序时，它会告诉我它无法保留足够的空间，无法运行。我进行了实验，并使用了 -Xms 和 -Xmx 以及 10m，它们都可以毫无问题地运行……想想吧！

解决方案 7：

这可能有点离题，但我想到了两件事。以下两件事都假设您正在运行 32 位版本的 Linux。

Linux 上有进程大小限制，我记得 CentOS 上是 2.5gb 左右，是在内核中配置的（即重新完成更改）。一旦将所有 JVM 代码 + Permgen 空间和所有其余 JVM 库加起来，您的进程可能会达到该限制。

第二件事是我遇到的，你可能用完了地址空间，听起来很奇怪。在使用 1.5Gb 堆运行 Glassfish 时遇到问题，当它尝试编译 JSP 时，我的分叉 javac 会失败，因为即使盒子中有 12gb 内存，操作系统也无法为新创建的进程分配足够的地址空间。这里可能发生了类似的事情。

恐怕上述两个问题的唯一解决方案是升级到 64 位内核。

希望这有用。

解决方案 8：

您需要考虑升级您的操作系统和 Java。Java 5.0 已停止使用，但如果您无法更新到 Java 6，则可以使用最新的补丁级别 22！

32 位 Windows 限制为 ~ 1.3 GB，因此最好将最大值设置为 1.8。注意：这是连续内存的问题，并且随着系统运行，其内存空间可能会变得碎片化，因此您遇到此问题并不令我感到惊讶。

64 位操作系统不存在这个问题，因为它具有更多的虚拟空间，您甚至不必升级到 64 位版本的 Java 即可利用这一点。

顺便说一句，根据我的经验，32 位 Java 5.0 比 64 位 Java 5.0 更快。直到多年后，Java 6 update 10 才在 64 位上更快。

解决方案 9：

我将一台机器的内存从 2GB 升级到了 4GB，然后马上就出现了错误：

$ java -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

问题出在 ulimit 上，我已将可寻址空间设置为 1GB。将其增加到 2GB 即可解决问题。

-Xms 和 -Xmx 没有效果。

看起来 java 试图按可用内存比例获取内存，如果不能则失败。

解决方案 10：

要执行的步骤....以解决 VM 初始化期间发生的错误无法为对象堆保留足够的空间无法创建 Java 虚拟机。

步骤 1：减少之前使用的内存。java -Xms128m -Xmx512m -cp simple.jar

步骤 2：从主板上取下 RAM 一段时间并插入并重新启动 * 它可能会释放阻塞堆区域内存.. java -Xms512m -Xmx1024m -cp simple.jar

希望它现在能运行良好...:-)

解决方案 11：

我最近遇到了这个问题。我有 3 个 Java 应用程序，它们的堆大小为 1024m 或 1280m。Java 正在查看交换中的可用空间，如果没有足够的可用内存，jvm 就会退出。

为了解决这个问题，我不得不结束几个分配了大量虚拟内存的程序。

我在带有 64 位 jvm 的 x86-64 Linux 上运行。

解决方案 12：

使用的 JVM 是什么？我知道 BEA JRockit 的最大堆大小不超过 1850mB。它不会失败，但会警告用户它不会使用超过 1850mB 的大小。

我不知道为什么会有这样的限制，但我知道 BEA JRockit 有这样的限制。

此致。

解决方案 13：

鉴于其他建议均不起作用（包括我自己建议的许多方法），为了进一步排除故障，您可以尝试运行：

sysctl -a

在 SuSE 和 RedHat 机器上查看是否有任何差异？我猜这两个发行版之间的默认配置不同，导致了这种情况。

解决方案 14：

我正在使用 SOA 环境，将 Xmx 从 1024 减少到 768setSOADomainENV.cmd解决了该问题。

REM set DEFAULT_MEM_ARGS=-Xms512m -Xmx1024m
set DEFAULT_MEM_ARGS=-Xms512m -Xmx768m

解决方案 15：

在 Windows 中，我通过直接编辑文件 /bin/cassandra.bat 解决了这个问题，更改了“Xms”和“Xmx”JVM_OPTS 参数的值。您可以尝试编辑 /bin/cassandra 文件。在此文件中，我看到一个注释变量 JVM_OPTS，请尝试取消注释并编辑它。