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

Question

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

在网上搜索解释之后，我开始怀疑它是否与我使用32位JVM这一事实有关（这个服务器上没有任何java进程需要非常多的内存）。

我认为默认的最大内存池是64MB，而我正在运行接近64个这样的进程。所以这就是4GB全部告诉...在32位限制。但我不明白为什么或如何将这些过程中的任何一个受到其他过程的影响。如果我是对的，那么为了运行更多这些进程，我要么必须将最大堆调整为低于默认值，要么切换到使用64位JVM（这可能意味着提高最大堆）高于这些过程的默认值）。我不反对其中任何一个，但我不想浪费时间，现在仍然是在黑暗中拍摄。

任何人都可以解释为什么它可能会这样工作吗？还是我完全弄错了？

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

编辑：我完全错了。下面的答案证实了我的直觉，我没有理由不能运行尽可能多的JVM。不久之后，我在尝试运行非java进程的同一台服务器上遇到错误：“fork：没有足够的空间”。所以我遇到的其他限制不是特定于java的。我必须弄清楚它是什么（不，它不是交换空间）。我很可能会去服务器故障。

Answer 1

  

我相信默认的最大内存池   是64MB，我的运行接近64   这些过程。那就是   4GB全部告诉......正好在32位   限制。

没有。 32位限制是每个进程（至少在64位操作系统上）。但是default maximum heap is not fixed at 64MB：

  

初始堆大小：大于1/64   机器上的物理内存   机器或一些合理的最低限度。

     

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

     

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

Answer 2

我怀疑内存是碎片化的。另请检查Tools to view/solve Windows XP memory fragmentation以确认内存碎片可能导致此类错误。