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位操作系統上）。 但默認的最大堆不固定為64MB ：

初始堆大小：機器上物理內存的1/64或者合理的最小值。

最大堆大小：物理內存的1/4或1GB的較小值。

注意：為堆大小指定的邊界和分數對於J2SE 5.0是正確的。 隨着計算機變得越來越強大，它們在后續版本中可能會有所不同。

Answer 2

我懷疑內存是碎片化的。 還可以查看工具以查看/解決Windows XP內存碎片 ，以確認內存碎片可能導致此類錯誤。