Window内存详解（五） VMMAP内存查看工具

╰+攻爆jí腚メ 2022-08-08 00:54 233阅读 0赞

下面我根据VMMap来详细介绍一下内存的分类。

内存是一个很复杂的系统，其中的paging file，sharable memory，reserve和commit等概念使得要算清楚一个进程到底使用了多少内存几乎成了不可能的事情了。

还好我们有VMMap这个工具，它用两个纬度将内存进行了详细的划分。

一个是纵向的纬度，也就是内存是从哪里来的。分为

1.  Image（可执行文件），
2.  Mapped file（由CreateFileMapping以文件作为back up）。
3.  Sharable(由CreateFileMapping以内存作为 back up)
4.  Private Data（由Virtual Alloc分配）
5.  Heap（由new，GlobalAlloc和HeapAlloc等分配）
6.  Stack（栈占用的控件）
7.  Page table（内核里面维护当前虚拟地址控件所需要的内存）
8.  Managed Heap（由.NET garbage collector分配和管理）

![2012030714484257.png][]

还有一个横向的维护，分别被称为：

1.  Size： 总体大小，包括了commit和没有reservce的内存。如果这项和Committed不 一致，那么就是说有reserve的内存。
2.  Committed： committed的大小，包括Private内存和可共享的内存。
3.  Private：属于当前进程的虚拟内存，指的是当你修改他时仅仅当前进程会受到影响。（copy-on-wirte属性的页面还没被修改时也属于此类）

以上实际上是虚拟内存(virtual memory)的概念，其中的内容可能被物理内存（physical memory）back up，也可能被Paging file back up。

而以下的几个指标指的是物理内存：

1.  Total WS: 所有的working set，包括private working set和sharable working set。
2.  Private WS: private working set。仅属于当前进程的working set。
3.  Sharable WS。可共享的working set。
4.  Shared WS。已经共享的working set，这个值应该是sharable working set的一部分或者全部。

为了更具体的了解这几个指标，下面我们根据一些API的具体行为所产生的结果来观察一下他们的含义。

New，GlobalAlloc and HeapAlloc：

受影响的是VMMap中的Heap行。

分配时占用的是Committed和Private列，working set不受影响。

当访问时Total working set和Private Working Set跟着上升。

VirtualAlloc：

受影响的是VMMap中的Private Data行。

分配Reserve的data时，上升的是第一列Size，第二列Committed不变。

Commit时，上升的是Committed和Private列。Total Working Set列不变。

当访问Commit的内存时，上升的是Total Working set 和Private Working set列。

DeCommit时，只有第一列size保持不变，Committed，Private和Working set列都下降。

Release时，第一列Size也下降。

Memory Based CreateFileMapping

这个file mapping不管有没有命名，下面的行为都一样。

受影响的是VMMap中的Sharable行。

调用CreateFileMapping时，不影响任何列，增加的只是系统的Total Commit Charge。

调用MapViewOfFile时，上升的是Size和Committed列。

当访问这些map的数据时，上升的是Total Working Set和Sharable Working Set。

调用UnmapViewOfFile时，Size，Committee和Working set列都下降。

调用CloseHandle来关闭CreateFileMapping创建的handle时，不影响任何列， 但是减少了系统的Total Commit Charge。

共享状态下的Memory based CreateFileMapping

需要注意的是这个file mapping命名了，并且是在同一个进程中打开两次，以达到共享的目的。

受影响的是VMMap中的Sharable列。

调用第一个调用CreateFileMapping时，不影响任何列，增加的只是系统的Total Commit Charge。

调用MapViewOfFile时，上升的是Size和Committed列。

当访问这些map的数据时，上升的是Total Working Set和Sharable Working Set。

以上行为跟前面一个Scenario完全一样，下面要开始创建再次打开刚才创建的File mapping.

当用同样的名字再次调用CreateFileMapping打开前面创建的file mapping时，系统的Total Commit Charge不受影响，也不影响VMMap中的任何列。

调用MapViewOfFile时，上升的是Size和Committed列。也就是说，上升第二次了。

当访问这些map的数据时，上升的是Total Working Set和Sharable Working Set。也是上升第二次。

调用UnmapViewOfFile来ummap掉第二次打开的view，Size，，commmited和working set都下降一半。

调用UnmapViewOfFile来ummap掉第一次打开的view，Size，，commmited和working set都下降到初始状态。

调用CloseHandle来关闭第二次打开的Handle，Total Commit charge不受影响。

调用CloseHandle来关闭第一次打开的Handle，Total Commit charge下降。

File Based CreateFileMapping

受影响的是Mapped File行。

调用CreateFileMapping时，没有影响到VMMap中的任何列，并且跟Memory Based File mapping不一样的是，Total Commit Charge也不受 影响，因为他是以File 作为back up的

调用MapViewOfFile时，上升的是Size和Committed列。跟Memory Based File mapping一样的表现。

当访问这些map的数据时，上升的是Total Working Set和Sharable Working Set。跟Memory Based File mapping一样的表现。

调用UnmapViewOfFile时，Size，Committee和Working set列都下降。跟Memory Based File mapping一样的表现。

调用CloseHandle来关闭CreateFileMapping创建的handle时，不影响任何列， 也不影响Total Commit Charge。

总结：file based和memory based不同点在于：

1.  File based影响是Mapped file行，memory based影响的是Sharable行。
2.  File based 不影响total commit charge， memory based 影响。

[2012030714484257.png]: /images/20220805/a69d947dd84340708645bf873ca4dc94.png

Window内存详解（五） VMMAP内存查看工具

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关使用 vmmap 分析内存泄漏问题

相关端口进程内存查看操作(linux、windows)

相关内存取证volatility工具命令详解

相关 qt5使用内存检测工具vld查看内存泄漏

相关【jdk】查看jdk内存（window或linux）

相关 [Windows驱动开发]（五）内核内存管理

相关 Window内存详解（五） VMMAP内存查看工具

相关 Windows内存详解（四）OD内存断点初步分析

相关 Windows 内存详解（三）Windows内存管理

相关 windows内存详解（一）全面介绍Windows内存管理机制及C++内存分配实例