Windows任务管理器显示的进程虚拟内存的哪一部分

Question

我的问题有点幼稚。我愿意尽可能简单地概述，找不到任何能让我清楚的资源。我是开发人员，我想了解Windows任务管理器中默认情况下“内存”列中显示的内存究竟是什么：

为了使事情变得更简单，让我们忘记进程与其他进程共享的内存，并想象共享内存可以忽略不计。此外，我专注于全局，主要关注GB级别的事物。

据我所知，被称为“虚拟内存”的进程保留的内存部分存储在主内存（RAM）中，部分存储在磁盘上。系统决定了哪里去了。系统基本上在RAM中保留虚拟存储器的部分，该部分由该过程充分频繁地访问。进程可以保留比计算机中可用的RAM更多的虚拟内存。

从开发人员的角度来看，虚拟内存可能只是由程序通过自己的内存管理器（例如malloc()或new X()）部分分配。我猜系统不知道虚拟内存的哪个部分被分配，因为这是由进程以“私有”的方式处理的，并且取决于语言，运行时，编译器......问：这是正确的吗？

我的假设是，任务管理器显示的内存基本上是系统存储在RAM中的虚拟内存的一部分。 问：这是正确的吗？是否有一种简单的方法可以了解流程保留的总虚拟内存？

Answer 1

Windows上的内存是......非常复杂，并且询问我的进程使用了​​多少内存＆＃39;实际上是一个荒谬的问题。要回答你的问题，请先了解一下背景知识。

Windows上的内存是通过ptr = VirtualAlloc(..., MEM_RESERVE, ...)分配的，稍后会以VirtualAlloc(ptr+n, MEM_COMMIT, ...)提交。

任何保留的内存都会耗尽地址空间，所以并不感兴趣。 Windows会让你MEM_RESERVE太字节的内存很好。提交内存会耗尽资源，但不会影响您的想法。当你调用提交窗口时会做一些总和并且基本上可以解决（总物理ram +总交换 - 当前提交）并允许你分配内存，如果有足够的空闲。但是，在您实际使用它之前，Windows内存管理器实际上并没有给你物理ram。

然而，稍后，如果Windows对于物理RAM很紧，它会将一些RAM交换到磁盘（它可能会压缩它并丢弃未使用的页面，丢弃任何直接从文件映射的内容和其他优化）。这意味着您的程序的总提交和物理ram总使用量可能会大不相同。根据您的测量结果，这两个数字都很有用。

最后一个大警告 - 共享的记忆。当您加载DLL代码时，只读存储器[甚至可能是读/写部分，但这是COW＆＃39; d]可以与其他程序共享。这意味着你的应用程序需要那个内存，但是你不能仅仅依靠你的应用来计算内存 - 毕竟它可以被共享，所以不会占用尽可能多的物理内存而不是天真的数量。认为

（如果您正在编写游戏或类似游戏，您还需要计算GPU内存，但我不是这里的专家）

上述所有优点通常都由应用程序使用的堆包装，你不会看到这一点 - 你要求并使用内存。它尽可能地最佳。

您可以通过转到详细信息选项卡并查看各种选项来看到这一点 - commit-size和working-set非常有用。如果您只是查看任务管理器中的主窗口并且它具有单个值，我希望您现在明白所使用的内存的单个值必须是某种妥协，因为它不是一个有意义的问题。

现在回答你的问题

首先，操作系统确切知道您的应用程序已预留多少内存以及已提交的内存量。它不知道的是你（或者更有可能是CRT）正在使用的堆实现是否保留了一些未释放的内存，而这些内存并没有释放回操作系统。堆通常以优化方式执行此操作 - 从操作系统请求内存并将其释放回操作系统是一项相当昂贵的操作（并且只能在称为页面的大块中完成），因此大多数操作都会保留一些。

第二个问题：不要使用该值，转到详细信息并使用其中的值，只有您知道您实际想要问的内容。

编辑：

对于您的评论，是的，但这取决于分配的大小。如果你分配了一个大的内存块（比如＆gt; = 1MB），那么CRT中的堆通常会直接将分配推迟到操作系统，因此释放单个内存实际上会释放它们。对于小分配，CRT中的堆要求操作系统中的内存页，然后将其细分以分配给出。因此，如果你随后释放其中任何一个，那么你就会留下漏洞 - 并且堆不能将这些漏洞带回操作系统，因为操作系统通常只能在整个页面中工作。因此，您在任务管理器中看到的任何内容都将显示仍然使用了所有内存。请记住，这个记忆不会丢失或泄漏，它只是有效地汇集，并且如果分配要求这个大小，将再次使用。如果你关心这段记忆，你可以使用crt heap statistics famliy of functions来关注这些 - 特别是_CrtMemDumpStatistics