64位操作系统上的32位Java：JVM的数量有限制吗？

我有一个Solaris sparc（64位）服务器，它有16 GB的内存。有很多小Java进程在它上面运行，但今天我在尝试启动一个新进程时遇到了“无法为对象堆保留足够的空间”错误。我很惊讶，因为服务器上仍然有超过4GB的空闲空间。新流程能够在其他一些流程关闭后成功启动；这个系统肯定达到了某种极限

在网上搜索解释之后，我开始怀疑这是否与我使用32位JVM（此服务器上的java进程都不需要太多内存）有关

我相信默认的最大内存池是64MB，我运行的进程接近64个。所以总共是4GB。。。正好是32位限制。但我不明白这些过程中的任何一个为什么或如何会受到其他过程的影响。如果我是对的，那么为了运行更多这些进程，我要么将max heap调整为低于默认值，要么切换到使用64位JVM（这可能意味着将max heap提高到高于这些进程的默认值）。我不反对这两种方法，但我不想浪费时间，现在这仍然是一个不确定因素

有人能解释为什么会这样吗？还是我完全错了

如果我的解释是对的，那么可能有关于这个的文档：我非常想找到它。（如果有必要的话，我正在运行Sun的JDK 6更新17。）

---

编辑：我完全错了。下面的答案证实了我的直觉，即我没有理由不能运行尽可能多的JVM。过了一会儿，我在试图运行非java进程的同一台服务器上遇到了一个错误：“fork:没有足够的空间”。因此，我遇到的另一个限制不是java特有的。我必须弄清楚它是什么（不，它不是交换空间）。很可能是服务器故障。

我怀疑内存有碎片。还要检查内存碎片是否会导致此类错误

我相信默认的最大内存池 是64MB，而我的运行速度接近64 这些过程的一部分。那就是 总共4GB。。。就在32位 限制

不可以。32位限制是每个进程（至少在64位操作系统上）。但是：

初始堆大小：1/64的较大值 计算机上的物理内存 机器或一些合理的最小值

最大堆大小：小于1/4 物理内存或1GB

注意：堆大小的边界和分数对于J2SE 5.0是正确的。随着计算机功能的增强，它们在后续版本中可能会有所不同

---

啊，是的，谢谢你，我在回忆1.4的旧限额。是的，我知道限制是每个进程，但我抓住了救命稻草。对不起，在这个问题上，我没有看到任何东西可以证实内存碎片会导致这个问题。实际上，这似乎表明内存只需要在JVM本身的地址空间内是连续的。。。如果我错了，而你是对的，你知道我将如何证实这一点吗？