vmmap?分析內(nèi)存泄露問題
[導(dǎo)讀]vmmap是sysinternals工具集中的一個(gè)工具，主要用于分析一個(gè)進(jìn)程的虛擬內(nèi)存和物理內(nèi)存的使用情況。更有效的是，可以通過對(duì)比兩個(gè)不同時(shí)間的內(nèi)存使用情況的Snapshot，來查找內(nèi)存泄露問題。vmmap介紹當(dāng)你用vmmap去查看一個(gè)正在運(yùn)行的進(jìn)程的時(shí)候?？梢钥吹饺缦聢D，不同...
vmmap是sysinternals工具集中的一個(gè)工具，主要用于分析一個(gè)進(jìn)程的虛擬內(nèi)存和物理內(nèi)存的使用情況。更有效的是，可以通過對(duì)比兩個(gè)不同時(shí)間的內(nèi)存使用情況的Snapshot，來查找內(nèi)存泄露問題。vmmap介紹
當(dāng)你用vmmap去查看一個(gè)正在運(yùn)行的進(jìn)程的時(shí)候?？梢钥吹饺缦聢D，不同類型的內(nèi)存使用采用不同的顏色標(biāo)明。VMMap主要列舉了以下幾種類型的內(nèi)存使用情況：- Free: 圖中顯示
137434599232K，是不是被嚇到了。這個(gè)一般是指虛擬地址空間。每個(gè)進(jìn)程都有自己的虛擬地址空間，比如32位的一般為4G，其中2G是內(nèi)核地址空間, 2GB用戶態(tài)地址空間；64位理論上為2^64個(gè)字節(jié)，實(shí)際上沒那么大，按照MSDN的描述64位的Windows用戶態(tài)可使用地址空間為128TB。 - Heap: 這個(gè)主要就是指我們通過C/C 的
malloc,?new;以及HeapAlloc等申請(qǐng)的內(nèi)存大小 - Image: 比較好理解，一般指進(jìn)程啟動(dòng)的運(yùn)行文件，比如Exe或者加載的DLL文件。
- Managed Heap: 這個(gè)一般指用C#編寫代碼使用的托管堆。比如一個(gè)程序可能是C#和C 均有實(shí)現(xiàn)，這個(gè)時(shí)候可以查看是不是托管堆占用的內(nèi)存持續(xù)增高，那么就可以判斷一般是C#部分托管堆使用有問題造成了泄露。
- Mapped File: 主要是指內(nèi)存映射文件，熟悉的同學(xué)應(yīng)該知道，這也是常用的進(jìn)程間通信的一種方式。
- Private Data: 主要指通過
VirtualAlloc申請(qǐng)的內(nèi)存空間。這里也注意同Free主要是指已經(jīng)使用的地址空間，而非已經(jīng)Commit的內(nèi)存。比如下圖中, - Stack: 函數(shù)棧所使用的內(nèi)存大小
- Shareable: 主要是進(jìn)程間可以共享的內(nèi)存，但是后備存儲(chǔ)器為RAM或者Paging File(一般是指虛擬內(nèi)存page.sys)。
- Page Table: 主要指內(nèi)核中和該進(jìn)程頁表相關(guān)聯(lián)的內(nèi)存
對(duì)于其他的描述，本人本人主要介紹兩種需要關(guān)注的:
- Committed: 對(duì)于一個(gè)虛擬地址空間的使用，我們可以是申請(qǐng)地址空間，但不提交(
commit)，如果不提交，則不會(huì)占用真實(shí)的存儲(chǔ)器空間(比如RAM或者Paging File)，只有commit后才會(huì)使用物理內(nèi)存(RAM或者Paging File)。那么VMMap這里所指的內(nèi)存就是后備存儲(chǔ)器為RAM, Paging File, 或者M(jìn)apped 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分析出來的，主要是因?yàn)楫?dāng)運(yùn)行到比較長(zhǎng)的時(shí)間的時(shí)候VMMap偶爾會(huì)出現(xiàn)崩潰的情況。但是VMMap確實(shí)可以輔助分析出內(nèi)存泄露問題，筆者也是將這個(gè)方法分享給大家。下面是一段便于讀者理解Vmmap分析方法的樣例。首先每隔10秒鐘，申請(qǐng)10M內(nèi)存，總共申請(qǐng)10次；然后每隔10秒釋放1次內(nèi)存，只釋放5次。這樣操作，可以簡(jiǎn)單模擬，一個(gè)程序在運(yùn)行中既有正常的內(nèi)存申請(qǐng)釋放的場(chǎng)景，也有申請(qǐng)后卻沒有釋放的場(chǎng)景，這樣交錯(cuò)在一起，讓問題更加逼近現(xiàn)實(shí)。這樣也便于使用這種方法，在未來碰到問題的時(shí)候進(jìn)行實(shí)戰(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;
}
接下來一起來查看是如何定位一個(gè)程序的內(nèi)存泄露的。第一步?配置好程序的位置，工作目錄，以及符號(hào)文件目錄:第二步?當(dāng)運(yùn)行程序，首先看到整個(gè)VMMap界面。這個(gè)時(shí)候映入眼簾的好多好多數(shù)據(jù)，該看什么呢？首先對(duì)于一般的C 程序而言，堆的內(nèi)存泄露使用是最常見，那么就先看下Heap部分的Committed大小是不是很大。比如本文的樣例，發(fā)現(xiàn)已經(jīng)有70M左右的大小。先鎖定到溢出內(nèi)存類型為Heap。第三步?個(gè)人認(rèn)為查找內(nèi)存泄露也需要一些技巧和常識(shí)的。比如程序剛啟動(dòng)不久的時(shí)候，申請(qǐng)的很多資源是全局的，或者伴隨著整個(gè)進(jìn)程的生命周期的，那么剛啟動(dòng)后的內(nèi)存的增長(zhǎng)一般可以忽略，不認(rèn)為是內(nèi)存泄露的原因。再大概程序運(yùn)行一段時(shí)間后（根據(jù)自己程序?qū)嶋H情況而定），基本的伴隨整個(gè)進(jìn)程的生命周期的資源已經(jīng)創(chuàng)建完畢。此時(shí)可以使用Timeline和Address部分的功能對(duì)照查看。這個(gè)時(shí)候首先選擇
Heap(點(diǎn)擊一下)，那么Address部分將會(huì)顯示Heap所占用的內(nèi)存。然后當(dāng)我們打開Timeline，選擇特定的時(shí)間段區(qū)域，比如上圖中選擇區(qū)域?yàn)閯傞_始申請(qǐng)內(nèi)存的部分，每隔10秒，增加申請(qǐng)10M內(nèi)存。此時(shí)重要的是Address部分也會(huì)動(dòng)態(tài)的展示這段時(shí)間的內(nèi)存變化。然后注意其中的內(nèi)存使用比如
000001B39E445000的內(nèi)存被申請(qǐng)了，然后拉長(zhǎng)時(shí)間線，發(fā)現(xiàn)很長(zhǎng)時(shí)間還是存在在Address欄中，并且綠色，就說明一直沒有被釋放。此時(shí)當(dāng)你選中這個(gè)地址，再選擇
Heap Allocations，便可以看到其申請(qǐng)的大小為10000000, 雙擊打開后便可以查看到函數(shù)調(diào)用棧了。如下圖所示便可以找到是在HeapMemoryLeakSample函數(shù)內(nèi)調(diào)用了new，并且有行號(hào)提示(不過這里的行號(hào)提示不夠精準(zhǔn)，但是也不影響你去分析問題了)。也可以不選擇區(qū)間，而選個(gè)某個(gè)時(shí)間點(diǎn)，查看內(nèi)存的狀態(tài)。第四步?如果很幸運(yùn)，第三步已經(jīng)找到問題了。第四步本來想說一說Call Stack的追蹤的，比如通過申請(qǐng)的內(nèi)存的Count或者Bytes來查找到可疑的內(nèi)存泄露點(diǎn)的函數(shù)調(diào)用棧?？墒枪P者多次實(shí)驗(yàn)后均發(fā)現(xiàn)，數(shù)據(jù)對(duì)不上。比如下圖的Count百分比和Bytes百分比之和均對(duì)不上100%。所以筆者也不會(huì)對(duì)此做過多的贅述，調(diào)試軟件同樣也是軟件，也可能存在bug或者一些限制。但是通過如上的方法和思想，也許能夠協(xié)助你找到內(nèi)存泄露點(diǎn)，至少可以起到輔助的作用。- EOF -
下載文檔
