vmmap是sysinternals工具集中的一個工具，主要用于分析一個進程的虛擬內(nèi)存和物理內(nèi)存的使用情況。更有效的是，可以通過對比兩個不同時間的內(nèi)存使用情況的Snapshot，來查找內(nèi)存泄露問題。

vmmap介紹

當你用vmmap去查看一個正在運行的進程的時候?？梢钥吹饺缦聢D，不同類型的內(nèi)存使用采用不同的顏色標明。VMMap主要列舉了以下幾種類型的內(nèi)存使用情況：

• Free: 圖中顯示137434599232K，是不是被嚇到了。這個一般是指虛擬地址空間。每個進程都有自己的虛擬地址空間，比如32位的一般為4G，其中2G是內(nèi)核地址空間, 2GB用戶態(tài)地址空間；64位理論上為2^64個字節(jié)，實際上沒那么大，按照MSDN的描述64位的Windows用戶態(tài)可使用地址空間為128TB。

• Heap: 這個主要就是指我們通過C/C 的malloc,?new;以及HeapAlloc等申請的內(nèi)存大小

• Image: 比較好理解，一般指進程啟動的運行文件，比如Exe或者加載的DLL文件。

• Managed Heap: 這個一般指用C#編寫代碼使用的托管堆。比如一個程序可能是C#和C 均有實現(xiàn)，這個時候可以查看是不是托管堆占用的內(nèi)存持續(xù)增高，那么就可以判斷一般是C#部分托管堆使用有問題造成了泄露。

• Mapped File: 主要是指內(nèi)存映射文件，熟悉的同學(xué)應(yīng)該知道，這也是常用的進程間通信的一種方式。

• Private Data: 主要指通過VirtualAlloc申請的內(nèi)存空間。這里也注意同Free主要是指已經(jīng)使用的地址空間，而非已經(jīng)Commit的內(nèi)存。比如下圖中,

• Stack: 函數(shù)棧所使用的內(nèi)存大小

• Shareable: 主要是進程間可以共享的內(nèi)存，但是后備存儲器為RAM或者Paging File(一般是指虛擬內(nèi)存page.sys)。

• Page Table: 主要指內(nèi)核中和該進程頁表相關(guān)聯(lián)的內(nèi)存

對于其他的描述，本人本人主要介紹兩種需要關(guān)注的:

• Committed: 對于一個虛擬地址空間的使用，我們可以是申請地址空間，但不提交(commit)，如果不提交，則不會占用真實的存儲器空間(比如RAM或者Paging File)，只有commit后才會使用物理內(nèi)存(RAM或者Paging File)。那么VMMap這里所指的內(nèi)存就是后備存儲器為RAM, Paging File, 或者Mapped file。

• Working Set: 一般內(nèi)存有RAM，還有虛擬內(nèi)存（page.sys），而根據(jù)內(nèi)存的調(diào)度原理，并不是所有的內(nèi)存都常駐RAM。Working Set就是主要指在RAM中所使用的內(nèi)存。

VMMap分析內(nèi)存泄露

筆者曾經(jīng)有一次用過VMMap分析過內(nèi)存泄露，但是最終問題并不是通過VMMap分析出來的，主要是因為當運行到比較長的時間的時候VMMap偶爾會出現(xiàn)崩潰的情況。但是VMMap確實可以輔助分析出內(nèi)存泄露問題，筆者也是將這個方法分享給大家。

下面是一段便于讀者理解Vmmap分析方法的樣例。首先每隔10秒鐘，申請10M內(nèi)存，總共申請10次；然后每隔10秒釋放1次內(nèi)存，只釋放5次。這樣操作，可以簡單模擬，一個程序在運行中既有正常的內(nèi)存申請釋放的場景，也有申請后卻沒有釋放的場景，這樣交錯在一起，讓問題更加逼近現(xiàn)實。這樣也便于使用這種方法，在未來碰到問題的時候進行實戰(zhàn)。

#include?
#include?
#include?
#include?
void?HeapMemoryLeakSample()?{
?const?int?iListSize?=?10;
?char*?pHeapList[iListSize];
?//Alloc?10?Heap?STR_SIZE
?const?int?STR_SIZE?=?10?*?1000?*?1000;
?for?(int?i?=?0;?i???pHeapList[i]?=?new?char?[STR_SIZE];
??strcpy_s(pHeapList[i],?STR_SIZE,?"Alloc?Memory");
??std::cout?<std::endl;
??std::this_thread::sleep_for?(std::chrono::seconds(10));
?}
?//Free?5?Heap?space
?for?(int?i?=?0;?i???if?(i?%?2?==?0)?{
???delete?pHeapList[i];
???std::cout?<"Free?Memory"?<std::endl;
???std::this_thread::sleep_for?(std::chrono::seconds(10));
??}
?}
}
int?main()?{
?HeapMemoryLeakSample();
?while?(true)?{
??std::this_thread::sleep_for?(std::chrono::seconds(10));
?}
?return?0;
}
接下來一起來查看是如何定位一個程序的內(nèi)存泄露的。

第一步?配置好程序的位置，工作目錄，以及符號文件目錄:


第二步?當運行程序，首先看到整個VMMap界面。這個時候映入眼簾的好多好多數(shù)據(jù)，該看什么呢？首先對于一般的C 程序而言，堆的內(nèi)存泄露使用是最常見，那么就先看下Heap部分的Committed大小是不是很大。比如本文的樣例，發(fā)現(xiàn)已經(jīng)有70M左右的大小。先鎖定到溢出內(nèi)存類型為Heap。

第三步?個人認為查找內(nèi)存泄露也需要一些技巧和常識的。比如程序剛啟動不久的時候，申請的很多資源是全局的，或者伴隨著整個進程的生命周期的，那么剛啟動后的內(nèi)存的增長一般可以忽略，不認為是內(nèi)存泄露的原因。再大概程序運行一段時間后（根據(jù)自己程序?qū)嶋H情況而定），基本的伴隨整個進程的生命周期的資源已經(jīng)創(chuàng)建完畢。此時可以使用Timeline和Address部分的功能對照查看。

這個時候首先選擇Heap(點擊一下)，那么Address部分將會顯示Heap所占用的內(nèi)存。然后當我們打開Timeline，選擇特定的時間段區(qū)域，比如上圖中選擇區(qū)域為剛開始申請內(nèi)存的部分，每隔10秒，增加申請10M內(nèi)存。此時重要的是Address部分也會動態(tài)的展示這段時間的內(nèi)存變化。

然后注意其中的內(nèi)存使用比如000001B39E445000的內(nèi)存被申請了，然后拉長時間線，發(fā)現(xiàn)很長時間還是存在在Address欄中，并且綠色，就說明一直沒有被釋放。

此時當你選中這個地址，再選擇Heap Allocations，便可以看到其申請的大小為10000000, 雙擊打開后便可以查看到函數(shù)調(diào)用棧了。如下圖所示便可以找到是在HeapMemoryLeakSample函數(shù)內(nèi)調(diào)用了new，并且有行號提示(不過這里的行號提示不夠精準，但是也不影響你去分析問題了)。

也可以不選擇區(qū)間，而選個某個時間點，查看內(nèi)存的狀態(tài)。

第四步?如果很幸運，第三步已經(jīng)找到問題了。第四步本來想說一說Call Stack的追蹤的，比如通過申請的內(nèi)存的Count或者Bytes來查找到可疑的內(nèi)存泄露點的函數(shù)調(diào)用棧?？墒枪P者多次實驗后均發(fā)現(xiàn)，數(shù)據(jù)對不上。比如下圖的Count百分比和Bytes百分比之和均對不上100%。所以筆者也不會對此做過多的贅述，調(diào)試軟件同樣也是軟件，也可能存在bug或者一些限制。但是通過如上的方法和思想，也許能夠協(xié)助你找到內(nèi)存泄露點，至少可以起到輔助的作用。

- EOF -