我正在从这里学习有关 Windows 32 位虚拟内存页面映射的知识，
（我的目标是现代 Windows 版本，例如 Vista、Win 7、Server 2003/2008 32 位版本。）
两个困惑，
用户空间虚拟内存空间通常限制在2G，但物理磁盘页面存储可能远大于2G。由于磁盘页面比虚拟内存页面多，因此理论上可以将多个磁盘页面映射到一个虚拟地址页面。如果用户请求访问某个虚拟地址，如果多个磁盘页面映射到一个虚拟地址页面，内存管理器如何知道应该访问哪个磁盘页面？
我不知道为什么会有像 byte[] 数组必须使用连续的虚拟内存空间这样的限制。我认为理论上即使我们只分配500M的虚拟空间地址，我们也可以重新使用这样的虚拟空间地址来继续映射/取消映射磁盘页面文件，以消耗尽可能多的资源，甚至大于2G。
有任何想法吗？
字节（或任何其他）数组必须使用连续的地址空间，在这种情况下是连续的虚拟地址空间。这是一个可以使碎片成为问题的区域，并且实际上由于内存的虚拟化而加剧。由于此类系统系统中固有的各种“重定向”以及使其高效的性能考虑导致实际分配映射到块（通常是页面）中的虚拟地址空间的物理地址空间。
因此，请求 10 字节的虚拟地址空间块实际上可能会导致整个 4K 页面被保留和映射。由于页面内的物理内存必须是连续的，这可能导致整个 4K 的虚拟地址空间被“封锁”。
多个小的分配可以放在一个页面中（好的内存管理器会尝试实现这一点），但实际上保留的地址空间超过了严格要求的空间。考虑在起始 fa 页分配单个字节，然后是 4K - 2 个字节，然后是另一个单个字节。这（有效地）占据了整个页面。
考虑是否不再需要中间分配并因此被释放。在“top”和“tail”值被释放或移动到其他地方之前，在虚拟地址空间中创建了一个空白，该空白只能由小于 4K-1 字节的内容填充。如果发生足够多的此类事情，则虚拟地址空间中的连续区域收缩的速度比实际使用的内存总量要快得多。
您是正确的，因为没有什么能阻止您，用户，将您的（受限于 32 位土地）地址空间映射到 CPU/OS 支持的更大的磁盘或内存空间。一些芯片通过诸如PAE之类的机制使用超过 4GB 的物理地址空间来实现这一点。
Windows 本身提供了一个 API 来处理“更改地址空间的映射以将不同的“窗口”放到更广泛的池中的大多数方面（无论是通过 PAE、运行 WoW64、磁盘还是混合）。这称为AWE。但是这样的机制已经存在多年（就像那些记得 EMS 时代的传统记忆或分段记忆时代的人一样。
即使没有 CPU 和操作系统支持，您仍然可以通过各种技术自己手动完成（见下文）。
非常有趣的 Raymond Chen 处理了 windows 中许多更复杂的方面。
（某些版本的 Windows 有一个开关可以为用户程序启用 3G，但为了讨论的目的，我们将忽略它，因为原理是相同的。）
32 位程序只能访问 4G 内存，因为这是 32 位中可以容纳的最大指针。程序运行时，一部分内存空间映射到自身，一部分映射到操作系统。否则，当你调用操作系统时，操作系统代码不能同时看到它自己的内存和程序内存。
所以你的程序没有得到所有的内存，因此限制了连续分配。
现在，不同的程序可以拥有所有可寻址内存的不同子集。一些 32 位芯片允许物理上超过 4G 的内存，但是，任何给定的进程，因为它是 32 位，一次只能直接“看到”高达 32 位或 4G，其中一些属于进程（2G )，还有一些用于管理程序和其他程序的操作系统 (2G)。
这是我能给出的最简单的解释；请参阅虚拟内存以获得更长和更技术性的解释。
Mark Russinovich 写了一篇很好的文章Pushing the Limits of Windows: Virtual Memory。我认为您应该阅读它以清楚地了解它的工作原理。
一个进程可用的总虚拟地址空间为 4GB。上面的 2GB 对所有进程都是通用的，并且只能由系统级组件访问。较低的 2GB 是每个进程私有的，不共享。这与 RAM 的大小完全无关。映射到用户进程的磁盘页面可能远远超过 2GB。由于 2GB 进程空间是私有的，所有进程的总地址空间将远远超过 2GB。即使在理论上，也不可能在同一个进程中将多个磁盘页面映射到一个虚拟地址。