在64位操作系统中使用32位应用程序内存。

如果我的操作系统是64位，我的32位应用程序可以使用64位内存（> 3.5GB）吗？

如果该应用程序知道AWE，则它们可以使用超过4Gb的地址空间，尽管效率不如64位应用程序。如果启用了PAE并且该进程能够使用它，则32位Windows变体下的32位进程甚至有可能访问超过32位地址空间所允许的范围。

一个单独的32位进程_{^{（不了解AWE）}}通常限制为3Gb（其虚拟地址空间的第一个Gb保留给内核相关的操作），但是如果您正在运行多个进程，则它们将能够在总计 _{^{（每个人最多可以使用3Gb，总内存允许），}}因为它们的虚拟地址空间未共享。

每个进程的限制在类似Unix的环境中更为有用，在该环境中，服务倾向于基于进程而不是基于_{^{线程（一个进程中的多个线程共享进程资源，因此共享单个3Gb虚拟地址空间）}}，这一点更为常见。在Windows下_^（在Windows中_{^{启动新进程非常昂贵，因此首选线程，在大多数Unix环境下，启动新进程并不比启动新线程多消耗资源）}}。例如，对于仅运行SQL Server的计算机来说，这不是很有用，因为它只是一个进程，因此将达到3Gb的限制_{^{（某些版本可以配置为AWE感知，但不是全部都可以，并且功能将在下一个主要版本中删除）}}。

以及32位进程总共可以使用超过3Gb的内存，操作系统将能够使用任何未使用的内存进行磁盘缓存，因此，如果进程不以这种方式打开文件，则它可能不会浪费。告诉操作系统不要去做。

如果应用程序使用AWE，则可以（尽管不限于64位OS）。没有它，该过程仍然仅限于4GB地址空间。

Sorta，取决于您的意思。

假设Windows ...

如果操作系统是64位，则默认情况下32位进程将获得2 GB的用户地址虚拟地址空间。如果.exe文件的PE头标有IMAGE_FILE_LARGE_ADDRESS_AWARE标志，则该过程将获得4 GB的用户可寻址虚拟地址空间。无论哪种情况，内核的虚拟地址空间都与64位进程相同，因为它在所有进程之间共享。还要注意的是，未设置IMAGE_FILE_LARGE_ADDRESS_AWARE标志的64位进程也只能访问2 GB的用户虚拟地址空间。

您听到的有关特殊引导标志，3 GB，/ 3GB开关或/ userva的信息都是关于32位操作系统的，不适用于64位Windows。

在Microsoft的“ Windows版本的内存限制”页面上，所有这些细节都令人发指。

@David Spillett的回答还涉及到另一点：多个进程，所有进程都限于2 GB的用户空间，如果可用，仍然可以使用大量的RAM，文件缓存也可以使用。

32位OS上的32位进程具有4GB的地址空间，其中2GB由OS保留，该进程可使用2GB。
可以为操作系统指定一个开关（/ 3GB），将仅保留给操作系统的预留空间更改为1GB，并允许进程拥有3GB BUT，但前提是进程在标志中声明自身为大型地址可执行文件。

在64位操作系统上，如果能够识别大地址，则32位进程将获得4GB，否则将获得2GB。

所有这些都是针对不了解AWE的流程的。如果该进程能够使用AWE，那么，正如其他人所说，它可以使用较大的地址空间，但效率不如64位进程。

PAE允许32位OS使用超过4GB的RAM，但是，它存在兼容性问题，并且在XP中被其中一个服务包禁用，因此仅在服务器OS版本上可用。