这个问题与Java Refuses To Start - could Not Resrve Enough Space for Object Heap 有关，应该很容易弄清楚。然而; 我的搜索没有产生任何有用的东西。
本质上，我们在具有相同硬件的不同机器上拥有 2 个 32 位操作系统（RedHat 和 SuSE）。两者都使用相同的 JVM，都执行相同的命令行。RedHat 运行良好，但 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
'uname -a' 在两种类型的机器上都为我们提供了以下信息：
UTC 2005 i686 i686 i386 GNU/Linux
JVM 内存限制与可用的最大空闲连续块相关，而不是空闲内存量。该限制从大约 1.4 GB 到略高于 2.0 GB 不等，具体取决于您的操作系统将各种内容放在内存中的位置。我不知道 Redhat 或 Suse 将内容加载到内存中的细节，但可能是 suse 将某个库映射到 RAM 中间的地址，Redhat 可能会在最后映射它（推测）。
请记住，您在 java 中的实际内存使用量超过了您为 Xmx 指定的内存使用量。其他内存设置也会影响堆的大小（如 permgen）。所以也可能是 Suse 上的 perm 空间的默认值比 Redhat 上的大。
此外，根据应用程序的内存分配配置文件，您可能会使用更小的堆大小和不同的垃圾收集选项。这里有一些细节（http://java.sun.com/performance/reference/whitepapers/tuning.html）和其他地方。例如，如果你分配了很多小的临时块，你需要不同的 GC 设置，而不是你有很多位长寿命的对象。
关于链接的问题，为什么不直接使用 Redhat？这可能是一个简单的解决方案，但我保证它会比深入研究 Java 调优和操作系统内存管理的神秘世界更快地解决您的问题：P
首先，当你有这么大的地址空间压力时，你会疯狂地运行一个 32 位操作系统。在 64 位 Linux 上迁移到 64 位 JVM。您已经浪费了多少时间试图诊断这个问题，您从一开始就怀疑这个问题会随着 64 位系统的更大地址空间而消失？
其次，众所周知，在所有 Linux 供应商中，Red Hat 拥有最多的内核工程师，并对其 RHEL 产品中的内核进行了一些认真的调整。这些通常包括针对像您这样的大型工作负载的补丁（嗯，对于 32 位系统来说，这是一个很大的工作负载，在 64 位上没什么特别的）。因此，最终的原因可能是 RHEL 有其他客户在做与您一样疯狂的事情，而您从他们为支持这些客户所做的工作中受益。
最后，由于我怀疑您会坚持尝试在 32 位 SuSE 上找到一种方法，我将指出 Linux 在 32 位 x86 上提供了各种地址空间权衡，这是可能的（但不确定）您的 SuSE 系统只是选择了不同的权衡。如果您可以调出正在运行的内核的配置（通常在 /boot/config....），那么您可以比较诸如 HIGHMEM 之类的设置。
直到几年前的传统选项是 2:2 拆分，即用户空间被限制为 2GiB 的地址空间，这是一个简单的编程解决方案，它具有不错的效率，但在这种情况下显然你不能拥有你请求的堆，因为它不会为程序文本、堆栈等留下任何空间。最近的趋势是 3:1（类似于 Windows /3GB 切换），它以将操作系统内核本身塞进更少空间的代价来扩展用户空间地址空间，这可能导致自己的问题。这可能有效，但会非常拥挤，所以如果它不适合你的工作，我也不会感到惊讶。最后，较新的 Linux 内核还提供了一个选项，您可以获得 4GiB 32 位用户空间，这可能足以让您的作业可靠地运行，
要尝试这个，您需要一个新内核。您可以只安装 SuSE 提供的一个（看看他们是否提供其他可供选择的选项，例如“PAE”选项），或者您可能必须自己编译，在这种情况下，它可能会使您的支持合同无效。
但实际上，您应该选择选项 1，切换到 64 位 JVM 并站稳脚跟。