我对了解在64位OS中运行的32位JVM的最大（理论上和实际可实现的）堆大小更感兴趣。基本上，我正在寻找与SO相关问题中的数字相似的答案。
关于为什么使用32位JVM而不是64位JVM的原因，原因不是技术上的而是管理/官僚主义-在生产环境中安装64位JVM可能为时已晚。
#1 楼
希望只有一个大块内存并使用原始指针的32位JVM不能使用超过4 Gb（因为32位限制也适用于指针）。这包括Sun以及-我很确定-还包括IBM的实现。我不知道是否JRockit或其他产品在其32位实现中具有较大的内存选项。如果希望达到此限制，则应强烈考虑为您的生产环境考虑启动并行轨道来验证64位JVM，因此当32位环境崩溃时，您已经准备好了。否则，您将不得不在压力下完成这项工作，这永远都不好。
编辑2014-05-15：Oracle常见问题解答： 32位JVM的最大限制为4G。由于各种其他限制，例如可用交换，内核地址空间使用，内存碎片和VM开销，在实践中，限制可能要低得多。在大多数现代的32位Windows系统上，最大堆大小范围为1.4G至1.6G。在32位Solaris内核上，地址空间限制为2G。在运行32位VM的64位操作系统上，最大堆大小可能更高，在许多Solaris系统上接近4G。
（http://www.oracle.com/technetwork/java /hotspotfaq-138619.html#gc_heap_32bit）
#2 楼
您可以询问Java运行时：public class MaxMemory {
public static void main(String[] args) {
Runtime rt = Runtime.getRuntime();
long totalMem = rt.totalMemory();
long maxMem = rt.maxMemory();
long freeMem = rt.freeMemory();
double megs = 1048576.0;
System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
System.out.println ("Max Memory: " + maxMem + " (" + (maxMem/megs) + " MiB)");
System.out.println ("Free Memory: " + freeMem + " (" + (freeMem/megs) + " MiB)");
}
}
这将基于默认堆分配报告“最大内存”。因此，您仍然需要玩
-Xmx（在HotSpot上）。我发现我的32位HotSpot JVM在Windows 7 Enterprise 64位上运行，最多可以分配1577MiB：[C:scratch]> java -Xmx1600M MaxMemory Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. [C:scratch]> java -Xmx1590M MaxMemory Total Memory: 2031616 (1.9375 MiB) Max Memory: 1654456320 (1577.8125 MiB) Free Memory: 1840872 (1.75559234619 MiB) [C:scratch]>
而在64位JVM上相同的操作系统，当然要高得多（大约3TiB）
[C:scratch]> java -Xmx3560G MaxMemory Error occurred during initialization of VM Could not reserve enough space for object heap [C:scratch]> java -Xmx3550G MaxMemory Total Memory: 94240768 (89.875 MiB) Max Memory: 3388252028928 (3184151.84297 MiB) Free Memory: 93747752 (89.4048233032 MiB) [C:scratch]>
正如其他人已经提到的，它取决于操作系统。
对于32位Windows：<2GB（Windows内部手册中说2GB用于用户进程）
对于32位BSD / Linux：<3GB（来自Devil Book）
对于32位MacOS X：<4GB（来自Mac OS X内部手册）
不确定32位Solaris，请尝试上面的代码并告知我们。
对于64位主机操作系统，如果JVM是32位的，它将仍然依赖，很可能像上面演示的一样。
-更新20110905：我只想指出其他一些观察/细节：
我运行的硬件是64位，安装了6GB的实际RAM。操作系统是Windows 7 Enterprise，64位。可以分配的实际数量
Runtime.MaxMemory也取决于操作系统的工作集。我曾经在运行VirtualBox的同时运行了此程序，发现我无法使用-Xmx1590M成功启动HotSpot JVM，因此必须变小。这也意味着您可能会获得超过1590M的内存，具体取决于您当时的工作集大小（尽管由于Windows的设计，我仍然认为32位版本的大小会低于2GiB）评论
我喜欢您实际测试而不是猜测。
– Jim Hurne
11年8月25日在18:01
@djangofan是正确的。该程序应除以1,048,576（1024 * 1024或2 ^ 20），而不是104,856。但是，这只是一个展示。从命令可以看到，他仅尝试将最大堆大小设置为1,590 MiB。
– Jim Hurne
11年8月29日在12:14
非常酷的答案（我想说答案），带有代码示例，以及涵盖所有操作系统的详细信息。
–TGP1994
2013年6月17日在21:42
遵循我之前的评论：jdocs（对于Windows atleast）指定-Xmx和-Xms参数必须被赋予1024的倍数的值...我不确定是否1590是，所以我认为很奇怪结果应该是可以预期的。
–TGP1994
2013年6月17日在22:01
发现良好的TGP1994。我认为，因为我指定了“ M”和“ G”的倍数，所以无论如何大小（以字节为单位）将是1024字节的倍数。例如1590M将被解析为1590 *（1024 * 1024）= 1667235840字节（1628160KiB-当然是1024的偶数倍）。
– Mike
13年6月19日，0：05
#3 楼
您没有指定哪个操作系统。在Windows下（对于我的应用程序-长期运行的风险管理应用程序），我们观察到在Windows 32bit上容量不能超过1280MB。我怀疑在64位下运行32位JVM会产生什么区别。
我们将该应用程序移植到Linux，并且我们在64位硬件上运行32位JVM，并且拥有一个非常容易运行的2.2GB VM。 br />
您可能遇到的最大问题是GC，具体取决于您要使用的内存。
评论
我希望知道Solaris 10的限制，但这仅是针对我的问题。也想在雨天知道其他操作系统：)
–威诺雷诺兹
09年9月16日在19:15
不确定Solaris。我希望VM的大小会很大，我几年前在Solaris上使用Java的经验。作为Sun硬件上的Sun OS上的Sun VM，一切都很好。我还被认为是Solaris下的GC问题少于Linux / Windows。
– Fortyrunner
09年9月16日在19:28
这是哪个Windows。我相信Windows 32位的服务器版本可以更好地处理大量内存。
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
09-09-16 at 21:20
啊，最后提到了OS ；-)您安装了64位内核吗？
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
09-09-16 21:21
那是Win2k服务器。迁移到Win2k3（事情进展缓慢..）为时已晚，我们改用Linux。
– Fortyrunner
09-09-16 at 21:43
#4 楼
从4.1.2堆大小调整：“对于32位进程模型，
进程的最大虚拟地址大小通常为4 GB，尽管某些操作系统限制
2 GB或3 GB。最大堆大小通常为-Xmx3800m（1600m），对于
2 GB限制），但实际限制取决于应用程序。
对于64位进程型号，则基本上没有限制。“
在这里找到了一个很好的答案：Windows XP上的Java最大内存。
#5 楼
我们最近对此有了一些经验。我们最近已从Solaris（x86-64版本5.10）移植到Linux（RedHat x86-64），并意识到与Solaris相比，Linux上可用于32位JVM进程的内存更少。对于Solaris几乎达到4GB（http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit）。
我们在-Xms2560m -Xmx2560m -XX：MaxPermSize = 512m -XX：PermSize = 512m上运行了我们的应用程序，在过去的几年中，Solaris上均未出现任何问题。尝试将其移至linux时，我们在启动时遇到随机内存不足的问题。我们只能使它始终在-Xms2300 -Xmx2300上启动。然后我们得到了支持的建议。
Linux上的32位进程最大可寻址地址空间为3gb（3072mb），而在Solaris上为32g完整的4gb（ 4096mb）。
评论
支持人员给出答案的原因在于，进程可使用多少可寻址内存。这取决于Linux内核，甚至取决于硬件。从理论上讲，可寻址内存限制为2 ^ 32 = 4G（并且Java堆大小将小于此大小）。但是，这可以（理论上）使用hugemem和PAE进行扩展；我没有尝试过。
–威诺雷诺兹
2011年7月6日在16:39
#6 楼
在64位操作系统上的32位JVM的限制将与在32位OS上的32位JVM的限制完全相同。毕竟，32位JVM将在32位虚拟机（从虚拟化的角度来看）中运行，因此它不会知道它在64位OS /计算机上运行。在64位OS和32位OS上运行32位JVM的一个好处是可以拥有更多的物理内存，因此交换/分页的频率降低。但是，只有在具有多个过程时，才能真正充分实现此优势。
评论
取决于硬件及其虚拟化方式，可能会有细微的差异。 4GB的某些可寻址空间通常用于内存映射的设备。虚拟化层可能具有或不具有与机器上的物理设备相同的内存占用量。
– Eric J.
09年9月16日在19:05
不完全的。由于32位地址空间不必与操作系统或硬件接口共享，因此64位计算机中的JVM还有更多空间。
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
09年9月16日在19:08
没错，但这意味着您的32位虚拟机的开销可能与32位实际机的开销稍有不同（或者更糟，或者更好）。无论哪种方式，您都在32位计算机（真实或虚拟）上运行JVM，因此您将受制于标准32位约束。即：绝对上限为4GB。
–劳伦斯·贡萨尔维斯（Laurence Gonsalves）
09年9月16日在19:08
Thorbjørn：操作系统和硬件接口仍需要映射到32位VM中。窃听的确切数量可能有所不同，但仍会存在。如果您可以在64位操作系统下对其进行虚拟化，那么该如何阻止您在32位操作系统下对其进行虚拟化呢？这是我们正在谈论的虚拟内存。
–劳伦斯·贡萨尔维斯（Laurence Gonsalves）
09-09-16 19:13
LG：我不同意你的原始答案。操作系统内核以及它映射的任何硬件和总线地址空间都会占用很多地址空间，尽管它没有映射到用户程序中，但它确实减少了操作系统设置后的“剩余”数量。这是一个相当大的4GB 32位空间。传统上，这意味着4GB的大约25％-75％对用户进程不可用。 :-)内核黑客
– DigitalRoss
09年9月16日在19:16
#7 楼
关于为什么使用32位JVM而不是64位JVM的原因，原因不是技术性而是行政/官僚主义...
在BEA上工作时，我们发现平均应用程序实际上在64位JVM中运行得慢一些，而在32位JVM中运行时却慢了一点。在某些情况下，性能降低的速度高达25％。因此，除非您的应用程序确实需要所有这些额外的内存，否则最好设置更多的32位服务器。专业服务人员遇到了以下问题：
该应用程序正在处理多个海量图像，
该应用程序正在进行大量运算，
该应用程序存在内存泄漏，客户是政府合同的主要内容，他们不想花时间和费用来追查内存泄漏。 （使用大量内存
堆会增加MTBF，而素数仍会得到支付）
。
评论
很高兴为您提供第一手建议，BEA的前任:)
–emecas
13年3月15日在19:37
#8 楼
Oracle当前拥有的JROCKIT JVM支持不连续的堆使用，因此，当JVM在64位Windows OS上运行时，允许32位JVM访问超过3.8 GB的内存。 （在32位OS上运行时为2.8 GB）。需要注册）在http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html
#9 楼
这是在Solaris和Linux 64位系统上进行的一些测试Solaris 10-SPARC-T5220计算机具有32 GB RAM（大约有9 GB可用空间）
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3750m MaxMemory
Error occurred during initialization of VM
Could not reserve space for ObjectStartArray
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3700m MaxMemory
Total Memory: 518520832 (494.5 MiB)
Max Memory: 3451912192 (3292.0 MiB)
Free Memory: 515815488 (491.91998291015625 MiB)
Current PID is: 28274
Waiting for user to press Enter to finish ...
$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)
$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available
$ prstat -p 28274
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
28274 user1 670M 32M sleep 59 0 0:00:00 0.0% java/35
BTW：显然，Java在启动时并未分配太多实际内存。启动每个实例似乎只需要大约100 MB（我启动10个实例）
Solaris 10-x86-具有8 GB RAM（大约3 GB可用空间*）的VMWare VM
3 GB的可用RAM并不是真的。 ZFS缓存使用了大量的RAM，但是我没有root访问权限来检查确切的内存数量
4 GB RAM（已使用约3.8 GB-缓冲区200 MB，高速缓存3.1 GB，因此约有3 GB可用空间）
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3650m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3600m MaxMemory
Total Memory: 516423680 (492.5 MiB)
Max Memory: 3355443200 (3200.0 MiB)
Free Memory: 513718336 (489.91998291015625 MiB)
Current PID is: 26841
Waiting for user to press Enter to finish ...
$ java -version
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)
$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
$ prstat -p 26841
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
26841 user1 665M 22M sleep 59 0 0:00:00 0.0% java/12
同一台使用JRE 7的计算机
$ alias java='$HOME/jre/jre1.6.0_34/bin/java'
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory: 3215654912 (3066.6875 MiB)
Free Memory: 511838768 (488.1274871826172 MiB)
Current PID is: 21879
Waiting for user to press Enter to finish ...
$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) Server VM (build 20.9-b04, mixed mode)
$ file $HOME/jre/jre1.6.0_34/bin/java
/home/user1/jre/jre1.6.0_34/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
$ cat /proc/21879/status | grep ^Vm
VmPeak: 3882796 kB
VmSize: 3882796 kB
VmLck: 0 kB
VmHWM: 12520 kB
VmRSS: 12520 kB
VmData: 3867424 kB
VmStk: 88 kB
VmExe: 40 kB
VmLib: 14804 kB
VmPTE: 96 kB
评论
对于我们所缺少的平台，这里有一些有用的测试结果。也可以很好地使用文件和内存转储。
– Mike
2014年7月3日在7:02
#10 楼
对于更好的操作系统，应该更好一些对于在64位主机上运行的32位JVM，我想堆剩下的就是JVM之后可用的无碎片虚拟空间，它是自己的DLL ，并且所有OS 32位兼容性的东西都已加载。作为一个大胆的猜测，我认为应该有3GB的存储空间，但这要好得多取决于您在32位主机域中的运行状况。
即使您可以巨大的3GB堆，您可能不希望这样做，因为这会导致GC暂停变得很麻烦。有些人只是运行更多的JVM来使用额外的内存，而不是一个巨型的。我想他们现在正在调整JVM的性能以更好地处理巨型堆。
很难确切知道您可以做的更好。我想您的32位情况可以通过实验轻松确定。当然，要进行抽象预测是很困难的，因为要考虑很多因素，尤其是因为32位主机上可用的虚拟空间非常有限。堆确实需要存在于连续的虚拟内存中，因此地址空间的碎片dll以及操作系统内核对地址空间的内部使用将确定可能的分配范围。
操作系统将使用一些地址空间来映射硬件设备及其自身的动态分配。尽管此内存未映射到Java进程地址空间，但是OS内核无法同时访问它和您的地址空间，因此它将限制任何程序的虚拟空间的大小。
加载DLL取决于JVM的实现和版本。加载OS内核取决于很多事情，包括发行版，硬件以及自上次重启以来到目前为止已映射了多少东西，谁知道...
总结
我敢打赌，您在32位域中可获得1-2 GB，在64位域中可获得约3 GB，因此总体提高了约2倍。
评论
不幸的是，我没有一个可以使用Xmx标志进行实验的64位环境。据我所知，有一个巨大的（32 * n）GB可用RAM，但超出了范围。这就是为什么我想知道32位JVM在没有32位世界中通常面临的所有约束的情况下如何工作。
–威诺雷诺兹
09年9月16日在19:23
好，很好的问题。我确信基本答案是“它将更好地工作”。
– DigitalRoss
09年9月16日在19:27
好的，我已经修改了答案，将重点更多地放在了您的实际问题上。 :-)
– DigitalRoss
09年9月16日在19:48
≅3GB的64位声音几乎正确。 Thorbjørn已经表明了理论上为什么它不能超过4GB的原因。太糟糕了，我不能接受两个答案。
–威诺雷诺兹
09年9月16日在19:57
如果您有一个大箱子，则可以例如使用64位Solaris进行试验。 virtualbox（具有最佳的Solaris guest虚拟机支持）。
–索比昂·拉文·安徒生
09-09-16 at 21:23
#11 楼
从Solaris 2.5开始，在Solaris上的限制约为3.5 GB。 （大约10年前）评论
我将使用Oracle Solaris Express 11进行试验。
– djangofan
11年8月25日在21:18
@Peter Lawrey Uhm ..如果考虑到1996年5月的发布日期，Solaris 2.5大约是20年前了....当然，它直到2005年左右才停产。
–cb88
13年5月10日在21:55
#12 楼
我在使用Android版Blocks Editor的App Inventor使用JVM时遇到了同样的问题。它设置堆最大为925m。这还不够，但是我无法将其设置为超过1200m，具体取决于计算机上的各种随机因素。我从Firefox和JAVA 7下载了Nightly（测试版64位浏览器） 64位版本。
我还没有找到新的堆限制，但是我刚刚打开了一个堆大小为5900m的JVM。没问题！
我正在具有24gb RAM的计算机上运行Win 7 64位旗舰版。
#13 楼
我尝试在32位Linux机器上将堆大小设置为2200M，并且JVM运行良好。当我将其设置为2300M时，JVM没有启动。评论
我以为我会在Windows VISTA 64位上添加一个32位JVM，最大值为1582m（-Xmx值）。如果我指定1583m，它会抱怨。我不知道此值是否在计算机之间更改。我对其进行测试的计算机实际上具有4 GB的物理RAM。
– Santosh Tiwari
2011年6月9日15:12
@SantoshTiwari它因机器而异，但这就是为什么
– Eugene
5月2日，3:34
#14 楼
这很麻烦，但是您可以获得3gb的堆。http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http://forall.ru-board .com / egor23 / online / FAQ / Virtual_Memory / Limits_Virtual_Memory.html
#15 楼
这里是热点32位JVM的另一点：-本机堆容量= 4 Gig – Java堆– PermGen;
自Java以来，对于32位JVM可能特别棘手堆和本地堆正在比赛。
Java堆越大，本机堆越小。尝试为32位VM设置较大的堆
，例如，.2.5 GB +增加了本机OutOfMemoryError的风险，具体取决于您的应用程序占用空间，线程数等。
#16 楼
理论上的4GB，但实际上（针对IBM JVM）：Win 2k8 64，IBM Websphere Application Server 8.5.5 32位
C:\IBM\WebSphere\AppServer\bin>managesdk.bat -listAvailable -verbose CWSDK1003I: Доступные SDK: CWSDK1005I: Имя SDK: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=windows - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 - com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/win /x86_32/
CWSDK1001I: Задача managesdk выполнена успешно.
C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2036 MaxMemory
JVMJ9GC017E -Xmx слишком мала, должна быть не меньше 1 M байт
JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось инициализи
ровать
Could not create the Java virtual machine.
C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2047M MaxMemory
Total Memory: 4194304 (4.0 MiB)
Max Memory: 2146435072 (2047.0 MiB)
Free Memory: 3064536 (2.9225692749023438 MiB)
C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2048M MaxMemory
JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось создать эк
земпляр кучи; запрошено 2G
Could not create the Java virtual machine. RHEL 6.4 64，IBM Websphere Application Server 8.5.5 32位
[bin]./java -Xmx3791M MaxMemory
Total Memory: 4194304 (4.0 MiB)
Max Memory: 3975151616 (3791.0 MiB)
Free Memory: 3232992 (3.083221435546875 MiB)
[root@nagios1p bin]# ./java -Xmx3793M MaxMemory
Total Memory: 4194304 (4.0 MiB)
Max Memory: 3977248768 (3793.0 MiB)
Free Memory: 3232992 (3.083221435546875 MiB)
[bin]# /opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable -verbose
CWSDK1003I: Available SDKs :
CWSDK1005I: SDK name: 1.6_32
- com.ibm.websphere.sdk.version.1.6_32=1.6
- com.ibm.websphere.sdk.bits.1.6_32=32
- com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java
- com.ibm.websphere.sdk.platform.1.6_32=linux
- com.ibm.websphere.sdk.architecture.1.6_32=x86_32
-com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/linux/x86_32/
CWSDK1001I: Successfully performed the requested managesdk task.
#17 楼
该限制还来自以下事实：对于32 bit VM，如果要所有heap，则4GB本身必须从地址零开始。 考虑一下，如果要通过以下方式引用某些内容：
0000....0001
ie：具有这种特殊位表示形式的引用，表示您正在尝试访问堆中的第一个内存。为此，堆必须从地址零开始。但这永远不会发生，它会从零开始偏移：
| .... .... {heap_start .... heap_end} ... |
--> (this can't be referenced) <--
因为在
OS中堆从不从地址零开始，所以有很多位永远不会从32位引用使用，因此可以引用的堆较低。
评论
这里没有工作压力。我知道应该首先安装64位JVM。但是，这让我开始思考如何在拥有更多资源的环境中使用32位JVM。
–威诺雷诺兹
09-09-16 at 19:18
是不是因为Signnes占用了2GB？还是仅仅是Sun JVM？
–塞巴斯蒂安·甘斯兰特（Sebastian Ganslandt）
09-09-16 at 19:19
指针未签名-说负存储位置没有意义。
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
09年9月16日在21:15
不，由于签名，它不是2GB。但是，部分4GB地址空间是为OS内核保留的。在Windows的普通消费者版本上，限制为2GB。在Linux和Windows（32位）服务器版本上，每个进程限制为3GB。
–杰斯珀
09年9月17日上午10:44
@Jesper我想知道在64位操作系统上运行的32位JVM是否可以具有完整的4 GB地址空间？
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
2012年12月20日上午10:14