Java 虛擬機器(JVM)是可執行Java程式碼的假想計算機。只要根據JVM規格描述將直譯器移植到特定的計算機上，就能保證經過編譯的任何Java程式碼能夠在該系統上執行。本文首先簡要介紹從Java檔案的編譯到最終執行的過程，隨後對JVM規格描述作一說明。
　　
　　一.Java原始檔的編譯、下載、解釋和執行
　　Java應用程式的開發週期包括編譯、下載、解釋和執行幾個部分。Java編譯程式將Java源程式翻譯為JVM可執行程式碼?位元組碼。這一編譯過程同C/C++的編譯有些不同。當C編譯器編譯生成一個物件的程式碼時，該程式碼是為在某一特定硬體平臺執行而產生的。因此，在編譯過程中，編譯程式通過查表將所有對符號的引用轉換為特定的記憶體偏移量，以保證程式執行。Java編譯器卻不將對變數和方法的引用編譯為數值引用，也不確定程式執行過程中的記憶體佈局，而是將這些符號引用資訊保留在位元組碼中，由直譯器在執行過程中創立記憶體佈局，然後再通過查表來確定一個方法所在的地址。這樣就有效的保證了Java的可移植性和安全性。
　　
　　執行JVM位元組碼的工作是由直譯器來完成的。解釋執行過程分三部進行：程式碼的裝入、程式碼的校驗和程式碼的執行。

裝入程式碼的工作由"類裝載器"（class loader）完成。類裝載器負責裝入執行一個程式需要的所有程式碼，這也包括程式程式碼中的類所繼承的類和被其呼叫的類。當類裝載器裝入一個類時，該類被放在自己的名字空間中。除了通過符號引用自己名字空間以外的類，類之間沒有其他辦法可以影響其他類。在本臺計算機上的所有類都在同一地址空間內，而所有從外部引進的類，都有一個自己獨立的名字空間。這使得本地類通過共享相同的名字空間獲得較高的執行效率，同時又保證它們與從外部引進的類不會相互影響。當裝入了執行程式需要的所有類後，直譯器便可確定整個可執行程式的記憶體佈局。直譯器為符號引用同特定的地址空間建立對應關係及查詢表。通過在這一階段確定程式碼的記憶體佈局，Java很好地解決了由超類改變而使子類崩潰的問題，同時也防止了程式碼對地址的非法訪問。
　　
　　隨後，被裝入的程式碼由位元組碼校驗器進行檢查。校驗器可發現運算元棧溢位，非法資料型別轉化等多種錯誤。通過校驗後，程式碼便開始執行了。
　　
　　Java位元組碼的執行有兩種方式：
　　1.即時編譯方式：直譯器先將位元組碼編譯成機器碼，然後再執行該機器碼。
　　2.解釋執行方式：直譯器通過每次解釋並執行一小段程式碼來完成Java位元組碼程式的所有操作。
　　通常採用的是第二種方法。由於JVM規格描述具有足夠的靈活性，這使得將位元組碼翻譯為機器程式碼的工作
　　
　　具有較高的效率。對於那些對執行速度要求較高的應用程式，直譯器可將Java位元組碼即時編譯為機器碼，從而很好地保證了Java程式碼的可移植性和高效能。
　　
　　二.JVM規格描述
　　JVM的設計目標是提供一個基於抽象規格描述的計算機模型，為解釋程式開發人員提很好的靈活性，同時也確保Java程式碼可在符合該規範的任何系統上執行。JVM對其實現的某些方面給出了具體的定義，特別是對Java可執行程式碼，即位元組碼(Bytecode)的格式給出了明確的規格。這一規格包括操作碼和運算元的語法和數值、識別符號的數值表示方式、以及Java類檔案中的Java物件、常量緩衝池在JVM的儲存映象。這些定義為JVM直譯器開發人員提供了所需的資訊和開發環境。Java的設計者希望給開發人員以隨心所欲使用Java的自由。
　　
　　JVM定義了控制Java程式碼解釋執行和具體實現的五種規格，它們是：
　　JVM指令系統
　　JVM暫存器
　　JVM棧結構
　　JVM碎片回收堆
　　JVM儲存區
　　
　　2.1JVM指令系統
　　
　　JVM指令系統同其他計算機的指令系統極其相似。Java指令也是由操作碼和運算元兩部分組成。操作碼為8位二進位制數，運算元進緊隨在操作碼的後面，其長度根據需要而不同。操作碼用於指定一條指令操作的性質（在這裡我們採用彙編符號的形式進行說明），如iload表示從儲存器中裝入一個整數，anewarray表示為一個新陣列分配空間，iand表示兩個整數的"與"，ret用於流程控制，表示從對某一方法的呼叫中返回。當長度大於8位時，運算元被分為兩個以上位元組存放。JVM採用了"big endian"的編碼方式來處理這種情況，即高位bits存放在低位元組中。這同 Motorola及其他的RISC CPU採用的編碼方式是一致的，而與Intel採用的"little endian "的編碼方式即低位bits存放在低位位元組的方法不同。
　　
　　Java指令系統是以Java語言的實現為目的設計的，其中包含了用於呼叫方法和監視多先程系統的指令。Java的8位操作碼的長度使得JVM最多有256種指令，目前已使用了160多種操作碼。
　　
　　2.2JVM指令系統
　　
　　所有的CPU均包含用於儲存系統狀態和處理器所需資訊的暫存器組。如果虛擬機器定義較多的暫存器，便可以從中得到更多的資訊而不必對棧或記憶體進行訪問，這有利於提高執行速度。然而，如果虛擬機器中的暫存器比實際CPU的暫存器多，在實現虛擬機器時就會佔用處理器大量的時間來用常規儲存器模擬暫存器，這反而會降低虛擬機器的效率。針對這種情況，JVM只設置了4個最為常用的暫存器。它們是：
　　pc程式計數器
　　optop運算元棧頂指標
　　frame當前執行環境指標
　　vars指向當前執行環境中第一個區域性變數的指標
　　所有暫存器均為32位。pc用於記錄程式的執行。optop,frame和vars用於記錄指向Java棧區的指標。
　　
　　2.3JVM棧結構
　　
　　作為基於棧結構的計算機，Java棧是JVM儲存資訊的主要方法。當JVM得到一個Java位元組碼應用程式後，便為該程式碼中一個類的每一個方法建立一個棧框架，以儲存該方法的狀態資訊。每個棧框架包括以下三類資訊：
　　區域性變數
　　執行環境
　　運算元棧
　　
　　區域性變數用於儲存一個類的方法中所用到的區域性變數。vars暫存器指向該變量表中的第一個區域性變數。
　　執行環境用於儲存直譯器對Java位元組碼進行解釋過程中所需的資訊。它們是：上次呼叫的方法、區域性變數指標和運算元棧的棧頂和棧底指標。執行環境是一個執行一個方法的控制中心。例如：如果直譯器要執行iadd(整數加法)，首先要從frame暫存器中找到當前執行環境，而後便從執行環境中找到運算元棧，從棧頂彈出兩個整數進行加法運算，最後將結果壓入棧頂。
　　運算元棧用於儲存運算所需運算元及運算的結果。
　　
　　2.4JVM碎片回收堆
　　
　　Java類的例項所需的儲存空間是在堆上分配的。直譯器具體承擔為類例項分配空間的工作。直譯器在為一個例項分配完儲存空間後，便開始記錄對該例項所佔用的記憶體區域的使用。一旦物件使用完畢，便將其回收到堆中。
　　在Java語言中，除了new語句外沒有其他方法為一物件申請和釋放記憶體。對記憶體進行釋放和回收的工作是由Java執行系統承擔的。這允許Java執行系統的設計者自己決定碎片回收的方法。在SUN公司開發的Java直譯器和Hot Java環境中，碎片回收用後臺執行緒的方式來執行。這不但為執行系統提供了良好的效能，而且使程式設計人員擺脫了自己控制記憶體使用的風險。
　　
　　2.5JVM儲存區
　　
　　JVM有兩類儲存區：常量緩衝池和方法區。常量緩衝池用於儲存類名稱、方法和欄位名稱以及串常量。方法區則用於儲存Java方法的位元組碼。對於這兩種儲存區域具體實現方式在JVM規格中沒有明確規定。這使得Java應用程式的儲存佈局必須在執行過程中確定，依賴於具體平臺的實現方式。
　　
　　JVM是為Java位元組碼定義的一種獨立於具體平臺的規格描述，是Java平臺獨立性的基礎。目前的JVM還存在一些限制和不足，有待於進一步的完善，但無論如何，JVM的思想是成功的。
　　
　　對比分析：如果把Java原程式想象成我們的C++原程式，Java原程式編譯後生成的位元組碼就相當於C++原程式編譯後的80x86的機器碼（二進位制程式檔案），JVM虛擬機器相當於80x86計算機系統,Java直譯器相當於80x86CPU。在80x86CPU上執行的是機器碼，在Java直譯器上執行的是Java位元組碼。
　　
　　Java直譯器相當於執行Java位元組碼的“CPU”,但該“CPU”不是通過硬體實現的，而是用軟體實現的。Java直譯器實際上就是特定的平臺下的一個應用程式。只要實現了特定平臺下的直譯器程式，Java位元組碼就能通過直譯器程式在該平臺下執行，這是Java跨平臺的根本。當前，並不是在所有的平臺下都有相應Java直譯器程式，這也是Java並不能在所有的平臺下都能執行的原因，它只能在已實現了Java直譯器程式的平臺下執行。

堆和棧的區別  

非本人作也!因非常經典,所以收歸旗下,與眾人閱之!原作者不祥!

堆和棧的區別
一、預備知識—程式的記憶體分配
一個由c/C++編譯的程式佔用的記憶體分為以下幾個部分
1、棧區（stack）— 由編譯器自動分配釋放 ，存放函式的引數值，區域性變數的值等。其操作方式類似於資料結構中的棧。
2、堆區（heap） — 一般由程式設計師分配釋放， 若程式設計師不釋放，程式結束時可能由OS回收 。注意它與資料結構中的堆是兩回事，分配方式倒是類似於連結串列，呵呵。
3、全域性區（靜態區）（static）—，全域性變數和靜態變數的儲存是放在一塊的，初始化的全域性變數和靜態變數在一塊區域， 未初始化的全域性變數和未初始化的靜態變數在相鄰的另一塊區域。 - 程式結束後有系統釋放 
4、文字常量區—常量字串就是放在這裡的。 程式結束後由系統釋放
5、程式程式碼區—存放函式體的二進位制程式碼。
二、例子程式 
這是一個前輩寫的，非常詳細 
//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.1申請方式 
stack: 
由系統自動分配。 例如，宣告在函式中一個區域性變數 int b; 系統自動在棧中為b開闢空間 
heap: 
需要程式設計師自己申請，並指明大小，在c中malloc函式 
如p1 = (char *)malloc(10); 
在C++中用new運算子 
如p2 = (char *)malloc(10); 
但是注意p1、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  

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  

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  
#include  

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  
#include  
#include  

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  

_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  

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 堆，並試圖將分配呼叫分佈到不同堆，以減少在所有單一鎖上的競爭。

本程式包是好的步驟 —一種改進的 MP-友好的自定義堆分配程式。但是，它不提供語義資訊和缺乏統計功能。通常將 MP 堆作為 SDK 庫來使用。如果使用這個 SDK 建立可重用元件，您將大大受益。但是，如果在每個 DLL 中建立這個 SDK 庫，將增加工作設定。

重新思考演算法和資料結構 
要在多處理器機器上伸縮，則演算法、實現、資料結構和硬體必須動態伸縮。請看最經常分配和釋放的資料結構。試問，“我能用不同的資料結構完成此工作嗎？”例如，如果在應用程式初始化時載入了只讀項的列表，這個列表不必是線性連結的列表。如果是動態分配的陣列就非常好。動態分配的陣列將減少記憶體中的堆塊和碎片，從而增強效能。

減少需要的小物件的數量減少堆分配程式的負載。例如，我們在伺服器的關鍵處理路徑上使用五個不同的物件，每個物件單獨分配和釋放。一起快取記憶體這些物件，把堆呼叫從五個減少到一個，顯著減少了堆的負載，特別當每秒鐘處理 1,000 個以上的請求時。

如果大量使用“Automation”結構，請考慮從主線程式碼中刪除“Automation BSTR”，或至少避免重複的 BSTR 操作。（BSTR 連線導致過多的重分配和分配/釋放操作。）

摘要
對所有平臺往往都存在堆實現，因此有巨大的開銷。每個單獨程式碼都有特定的要求，但設計能採用本文討論的基本理論來減少堆之間的相互作用。 

評價您的程式碼中堆的使用。

改進您的程式碼，以使用較少的堆呼叫：分析關鍵路徑和固定資料結構。

在實現自定義的包裝程式之前使用量化堆呼叫成本的方法。

如果對效能不滿意，請要求 OS 組改進堆。更多這類請求意味著對改進堆的更多關注。

要求 C 執行時組針對 OS 所提供的堆製作小巧的分配包裝程式。隨著 OS 堆的改進，C 執行時堆呼叫的成本將減小。