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

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

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

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

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

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

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

解决方法:

I believe the default max memory pool
is 64MB, and I was running close to 64
of these processes. So that would be
4GB all told … right at the 32-bit
limit.

不是.每个进程的32位限制(至少在64位操作系统上).但是default maximum heap is not fixed at 64MB：

initial heap size: Larger of 1/64th of
the machine’s physical memory on the
machine or some reasonable minimum.

maximum heap size: Smaller of 1/4th of
the physical memory or 1GB.

Note: The boundaries and fractions given for the heap size are correct for J2SE 5.0. They are likely to be different in subsequent releases as computers get more powerful.

标签：java,64bit,32-bit,solaris
来源： https://codeday.me/bug/20190627/1299594.html