堆和棧的區別

1、預備知識—程序的內存分配
一個由c/C++編譯的程序佔用的內存分爲如下幾個部分
一、棧區（stack）— 由編譯器自動分配釋放 ，存放函數的參數值，局部變量的值等。其操做方式相似於數據結構中的棧。
二、堆區（heap） — 通常由程序員分配釋放， 若程序員不釋放，程序結束時可能由OS回收 。注意它與數據結構中的堆是兩回事，分配方式卻是相似於鏈表，呵呵。
三、全局區（靜態區）（static）—，全局變量和靜態變量的存儲是放在一塊的，初始化的全局變量和靜態變量在一塊區域， 未初始化的全局變量和未初始化的靜態變量在相鄰的另外一塊區域。 - 程序結束後有系統釋放 
四、文字常量區—常量字符串就是放在這裏的。 程序結束後由系統釋放
五、程序代碼區—存放函數體的二進制代碼。
2、例子程序 
這是一個前輩寫的，很是詳細 
//main.cpp 
int a = 0; 全局初始化區 
char *p1; 全局未初始化區 
main() 
{ 
int b; 棧 
char s[] = "abc"; 棧 
char *p2; 棧 
char *p3 = "123456"; 123456\0在常量區，p3在棧上。 
static int c =0； 全局（靜態）初始化區 
p1 = (char *)malloc(10); 
p2 = (char *)malloc(20); 
分配得來得10和20字節的區域就在堆區。 
strcpy(p1, "123456"); 123456\0放在常量區，編譯器可能會將它與p3所指向的"123456"優化成一個地方。 
}  2、堆和棧的理論知識 
2.1申請方式 
stack: 
由系統自動分配。 例如，聲明在函數中一個局部變量 int b; 系統自動在棧中爲b開闢空間 
heap: 
須要程序員本身申請，並指明大小，在c中malloc函數 
如p1 = (char *)malloc(10); 
在C++中用new運算符 
如p2 = (char *)malloc(10); 
可是注意p一、p2自己是在棧中的。 

2.2 
申請後系統的響應 
棧：只要棧的剩餘空間大於所申請空間，系統將爲程序提供內存，不然將報異常提示棧溢出。 
堆：首先應該知道操做系統有一個記錄空閒內存地址的鏈表，當系統收到程序的申請時， 
會 遍歷該鏈表，尋找第一個空間大於所申請空間的堆結點，而後將該結點從空閒結點鏈表中刪除，並將該結點的空間分配給程序，另外，對於大多數系統，會在這塊內 存空間中的首地址處記錄本次分配的大小，這樣，代碼中的delete語句才能正確的釋放本內存空間。另外，因爲找到的堆結點的大小不必定正好等於申請的大 小，系統會自動的將多餘的那部分從新放入空閒鏈表中。 

2.3申請大小的限制 
棧：在Windows下,棧是向低地址擴展的數據結構，是一塊連續的內存的區域。這句話的意思是棧頂的地址和棧的最 大容量是系統預先規定好的，在WINDOWS下，棧的大小是2M（也有的說是1M，總之是一個編譯時就肯定的常數），若是申請的空間超過棧的剩餘空間時， 將提示overflow。所以，能從棧得到的空間較小。 
堆：堆是向高地址擴展的數據結構，是不連續的內存區域。這是因爲系統是用鏈表來存儲的空閒內存地址的，天然是不連續的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限於計算機系統中有效的虛擬內存。因而可知，堆得到的空間比較靈活，也比較大。 

2.4申請效率的比較： 
棧由系統自動分配，速度較快。但程序員是沒法控制的。 
堆是由new分配的內存，通常速度比較慢，並且容易產生內存碎片,不過用起來最方便. 
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配內存，他不是在堆，也不是在棧是直接在進程的地址空間中保留一快內存，雖然用起來最不方便。可是速度快，也最靈活。 

2.5堆和棧中的存儲內容 
棧： 在函數調用時，第一個進棧的是主函數中後的下一條指令（函數調用語句的下一條可執行語句）的地址，而後是函數的各個參數，在大多數的C編譯器中，參數是由右往左入棧的，而後是函數中的局部變量。注意靜態變量是不入棧的。 
當本次函數調用結束後，局部變量先出棧，而後是參數，最後棧頂指針指向最開始存的地址，也就是主函數中的下一條指令，程序由該點繼續運行。 
堆：通常是在堆的頭部用一個字節存放堆的大小。堆中的具體內容有程序員安排。 

2.6存取效率的比較 

char s1[] = "aaaaaaaaaaaaaaa"; 
char *s2 = "bbbbbbbbbbbbbbbbb"; 
aaaaaaaaaaa是在運行時刻賦值的； 
而bbbbbbbbbbb是在編譯時就肯定的； 
可是，在之後的存取中，在棧上的數組比指針所指向的字符串(例如堆)快。 
好比： 
#include 
void main() 
{ 
char a = 1; 
char c[] = "1234567890"; 
char *p ="1234567890"; 
a = c[1]; 
a = p[1]; 
return; 
} 
對應的彙編代碼 
10: a = c[1]; 
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh] 
0040106A 88 4D FC mov byte ptr [ebp-4],cl 
11: a = p[1]; 
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h] 
00401070 8A 42 01 mov al,byte ptr [edx+1] 
00401073 88 45 FC mov byte ptr [ebp-4],al 
第一種在讀取時直接就把字符串中的元素讀到寄存器cl中，而第二種則要先把指針值讀到edx中，在根據edx讀取字符，顯然慢了。 

2.7小結： 
堆和棧的區別能夠用以下的比喻來看出： 
使用棧就象咱們去飯館裏吃飯，只管點菜（發出申請）、付錢、和吃（使用），吃飽了就走，沒必要理會切菜、洗菜等準備工做和洗碗、刷鍋等掃尾工做，他的好處是快捷，可是自由度小。 
使用堆就象是本身動手作喜歡吃的菜餚，比較麻煩，可是比較符合本身的口味，並且自由度大。 

windows進程中的內存結構

在閱讀本文以前，若是你連堆棧是什麼多不知道的話，請先閱讀文章後面的基礎知識。 

接觸過編程的人都知道，高級語言都能經過變量名來訪問內存中的數據。那麼這些變量在內存中是如何存放的呢？程序又是如何使用這些變量的呢？下面就會對此進行深刻的討論。下文中的C語言代碼如沒有特別聲明，默認都使用VC編譯的release版。 

首先，來了解一下 C 語言的變量是如何在內存分部的。C 語言有全局變量(Global)、本地變量(Local)，靜態變量(Static)、寄存器變量(Regeister)。每種變量都有不一樣的分配方式。先來看下面這段代碼： 

#include <stdio.h> 

int g1=0, g2=0, g3=0; 

int main() 
{ 
static int s1=0, s2=0, s3=0; 
int v1=0, v2=0, v3=0; 

//打印出各個變量的內存地址 

printf("0x%08x\n",&v1); //打印各本地變量的內存地址 
printf("0x%08x\n",&v2); 
printf("0x%08x\n\n",&v3); 
printf("0x%08x\n",&g1); //打印各全局變量的內存地址 
printf("0x%08x\n",&g2); 
printf("0x%08x\n\n",&g3); 
printf("0x%08x\n",&s1); //打印各靜態變量的內存地址 
printf("0x%08x\n",&s2); 
printf("0x%08x\n\n",&s3); 
return 0; 
} 

編譯後的執行結果是： 

0x0012ff78 
0x0012ff7c 
0x0012ff80 

0x004068d0 
0x004068d4 
0x004068d8 

0x004068dc 
0x004068e0 
0x004068e4 

輸出的結果就是變量的內存地址。其中v1,v2,v3是本地變量，g1,g2,g3是全局變量，s1,s2,s3是靜態變量。你能夠看到這些變量在 內存是連續分佈的，可是本地變量和全局變量分配的內存地址差了十萬八千里，而全局變量和靜態變量分配的內存是連續的。這是由於本地變量和全局/靜態變量是 分配在不一樣類型的內存區域中的結果。對於一個進程的內存空間而言，能夠在邏輯上分紅3個部份：代碼區，靜態數據區和動態數據區。動態數據區通常就是「堆 棧」。「棧(stack)」和「堆(heap)」是兩種不一樣的動態數據區，棧是一種線性結構，堆是一種鏈式結構。進程的每一個線程都有私有的「棧」，因此每 個線程雖然代碼同樣，但本地變量的數據都是互不干擾。一個堆棧能夠經過「基地址」和「棧頂」地址來描述。全局變量和靜態變量分配在靜態數據區，本地變量分 配在動態數據區，即堆棧中。程序經過堆棧的基地址和偏移量來訪問本地變量。 

├———————┤低端內存區域 
│ …… │ 
├———————┤ 
│ 動態數據區 │ 
├———————┤ 
│ …… │ 
├———————┤ 
│ 代碼區 │ 
├———————┤ 
│ 靜態數據區 │ 
├———————┤ 
│ …… │ 
├———————┤高端內存區域 

堆棧是一個先進後出的數據結構，棧頂地址老是小於等於棧的基地址。咱們能夠先了解一下函數調用的過程，以便對堆棧在程序中的做用有更深刻的 瞭解。不一樣的語言有不一樣的函數調用規定，這些因素有參數的壓入規則和堆棧的平衡。windows API的調用規則和ANSI C的函數調用規則是不同 的，前者由被調函數調整堆棧，後者由調用者調整堆棧。二者經過「__stdcall」和「__cdecl」前綴區分。先看下面這段代碼： 

#include <stdio.h> 

void __stdcall func(int param1,int param2,int param3) 
{ 
int var1=param1; 
int var2=param2; 
int var3=param3; 
printf("0x%08x\n",¶m1); //打印出各個變量的內存地址 
printf("0x%08x\n",¶m2); 
printf("0x%08x\n\n",¶m3); 
printf("0x%08x\n",&var1); 
printf("0x%08x\n",&var2); 
printf("0x%08x\n\n",&var3); 
return; 
} 

int main() 
{ 
func(1,2,3); 
return 0; 
} 

編譯後的執行結果是： 

0x0012ff78 
0x0012ff7c 
0x0012ff80 

0x0012ff68 
0x0012ff6c 
0x0012ff70 

├———————┤<—函數執行時的棧頂（ESP）、低端內存區域 
│ …… │ 
├———————┤ 
│ var 1 │ 
├———————┤ 
│ var 2 │ 
├———————┤ 
│ var 3 │ 
├———————┤ 
│ RET │ 
├———————┤<—「__cdecl」函數返回後的棧頂（ESP） 
│ parameter 1 │ 
├———————┤ 
│ parameter 2 │ 
├———————┤ 
│ parameter 3 │ 
├———————┤<—「__stdcall」函數返回後的棧頂（ESP） 
│ …… │ 
├———————┤<—棧底（基地址 EBP）、高端內存區域 

上圖就是函數調用過程當中堆棧的樣子了。首先，三個參數以從又到左的次序壓入堆棧，先壓「param3」，再壓「param2」，最後壓入 「param1」；而後壓入函數的返回地址(RET)，接着跳轉到函數地址接着執行（這裏要補充一點，介紹UNIX下的緩衝溢出原理的文章中都提到在壓入 RET後，繼續壓入當前EBP，而後用當前ESP代替EBP。然而，有一篇介紹windows下函數調用的文章中說，在windows下的函數調用也有這 一步驟，但根據個人實際調試，並未發現這一步，這還能夠從param3和var1之間只有4字節的間隙這點看出來）；第三步，將棧頂(ESP)減去一個 數，爲本地變量分配內存空間，上例中是減去12字節(ESP=ESP-3*4，每一個int變量佔用4個字節)；接着就初始化本地變量的內存空間。因爲 「__stdcall」調用由被調函數調整堆棧，因此在函數返回前要恢復堆棧，先回收本地變量佔用的內存(ESP=ESP+3*4)，而後取出返回地址， 填入EIP寄存器，回收先前壓入參數佔用的內存(ESP=ESP+3*4)，繼續執行調用者的代碼。參見下列彙編代碼： 

;--------------func 函數的彙編代碼------------------- 

:00401000 83EC0C sub esp, 0000000C //建立本地變量的內存空間 
:00401003 8B442410 mov eax, dword ptr [esp+10] 
:00401007 8B4C2414 mov ecx, dword ptr [esp+14] 
:0040100B 8B542418 mov edx, dword ptr [esp+18] 
:0040100F 89442400 mov dword ptr [esp], eax 
:00401013 8D442410 lea eax, dword ptr [esp+10] 
:00401017 894C2404 mov dword ptr [esp+04], ecx 

……………………（省略若干代碼） 

:00401075 83C43C add esp, 0000003C ;恢復堆棧，回收本地變量的內存空間 
:00401078 C3 ret 000C ;函數返回，恢復參數佔用的內存空間 
;若是是「__cdecl」的話，這裏是「ret」，堆棧將由調用者恢復 

;-------------------函數結束------------------------- 

;--------------主程序調用func函數的代碼-------------- 

:00401080 6A03 push 00000003 //壓入參數param3 
:00401082 6A02 push 00000002 //壓入參數param2 
:00401084 6A01 push 00000001 //壓入參數param1 
:00401086 E875FFFFFF call 00401000 //調用func函數 
;若是是「__cdecl」的話，將在這裏恢復堆棧，「add esp, 0000000C」 

聰明的讀者看到這裏，差很少就明白緩衝溢出的原理了。先來看下面的代碼： 

#include <stdio.h> 
#include <string.h> 

void __stdcall func() 
{ 
char lpBuff[8]="\0"; 
strcat(lpBuff,"AAAAAAAAAAA"); 
return; 
} 

int main() 
{ 
func(); 
return 0; 
} 

編譯後執行一下回怎麼樣？哈，「"0x00414141"指令引用的"0x00000000"內存。該內存不能爲"read"。」，「非法操做」 嘍！"41"就是"A"的16進制的ASCII碼了，那明顯就是strcat這句出的問題了。"lpBuff"的大小隻有8字節，算進結尾的\0，那 strcat最多隻能寫入7個"A"，但程序實際寫入了11個"A"外加1個\0。再來看看上面那幅圖，多出來的4個字節正好覆蓋了RET的所在的內存空 間，致使函數返回到一個錯誤的內存地址，執行了錯誤的指令。若是能精心構造這個字符串，使它分紅三部分，前一部份僅僅是填充的無心義數據以達到溢出的目 的，接着是一個覆蓋RET的數據，緊接着是一段shellcode，那隻要着個RET地址能指向這段shellcode的第一個指令，那函數返回時就能執 行shellcode了。可是軟件的不一樣版本和不一樣的運行環境均可能影響這段shellcode在內存中的位置，那麼要構造這個RET是十分困難的。通常 都在RET和shellcode之間填充大量的NOP指令，使得exploit有更強的通用性。 

├———————┤<—低端內存區域 
│ …… │ 
├———————┤<—由exploit填入數據的開始 
│ │ 
│ buffer │<—填入無用的數據 
│ │ 
├———————┤ 
│ RET │<—指向shellcode，或NOP指令的範圍 
├———————┤ 
│ NOP │ 
│ …… │<—填入的NOP指令，是RET可指向的範圍 
│ NOP │ 
├———————┤ 
│ │ 
│ shellcode │ 
│ │ 
├———————┤<—由exploit填入數據的結束 
│ …… │ 
├———————┤<—高端內存區域 

windows下的動態數據除了可存放在棧中，還能夠存放在堆中。瞭解C++的朋友都知道，C++可使用new關鍵字來動態分配內存。來看下面的C++代碼： 

#include <stdio.h> 
#include <iostream.h> 
#include <windows.h> 

void func() 
{ 
char *buffer=new char[128]; 
char bufflocal[128]; 
static char buffstatic[128]; 
printf("0x%08x\n",buffer); //打印堆中變量的內存地址 
printf("0x%08x\n",bufflocal); //打印本地變量的內存地址 
printf("0x%08x\n",buffstatic); //打印靜態變量的內存地址 
} 

void main() 
{ 
func(); 
return; 
} 

程序執行結果爲： 

0x004107d0 
0x0012ff04 
0x004068c0 

能夠發現用new關鍵字分配的內存即不在棧中，也不在靜態數據區。VC編譯器是經過windows下的「堆(heap)」來實現new關鍵字的內存動態分配。在講「堆」以前，先來了解一下和「堆」有關的幾個API函數： 

HeapAlloc 在堆中申請內存空間 
HeapCreate 建立一個新的堆對象 
HeapDestroy 銷燬一個堆對象 
HeapFree 釋放申請的內存 
HeapWalk 枚舉堆對象的全部內存塊 
GetProcessHeap 取得進程的默認堆對象 
GetProcessHeaps 取得進程全部的堆對象 
LocalAlloc 
GlobalAlloc 

當進程初始化時，系統會自動爲進程建立一個默認堆，這個堆默認所佔內存的大小爲1M。堆對象由系統進行管理，它在內存中以鏈式結構存在。經過下面的代碼能夠經過堆動態申請內存空間： 

HANDLE hHeap=GetProcessHeap(); 
char *buff=HeapAlloc(hHeap,0,8); 

其中hHeap是堆對象的句柄，buff是指向申請的內存空間的地址。那這個hHeap到底是什麼呢？它的值有什麼意義嗎？看看下面這段代碼吧： 

#pragma comment(linker,"/entry:main") //定義程序的入口 
#include <windows.h> 

_CRTIMP int (__cdecl *printf)(const char *, ...); //定義STL函數printf 
/*--------------------------------------------------------------------------- 
寫到這裏，咱們順便來複習一下前面所講的知識： 
(*注)printf函數是C語言的標準函數庫中函數，VC的標準函數庫由msvcrt.dll模塊實現。 
由 函數定義可見，printf的參數個數是可變的，函數內部沒法預先知道調用者壓入的參數個數，函數只能經過分析第一個參數字符串的格式來得到壓入參數的信 息，因爲這裏參數的個數是動態的，因此必須由調用者來平衡堆棧，這裏便使用了__cdecl調用規則。BTW，Windows系統的API函數基本上是 __stdcall調用形式，只有一個API例外，那就是wsprintf，它使用__cdecl調用規則，同printf函數同樣，這是因爲它的參數個 數是可變的緣故。 
---------------------------------------------------------------------------*/ 
void main() 
{ 
HANDLE hHeap=GetProcessHeap(); 
char *buff=HeapAlloc(hHeap,0,0x10); 
char *buff2=HeapAlloc(hHeap,0,0x10); 
HMODULE hMsvcrt=LoadLibrary("msvcrt.dll"); 
printf=(void *)GetProcAddress(hMsvcrt,"printf"); 
printf("0x%08x\n",hHeap); 
printf("0x%08x\n",buff); 
printf("0x%08x\n\n",buff2); 
} 

執行結果爲： 

0x00130000 
0x00133100 
0x00133118 

hHeap的值怎麼和那個buff的值那麼接近呢？其實hHeap這個句柄就是指向HEAP首部的地址。在進程的用戶區存着一個叫PEB(進程環境 塊)的結構，這個結構中存放着一些有關進程的重要信息，其中在PEB首地址偏移0x18處存放的ProcessHeap就是進程默認堆的地址，而偏移 0x90處存放了指向進程全部堆的地址列表的指針。windows有不少API都使用進程的默認堆來存放動態數據，如windows 2000下的全部 ANSI版本的函數都是在默認堆中申請內存來轉換ANSI字符串到Unicode字符串的。對一個堆的訪問是順序進行的，同一時刻只能有一個線程訪問堆中 的數據，當多個線程同時有訪問要求時，只能排隊等待，這樣便形成程序執行效率降低。 

最後來講說內存中的數據對齊。所位數據對齊，是指數據所在的內存地址必須是該數據長度的整數倍，DWORD數據的內存起始地址能被4除盡，WORD 數據的內存起始地址能被2除盡，x86 CPU能直接訪問對齊的數據，當他試圖訪問一個未對齊的數據時，會在內部進行一系列的調整，這些調整對於程序來講 是透明的，可是會下降運行速度，因此編譯器在編譯程序時會盡可能保證數據對齊。一樣一段代碼，咱們來看看用VC、Dev-C++和lcc三個不一樣編譯器編譯 出來的程序的執行結果： 

#include <stdio.h> 

int main() 
{ 
int a; 
char b; 
int c; 
printf("0x%08x\n",&a); 
printf("0x%08x\n",&b); 
printf("0x%08x\n",&c); 
return 0; 
} 

這是用VC編譯後的執行結果： 
0x0012ff7c 
0x0012ff7b 
0x0012ff80 
變量在內存中的順序：b(1字節)-a(4字節)-c(4字節)。 

這是用Dev-C++編譯後的執行結果： 
0x0022ff7c 
0x0022ff7b 
0x0022ff74 
變量在內存中的順序：c(4字節)-中間相隔3字節-b(佔1字節)-a(4字節)。 

這是用lcc編譯後的執行結果： 
0x0012ff6c 
0x0012ff6b 
0x0012ff64 
變量在內存中的順序：同上。 

三個編譯器都作到了數據對齊，可是後兩個編譯器顯然沒VC「聰明」，讓一個char佔了4字節，浪費內存哦。 

基礎知識： 
堆棧是一種簡單的數據結構，是一種只容許在其一端進行插入或刪除的線性表。容許插入或刪除操做的一端稱爲棧頂，另外一端 稱爲棧底，對堆棧的插入和刪除操做被稱爲入棧和出棧。有一組CPU指令能夠實現對進程的內存實現堆棧訪問。其中，POP指令實現出棧操做，PUSH指令實 現入棧操做。CPU的ESP寄存器存放當前線程的棧頂指針，EBP寄存器中保存當前線程的棧底指針。CPU的EIP寄存器存放下一個CPU指令存放的內存 地址，當CPU執行完當前的指令後，從EIP寄存器中讀取下一條指令的內存地址，而後繼續執行。 

參考：《Windows下的HEAP溢出及其利用》by: isno 
《windows核心編程》by: Jeffrey Richter 

摘要： 討論常見的堆性能問題以及如何防範它們。（共 9 頁）

前言
您是不是動態分配的 C/C++ 對象忠實且幸運的用戶？您是否在模塊間的往返通訊中頻繁地使用了「自動化」？您的程序是否因堆分配而 運行起來很慢？不只僅您遇到這樣的問題。幾乎全部項目早晚都會遇到堆問題。你們都想說，「個人代碼真正好，只是堆太慢」。那只是部分正確。更深刻理解堆及 其用法、以及會發生什麼問題，是頗有用的。

什麼是堆？
（若是您已經知道什麼是堆，能夠跳到「什麼是常見的堆性能問題？」部分）

在程序中，使用堆來動態分配和釋放對象。在下列狀況下，調用堆操做： 

事先不知道程序所需對象的數量和大小。

對象太大而不適合堆棧分配程序。
堆使用了在運行時分配給代碼和堆棧的內存以外的部份內存。下圖給出了堆分配程序的不一樣層。

GlobalAlloc/GlobalFree：Microsoft Win32 堆調用，這些調用直接與每一個進程的默認堆進行對話。

LocalAlloc/LocalFree：Win32 堆調用（爲了與 Microsoft Windows NT 兼容），這些調用直接與每一個進程的默認堆進行對話。

COM 的 IMalloc 分配程序（或 CoTaskMemAlloc / CoTaskMemFree）：函數使用每一個進程的默認堆。自動化程序使用「組件對象模型 (COM)」的分配程序，而申請的程序使用每一個進程堆。

C/C++ 運行時 (CRT) 分配程序：提供了 malloc() 和 free() 以及 new 和 delete 操做符。 如 Microsoft Visual Basic 和 Java 等語言也提供了新的操做符並使用垃圾收集來代替堆。CRT 建立本身的私有堆，駐留 在 Win32 堆的頂部。

Windows NT 中，Win32 堆是 Windows NT 運行時分配程序周圍的薄層。全部 API 轉發它們的請求給 NTDLL。

Windows NT 運行時分配程序提供 Windows NT 內的核心堆分配程序。它由具備 128 個大小從 8 到 1,024 字節的空閒列表的前端分配程序組成。後端分配程序使用虛擬內存來保留和提交頁。

在圖表的底部是「虛擬內存分配程序」，操做系統使用它來保留和提交頁。全部分配程序使用虛擬內存進行數據的存取。

分配和釋放塊不就那麼簡單嗎？爲什麼花費這麼長時間？

堆實現的注意事項
傳統上，操做系統和運行時庫是與堆的實現共存的。在一個進程的開始，操做系統建立一個默認堆，叫作「進程堆」。若是沒有其 他堆可以使用，則塊的分配使用「進程堆」。語言運行時也能在進程內建立單獨的堆。（例如，C 運行時建立它本身的堆。）除這些專用的堆外，應用程序或許多已 載入的動態連接庫 (DLL) 之一能夠建立和使用單獨的堆。Win32 提供一整套 API 來建立和使用私有堆。有關堆函數（英文）的詳盡指導，請參 見 MSDN。

當應用程序或 DLL 建立私有堆時，這些堆存在於進程空間，而且在進程內是可訪問的。從給定堆分配的數據將在同一個堆上釋放。（不能從一個堆分配而在另外一個堆釋放。）

在全部虛擬內存系統中，堆駐留在操做系統的「虛擬內存管理器」的頂部。語言運行時堆也駐留在虛擬內存頂部。某些狀況下，這些堆是操做系統堆中的層，而語言運行時堆則經過大塊的分配來執行本身的內存管理。不使用操做系統堆，而使用虛擬內存函數更利於堆的分配和塊的使用。

典型的堆實現由前、後端分配程序組成。前端分配程序維持固定大小塊的空閒列表。對於一次分配調用，堆嘗試從前端列表找到一個自由塊。若是失敗，堆被 迫從後端（保留和提交虛擬內存）分配一個大塊來知足請求。通用的實現有每塊分配的開銷，這將耗費執行週期，也減小了可以使用的存儲空間。

Knowledge Base 文章 Q10758，「用 calloc() 和 malloc() 管理內存」 （搜索文章編號）, 包含了有關 這些主題的更多背景知識。另外，有關堆實現和設計的詳細討論也可在下列著做中找 到：「Dynamic Storage Allocation: A Survey and Critical Review」，做 者 Paul R. Wilson、Mark S. Johnstone、 Michael Neely 和 David Boles；「International Workshop on Memory Management」, 做 者 Kinross, Scotland, UK, 1995 年 9 月( http://www.cs.utexas.edu/users/oops/papers.html )（英文）。

Windows NT 的實現（Windows NT 版本 4.0 和更新版本） 使用了 127 個大小從 8 到 1,024 字節 的 8 字節對齊塊空閒列表和一個「大塊」列表。「大塊」列表（空閒列表[0]） 保存大於 1,024 字節的塊。空閒列表容納了用雙向鏈表連接在一塊兒 的對象。默認狀況下，「進程堆」執行收集操做。（收集是將相鄰空閒塊合併成一個大塊的操做。）收集耗費了額外的週期，但減小了堆塊的內部碎片。

單一全局鎖保護堆，防止多線程式的使用。（請參見「Server Performance and Scalability Killers」中的第一個注意事項, George Reilly 所著，在 「MSDN Online Web Workshop」上（站點： http://msdn.microsoft.com/workshop/server/iis/tencom.asp （英文）。）單一全局鎖本質上是用來保護堆數據結構，防止跨多線程的隨機存取。若堆操做太頻繁，單一全局鎖會對性能有不利的影響。

什麼是常見的堆性能問題？
如下是您使用堆時會遇到的最多見問題： 

分配操做形成的速度減慢。光分配就耗費很長時間。最可能致使運行速度減慢緣由是空閒列表沒有塊，因此運行時分配程序代碼會耗費週期尋找較大的空閒塊，或從後端分配程序分配新塊。

釋放操做形成的速度減慢。釋放操做耗費較多週期，主要是啓用了收集操做。收集期間，每一個釋放操做「查找」它的相鄰塊，取出它們並構形成較大塊，而後再把此較大塊插入空閒列表。在查找期間，內存可能會隨機碰到，從而致使高速緩存不能命中，性能下降。

堆競爭形成的速度減慢。當兩個或多個線程同時訪問數據，並且一個線程繼續進行以前必須等待另外一個線程完成時就發生競爭。競爭老是致使麻煩； 這也是目前多處理器系統遇到的最大問題。當大量使用內存塊的應用程序或 DLL 以多線程方式運行（或運行於多處理器系統上）時將致使速度減慢。單一鎖定 的使用—經常使用的解決方案—意味着使用堆的全部操做是序列化的。當等待鎖定時序列化會引發線程切換上下文。能夠想象交叉路口閃爍的紅燈處走走停停致使的速度 減慢。 
競爭一般會致使線程和進程的上下文切換。上下文切換的開銷是很大的，但開銷更大的是數據從處理器高速緩存中丟失，以及後來線程復活時的數據重建。

堆破壞形成的速度減慢。形成堆破壞的緣由是應用程序對堆塊的不正確使用。一般情形包括釋放已釋放的堆塊或使用已釋放的堆塊，以及塊的越界重寫等明顯 問題。（破壞不在本文討論範圍以內。有關內存重寫和泄漏等其餘細節，請參見 Microsoft Visual C++(R) 調試文檔 。）

頻繁的分配和重分配形成的速度減慢。這是使用腳本語言時很是廣泛的現象。如字符串被反覆分配，隨重分配增加和釋放。不要這樣作，若是可能，儘可能分配大字符串和使用緩衝區。另外一種方法就是儘可能少用鏈接操做。
競爭是在分配和釋放操做中致使速度減慢的問題。理想狀況下，但願使用沒有競爭和快速分配/釋放的堆。惋惜，如今尚未這樣的通用堆，也許未來會有。

在全部的服務器系統中（如 IIS、MSProxy、DatabaseStacks、網絡服務器、 Exchange 和其餘）, 堆鎖定實在是個大瓶頸。處理器數越多，競爭就越會惡化。

儘可能減小堆的使用
如今您明白使用堆時存在的問題了，難道您不想擁有能解決這些問題的超級魔棒嗎？我可但願有。但沒有魔法能使堆運行加快—所以不要指望在產品出貨以前的最後一星期可以大爲改觀。若是提早規劃堆策略，狀況將會大大好轉。調整使用堆的方法，減小對堆的操做是提升性能的良方。

如何減小使用堆操做？經過利用數據結構內的位置可減小堆操做的次數。請考慮下列實例：

struct ObjectA {
   // objectA 的數據 
}

struct ObjectB {
   // objectB 的數據 
}

// 同時使用 objectA 和 objectB

//
// 使用指針 
//
struct ObjectB {
   struct ObjectA * pObjA;
   // objectB 的數據 
}

//
// 使用嵌入
//
struct ObjectB {
   struct ObjectA pObjA;
   // objectB 的數據 
}

//
// 集合 – 在另外一對象內使用 objectA 和 objectB
//

struct ObjectX {
   struct ObjectA  objA;
   struct ObjectB  objB;
}

避免使用指針關聯兩個數據結構。若是使用指針關聯兩個數據結構，前面實例中的對象 A 和 B 將被分別分配和釋放。這會增長額外開銷—咱們要避免這種作法。

把帶指針的子對象嵌入父對象。當對象中有指針時，則意味着對象中有動態元素（百分之八十）和沒有引用的新位置。嵌入增長了位置從而減小了進一步分配/釋放的需求。這將提升應用程序的性能。

合併小對象造成大對象（聚合）。聚合減小分配和釋放的塊的數量。若是有幾個開發者，各自開發設計的不一樣部分，則最終會有許多小對象須要合併。集成的挑戰就是要找到正確的聚合邊界。

內聯緩衝區可以知足百分之八十的須要（aka 80-20 規則）。個別狀況下，須要內存緩衝區來保存字符串/二進制數據，但事先不知道總 字節數。估計並內聯一個大小能知足百分之八十須要的緩衝區。對剩餘的百分之二十，能夠分配一個新的緩衝區和指向這個緩衝區的指針。這樣，就減小分配和釋放 調用並增長數據的位置空間，從根本上提升代碼的性能。

在塊中分配對象（塊化）。塊化是以組的方式一次分配多個對象的方法。若是對列表的項連續跟蹤，例如對一個 {名稱，值} 對的列表，有兩種 選擇：選擇一是爲每個「名稱-值」對分配一個節點；選擇二是分配一個能容納（如五個）「名稱-值」對的結構。例如，通常狀況下，若是存儲四對，就可減小 節點的數量，若是須要額外的空間數量，則使用附加的鏈表指針。 
塊化是友好的處理器高速緩存，特別是對於 L1-高速緩存，由於它提供了增長的位置 —不用說對於塊分配，不少數據塊會在同一個虛擬頁中。

正確使用 _amblksiz。C 運行時 (CRT) 有它的自定義前端分配程序，該分配程序從後端（Win32 堆）分配大小爲 _amblksiz 的塊。將 _amblksiz 設置爲較高的值能潛在地減小對後端的調用次數。這隻對普遍使用 CRT 的程序適用。
使用上述技術將得到的好處會因對象類型、大小及工做量而有所不一樣。但總能在性能和可升縮性方面有所收穫。另外一方面，代碼會有點特殊，但若是通過深思熟慮，代碼仍是很容易管理的。

其餘提升性能的技術
下面是一些提升速度的技術： 

使用 Windows NT5 堆 
因爲幾個同事的努力和辛勤工做，1998 年初 Microsoft Windows(R) 2000 中有了幾個重大改進：

改進了堆代碼內的鎖定。堆代碼對每堆一個鎖。全局鎖保護堆數據結構，防止多線程式的使用。但不幸的是，在高通訊量的狀況下，堆仍受困於全局鎖，致使高競爭和低性能。Windows 2000 中，鎖內代碼的臨界區將競爭的可能性減到最小,從而提升了可伸縮性。

使用 「Lookaside」列表。堆數據結構對塊的全部空閒項使用了大小在 8 到 1,024 字節（以 8-字節遞增）的快速高速緩 存。快速高速緩存最初保護在全局鎖內。如今，使用 lookaside 列表來訪問這些快速高速緩存空閒列表。這些列表不要求鎖定，而是使用 64 位的 互鎖操做，所以提升了性能。

內部數據結構算法也獲得改進。
這些改進避免了對分配高速緩存的需求，但不排除其餘的優化。使用 Windows NT5 堆評估您 的代碼；它對小於 1,024 字節 (1 KB) 的塊（來自前端分配程序的塊）是最佳的。 GlobalAlloc() 和 LocalAlloc() 創建在同一堆上，是存取每一個進程堆的通用機制。若是但願得到高的局部性能，則使 用 Heap(R) API 來存取每一個進程堆，或爲分配操做建立本身的堆。若是須要對大塊操做，也能夠直接使 用 VirtualAlloc() / VirtualFree() 操做。

上述改進已在 Windows 2000 beta 2 和 Windows NT 4.0 SP4 中使用。改進後，堆鎖的競爭率顯著下降。這使 全部 Win32 堆的直接用戶受益。CRT 堆創建於 Win32 堆的頂部，但它使用本身的小塊堆，於是不能從 Windows NT 改進中受 益。（Visual C++ 版本 6.0 也有改進的堆分配程序。）

使用分配高速緩存 
分配高速緩存容許高速緩存分配的塊，以便未來重用。這可以減小對進程堆（或全局堆）的分配/釋放調用的次數，也容許最大限度的重用曾經分配的塊。另外，分配高速緩存容許收集統計信息,以便較好地理解對象在較高層次上的使用。

典型地，自定義堆分配程序在進程堆的頂部實現。自定義堆分配程序與系統堆的行爲很類似。主要的差異是它在進程堆的頂部爲分配的對象提供高速緩存。高 速緩存設計成一套固定大小（如 32 字節、64 字節、128 字節等）。這一個很好的策略，但這種自定義堆分配程序丟失與分配和釋放的對象相關的「語 義信息」。 

與自定義堆分配程序相反，「分配高速緩存」做爲每類分配高速緩存來實現。除可以提供自定義堆分配程序的全部好處以外，它們還可以保留大量語義信息。 每一個分配高速緩存處理程序與一個目標二進制對象關聯。它可以使用一套參數進行初始化，這些參數表示併發級別、對象大小和保持在空閒列表中的元素的數量等。 分配高速緩存處理程序對象維持本身的私有空閒實體池（不超過指定的閥值）並使用私有保護鎖。合在一塊兒，分配高速緩存和私有鎖減小了與主系統堆的通訊量，因 而提供了增長的併發、最大限度的重用和較高的可伸縮性。

須要使用清理程序來按期檢查全部分配高速緩存處理程序的活動狀況並回收未用的資源。若是發現沒有活動，將釋放分配對象的池，從而提升性能。

能夠審覈每一個分配/釋放活動。第一級信息包括對象、分配和釋放調用的總數。經過查看它們的統計信息能夠得出各個對象之間的語義關係。利用以上介紹的許多技術之一，這種關係能夠用來減小內存分配。

分配高速緩存也起到了調試助手的做用，幫助您跟蹤沒有徹底清除的對象數量。經過查看動態堆棧返回蹤影和除沒有清除的對象以外的簽名，甚至可以找到確切的失敗的調用者。

MP 堆 MP 堆是對多處理器友好的分佈式分配的程序包，在 Win32 SDK（Windows NT 4.0 和更新版本）中能夠得 到。最初由 JVert 實現，此處堆抽象創建在 Win32 堆程序包的頂部。MP 堆建立多個 Win32 堆，並試圖將分配調用分佈到不一樣堆，以減 少在全部單一鎖上的競爭。