Mr.*_*urg 2 c# windows memory-management virtual-memory large-address-aware
标题几乎概括了这一点。我有一个为 x86 平台编译的应用程序，它/largeaddressaware设置了标志。在 x64 系统上运行它，我可以“免费”获得扩展的 4GB 用户模式虚拟内存，而无需指定/3GB启动选项。在 x86 系统上，这意味着内核模式内存仅为 1GB，但由于 x64 系统可以寻址更多内存，内核模式是否会保留 2GB，甚至会增加到 3GB？
编辑：要明确的是，我想知道每个进程的限制。这个问题源于阅读这篇文章。
编辑2：这个问题不是重复的多少内存可以在64位操作系统上32位进程访问？因为该问题仅涉及应用程序可访问的内存，而不是系统可访问的内存。如果我误解了并且没有为每个进程的系统保留内存，如果有人可以将其写为答案，我将不胜感激。我确信我不是第一个对此感到困惑的人。
有一些误解让您感到困惑。
首先，我们来看看 32 位 Windows。每个进程的虚拟地址空间都有一部分分配给进程本身，还有一部分分配给内核所需的任何内容。然而，所有进程共享相同的内核内存 - 事实上，您甚至在自己的虚拟地址空间中拥有内核内存，这基本上是一种性能优化，以避免在处理应用程序中的内核对象和数据时必须切换地址空间。
默认情况下，这是 1:1 分割，因此您将获得 2 GiB 的用户地址空间和 2 GiB 的内核地址空间。这是早期 32 位 Windows 软件（当您的计算机在 486 CPU 或类似设备上总共只有 4 MiB 内存时）（滥用）使用的，因为由于内存的布局方式，您的用户地址space 从来没有任何超过2 GiB 屏障的指针 - 有效地为您提供了用于您自己的数据的任何指针的最高位。通常，这用于允许混合“如果适合，这是一个值，否则它是指向结构的指针”方法，从而节省内存和一些间接寻址。由于这种情况如此广泛，因此默认的分割方式与早期相同，以防止兼容性问题。但是，您还可以选择不同的分割 - 3 GiB 用户空间和 1 GiB 内核空间。这就是该/3GB选项的作用。但这还不够 - 您的应用程序还必须选择使用/LARGEADDRESSAWARE. 这基本上是说“我不会用我的指针做奇怪的事情”。
应该注意的是，32 位操作系统或进程并不一定意味着您只能寻址 4 GiB 内存 - 它只是限制了 CPU 在任何时候可以直接访问的内容。对于内存密集型服务器软件，即使是“32 位”版本也可能支持寻址更多内存 - 例如，32 位 MS SQL Server 通过 AWE 支持高达 64 GiB。这基本上是虚拟化的另一层，它允许重新映射虚拟地址的物理地址。理论上，无论有没有 AWE，您可以寻址的内存量都没有限制 - 毕竟，没有什么可以阻止您拥有自己的硬件来充当内存映射文件，从而有效地为您提供无限的地址空间。当然，就像分段内存的时代一样，它不太容易使用或实用:)
在 64 位 Windows 上，/3GB不再有任何意义并被忽略。默认地址空间分割取决于 Windows 的确切版本，但在“TB 及更多”范围内，超出了 32 位限制。对于现代 Windows，这通常是 128 TiB 用户 + 128 TiB 内核。32位应用程序还是要/LARGEADDRESSAWARE像以前一样使用。但是，由于内核现在是 64 位，因此无论如何它都不能与用户进程位于同一地址空间，因此 64 位操作系统上的 32 位应用程序可以完全访问 4 GiB 地址空间。
当然，这些限制仍然远低于 64 位理论上能够寻址的范围。然而，大多数 64 位 CPU 实际上无法寻址整个 64 位地址空间 - 我上次检查时最常见的是 48 位。令人惊讶的是，令人惊讶的是 - 这为您提供了 256 TiB 的地址空间，这是 Windows 中的限制。毕竟不是微软的阴谋！:) 实际上，这不是什么新鲜事。Intel x86 的 32 位 ALU 与 32 位地址空间相关这一事实在 CPU 历史上是相当离奇的 - CPU 通常具有比 ALU 宽度更高和更低的地址空间（无论是虚拟寻址还是物理寻址）宽度。MS DOS 的典型限制为 1 MiB 可寻址内存（640 kiB 留给用户应用程序）也源于此 - 当时的“32 位”CPU 只能使用 20 位地址。