为什么 32 位进程有 2 GB 的 RAM 限制？

Question

我很好奇为什么 32 位操作系统上的 32 位进程有 2 GB 的限制。根据博客文章聊天问题：32 位和 64 位进程的内存限制，限制可以扩展到 3 GB，但问题仍然存在。

我看到物理限制是 4 GB，那么 2 或 3 GB 只是在 Windows 中硬编码吗？为什么 4 GB 作为 32 位进程在 64 位操作系统上可能没有？

注意：此问题被标记为重复，但引用的问题是指 32 位地址空间的 4 GB 限制。这不是我要问的。我特别问为什么 Windows 将进程限制为2 GB——即使在 32 位平台上也是如此。接受的答案提到了它，但没有解释原因。

Answer 1

在 NT 平台上，4 GB 虚拟地址空间默认分为两部分，低 2 GB 用于进程地址空间，高 2 GB 用于系统使用。

该地址空间是虚拟的，不受 RAM 大小的影响。CPU 和操作系统内存管理器根据需要将部分 RAM 映射到虚拟地址空间。这很复杂，这里不再赘述。这是出于性能、安全性和可靠性的考虑而做出的设计决策。

每个进程都有自己私有的2GB地址空间，但系统地址空间只有一个。进程被隔离在自己的私有地址空间中，甚至看不到其他进程。必要时可以在两个或多个进程之间共享地址。系统地址空间不受正常进程的限制，只能被内核级组件访问，例如操作系统本身和设备驱动程序。如果一个过程误入歧途，它只会伤害自己；其他进程和操作系统不受影响。

但是为什么不给系统自己的私有地址空间，就像进程一样？这将允许系统和每个进程使用完整的 4 GB 地址空间。那本来可以做到的——但是有一个问题。

假设已经完成。正在运行的进程可以完全访问自己的代码和数据，一切看起来都很好。但是，如果该进程进行需要访问系统地址空间（例如 I/O 操作）的 OS 调用呢？或者如果有一个中断需要内核处理会发生什么？

CPU 只能看到正在运行的进程的地址空间。该怎么办？解决方案是进行上下文切换，将系统地址空间带入视野。操作系统可以非常有效地执行此操作，但这确实需要时间。如果需要频繁访问系统地址空间，则上下文切换的开销将变得过多并且性能受到影响。

必须有更好的方法。

所采用的解决方案是将 4 GB 的总地址空间分成两部分，每部分 2 GB。低 2 GB 的进程地址空间和高 2 GB 的系统。这允许系统地址空间始终在范围内并在需要时无需上下文切换即可访问。正如经常发生的那样，设计决策是出于实际原因做出的。

现在 2 GB 可能看起来很小而且很受限制，但是在 1993 年 NT 发布时它已经很大了。不要忘记每个进程都有自己的 2 GB。