Windows-提交大小与虚拟大小

我想知道提交大小（在任务管理器中可见）和虚拟大小（在SysInternals的Process Explorer中可见）之间的确切区别

---

Process Explorer中的Virtual Size参数看起来更准确地指示进程的总虚拟内存使用量。但是，提交大小总是小于虚拟大小，我猜它不包括进程使用的所有虚拟内存。我希望有人解释一下这些参数中到底包含了什么。

虚拟大小是进程虚拟地址空间的大小

分配内存时，您可以请求一个地址范围，而无需实际提交其后面的内存。在使用第二个分配调用提交这些地址之前，这些地址不会指向物理内存

---

阅读更多关于。Linux具有mmap功能，可以做同样的事情。

内存可以被保留、提交、首次访问，并且是工作集的一部分。当保留内存时，会留出一部分地址空间，而不会发生其他任何事情

当提交内存时，操作系统保证相应的页面原则上可以存在于物理RAM或页面文件中。换句话说，它计算系统上可用页面总数的硬限制，并正式创建页面。也就是说，它创建页面并假装它们存在（而实际上它们还不存在）

当第一次访问内存时，会创建正式存在的页面，以便它们真正存在。要么向流程提供零页，要么从映射将数据读入页面。页面被移动到流程的工作集中（但不一定永远留在那里）

每个正在运行的进程都有许多页，这些页实际上和逻辑上都在RAM中，也就是说，这些页是存在的，它们也是“正式”存在的。这是流程的工作集。
此外，每个正在运行的进程都有实际上在RAM中的页面，但在RAM中不再正式存在。它们可能位于所谓的“备用列表”或缓冲区缓存的一部分，或其他内容。当这些被访问时，操作系统可以简单地将它们再次移动到工作集中。
最后，每个进程都有根本不在RAM中的页面（要么在交换中，要么还不存在）

虚拟大小包含进程保留的所有页面的大小

提交大小仅包含已提交的页面

---

也就是说，用外行术语来说，“虚拟大小”几乎是您自己的问题，并且只受地址空间大小的限制，而“提交大小”是每个人的问题，因为它消耗了一个全局有限的资源（RAM加交换）。因此，它会影响其他进程。

提交大小是分页文件中为进程保留的空间量。当需要交换页面以在RAM中为其他进程腾出空间时使用

---

是的，虚拟内存的大小会更大，因为它包含分页文件不支持的页面。EXE和未重新定位的DLL中至少包含代码和资源部分。必要时，可以简单地丢弃这些页面并从文件中重新加载。所有操作系统DLL都适合此类别。此外，进程使用的任何内存映射文件。SysInternals的VMMap实用程序可以提供洞察力。

很难说。两者都可能是内存泄漏或类似的指示器，但它们是不同的东西。当您的虚拟大小达到2GB（或更早，由于碎片化，或稍后使用/3G）时，您最终将耗尽地址空间，因此进一步分配将出现“内存不足”错误，尽管原则上可能有足够的可用RAM。通常，“不断上升而不再下降”是不好的，但如果提交再次下降，这可能只是堆管理器保留内存（但正确地取消提交），这将是正常的。您是否遇到实际的内存不足情况？碎片的问题是，您可能会使分配器很难（不可能）提供内存，即使内存足够。例如，

std:：vector

用于增长的典型模式对分配器来说是一场噩梦：分配一个较大的块，复制，然后释放较小的块。然后分配另一个更大的块，复制并释放第二个块。以一种有用的方式回收释放的内存是不可能的，因为块大小永远不适合您要求的大小（幸运的是，这是一个罕见的事件，因为

vector

以几何方式增长，但您可能会使用类似的分配模式）。因此，如果在这些情况下遇到崩溃，而实际上应该有足够的内存，那么是的，很可能您遇到了碎片。请注意您分配/释放的模式，尽早保留而不是动态增长，如果适用，请分配更大的对象池（反复使用的对象池可以创造奇迹）。还要注意，分配器要处理的最小大小（通常是16个字节，因为它与8个字节对齐，需要存储簿记信息），因此分配许多非常小的对象对分配器也是有害的。不要将

提交大小

（由任务管理器报告）与

提交页面

混淆。

Commit Size

是内存映射文件（如二进制代码页）不支持的内存量<代码>提交的页面是一段虚拟内存，其中包括所有可寻址页面（与空闲或保留页面相反）。[…]正如您所指出的，完全位置独立的代码是通常不计入提交的映射的一个示例（但其他部分可能）。另外，TaskManager中显示的数字与页面数量的差异与页面大小的系数相同（但这只是一个演示细节），这是对的。尽管如此，这段记忆仍然是值得纪念的