Windows Task Manager显示进程虚拟内存的哪个部分

Question

我的问题有点天真。 我愿意提供一个尽可能简单的概述，并且找不到任何使我明白的资源。 我是一名开发人员，我想了解Windows Task Manager中默认情况下“内存”列中显示的内存到底是什么：

为了使事情简单一些，让我们忘记该进程与其他进程共享的内存，并假设共享内存可以忽略不计。 我也专注于全局，主要关心GB级别的事物。

据我所知，进程“虚拟内存”保留的内存部分存储在主内存（RAM）中，部分存储在磁盘上。 系统决定去哪里。 系统基本上将虚拟内存的一部分保存在RAM中，该进程会足够频繁地对其进行访问。 一个进程可以保留比计算机中可用RAM更多的虚拟内存。

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

我的假设是，任务管理器显示的内存实质上是系统存储在RAM中的虚拟内存的一部分。 问：对吗？ 有没有一种简单的方法来知道该进程保留的虚拟内存总量？

Answer 1

Windows上的内存非常复杂……询问“我的进程使用了​​多少内存”实际上是一个荒谬的问题。 要回答您的问题，请先获得一些背景知识。

Windows上的内存是通过ptr = VirtualAlloc(..., MEM_RESERVE, ...)稍后再通过VirtualAlloc(ptr+n, MEM_COMMIT, ...) 。

任何保留的内存都只会占用地址空间，因此没有兴趣。 Windows将允许您MEM_RESERVE TB的内存。 提交内存确实会浪费资源，但不会以您认为的方式使用。 当您调用commit窗口时，它们会进行一些累加并基本计算出（总物理内存+总交换数-当前提交），并且如果有足够的可用空间，则可以分配内存。 但是，在您实际使用Windows内存管理器之前，它实际上并没有给您提供物理内存。

但是，稍后，如果Windows占用的物理RAM太紧，它将把您的部分RAM交换到磁盘上（它可能会压缩它，还会丢弃未使用的页面，丢弃直接从文件映射的内容以及进行其他优化）。 这意味着您的程序的总提交和总的物理内存使用情况可能完全不同。 这两个数字都非常有用，具体取决于您要测量的内容。

最后一个大警告-共享的内存。 当您加载DLL代码时，可以与其他程序共享只读存储器[甚至可能是读/写部分，但这是COW'd]。 这意味着您的应用程序需要该内存，但您不能仅将其计算在您的应用程序中-毕竟它可以共享，因此占用的物理内存不会像幼稚的计数那样。

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

以上所有优点通常由应用程序使用的堆包装，您看不到这些-您需要并使用内存。 并且它尽可能地最佳。

您可以通过转到详细信息选项卡并查看各种选项来查看此内容-提交大小和工作集非常有用。 如果您仅查看任务管理器中的主窗口，并且它具有单个值，那么我希望您现在已经理解，所用内存的单个值必须是某种折衷方案，因为这不是一个有意义的问题。

现在回答您的问题

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

第二个问题：不要使用该值，而要详细了解并在其中使用这些值，因为只有您知道自己实际要问什么。

编辑：

对于您的评论，是的，但这取决于分配的大小。 如果您分配很大的内存块（例如> = 1MB），那么CRT中的堆通常会直接推迟对操作系统的分配，因此释放单个内存实际上将释放它们。 对于小分配，CRT中的堆从操作系统请求内存页，然后将其细分以分配。 因此，如果您再释放其他所有漏洞，那么您将留下漏洞-并且堆无法将漏洞归还给操作系统，因为操作系统通常只能在整个页面上工作。 因此，您在任务管理器中看到的所有内容都将显示所有内存仍在使用中。 请记住，此内存不会丢失或泄漏，它只是有效地池化了，如果分配要求该大小，它将再次使用。 如果您关心此内存，则可以使用函数的crt堆统计信息来关注这些信息-特别是_CrtMemDumpStatistics