这是我的理解，这是每个进程，而不是整个进程。 但根据Windows Server 2003和Windows 2000（KB283037）提供大内存支持：
通常，在Windows 2000或Windows Server 2003下运行的进程可以访问高达2 GB的内存地址空间（假设未使用/ 3GB开关），其中一些内存是物理内存，一些是虚拟内存。 运行的程序越多（因此运行的进程越多），就可以为整个2 GB的地址空间提供更多的内存。
对我来说，你运行的程序越多，碰到2GB地址空间限制的可能性就越大，即程序A使用500MB，程序B使用1GB，所以你的程序只剩下500MB的地址空间。
但是，MSDN文章http://msdn.microsoft.com/en-us/library/ms189334.aspx将其称为进程地址空间，对我来说，意味着每个应用程序都有自己的地址空间，不pipe是2GB还是3GB boot.ini中使用了什么开关。
那么每个进程或整个进程是如何？ 而知识库文章是错误的（或措辞不妙）？
（请注意我只是在讨论32位系统）
这是每个进程的虚拟地址空间 ，根据MSDN文章以及由Raymond Chen撰写并在他的博客上存档的一系列精彩文章。
这里是他的这一系列文章的索引页面 – 如果你正在处理作为高级系统pipe理员或开发人员的大内存支持，非常值得一读。
它只增加用魔术比特编译的程序的地址空间，可以select寻找这个额外的空间。
这个神奇的位是“大地址意识”的支持。
大多数微软程序（我相信）默认情况下启用此位。
在互联网上有一个工具，LaaTIDO，可以实现这一点。 我已经使用这个工具来启用在Windows上运行的Tomcat和Sun的JDK的大地址支持。
这个标志的问题在于，一些程序员不知道内存位置可能高于2 GB的限制，这可能会导致应用程序中的一些令人讨厌的错误。 让我解释为什么…
RAM中的地址指针与某些语言中的32位有符号整数类似。 签名意味着它可以是正面的或负面的。 现在，要检查一个指针是否被赋值，你检查它是否等于NULL / nil。 如果它不是null，则将其分配给某个东西。 一些程序员通过检查地址是否大于空来检查这个，因此他们忘记了地址可能是负的可能性。 由于负指针小于零，系统会认为它是未分配的，因此重新分配一个新的值，失去它的当前值和泄漏的内存。
幸运的是，大多数程序员学会了检查它是否相等，而不是大于空。 在这种情况下，应用程序将不会有问题，最多使用3 GB。