?
（最近感覺自己對(duì)java好無知啊！以下是轉(zhuǎn)自網(wǎng)絡(luò)上的文章，以供自己學(xué)習(xí)...........）
JAVA
文件編譯執(zhí)行與虛擬機(jī)(JVM)介紹
Java
虛擬機(jī)(JVM)是可運(yùn)行Java代碼的假想計(jì)算機(jī)。只要根據(jù)JVM規(guī)格描述將解釋器移植到特定的計(jì)算機(jī)上，就能保證經(jīng)過編譯的任何Java代碼能夠在該系統(tǒng)上運(yùn)行。本文首先簡(jiǎn)要介紹從Java文件的編譯到最終執(zhí)行的過程，隨后對(duì)JVM規(guī)格描述作一說明。
一.Java源文件的編譯、下載、解釋和執(zhí)行
Java應(yīng)用程序的開發(fā)周期包括編譯、下載、解釋和執(zhí)行幾個(gè)部分。Java編譯程序?qū)?span lang="EN-US">Java源程序翻譯為JVM可執(zhí)行代碼?字節(jié)碼。這一編譯過程同C/C++的編譯有些不同。當(dāng)C編譯器編譯生成一個(gè)對(duì)象的代碼時(shí)，該代碼是為在某一特定硬件平臺(tái)運(yùn)行而產(chǎn)生的。因此，在編譯過程中，編譯程序通過查表將所有對(duì)符號(hào)的引用轉(zhuǎn)換為特定的內(nèi)存偏移量，以保證程序運(yùn)行。Java編譯器卻不將對(duì)變量和方法的引用編譯為數(shù)值引用，也不確定程序執(zhí)行過程中的內(nèi)存布局，而是將這些符號(hào)引用信息保留在字節(jié)碼中，由解釋器在運(yùn)行過程中創(chuàng)立內(nèi)存布局，然后再通過查表來確定一個(gè)方法所在的地址。這樣就有效的保證了Java的可移植性和安全性。
運(yùn)行JVM字節(jié)碼的工作是由解釋器來完成的。解釋執(zhí)行過程分三部進(jìn)行：代碼的裝入、代碼的校驗(yàn)和代碼的執(zhí)行。裝入代碼的工作由"類裝載器"（class loader）完成。類裝載器負(fù)責(zé)裝入運(yùn)行一個(gè)程序需要的所有代碼，這也包括程序代碼中的類所繼承的類和被其調(diào)用的類。當(dāng)類裝載器裝入一個(gè)類時(shí)，該類被放在自己的名字空間中。除了通過符號(hào)引用自己名字空間以外的類，類之間沒有其他辦法可以影響其他類。在本臺(tái)計(jì)算機(jī)上的所有類都在同一地址空間內(nèi)，而所有從外部引進(jìn)的類，都有一個(gè)自己獨(dú)立的名字空間。這使得本地類通過共享相同的名字空間獲得較高的運(yùn)行效率，同時(shí)又保證它們與從外部引進(jìn)的類不會(huì)相互影響。當(dāng)裝入了運(yùn)行程序需要的所有類后，解釋器便可確定整個(gè)可執(zhí)行程序的內(nèi)存布局。解釋器為符號(hào)引用同特定的地址空間建立對(duì)應(yīng)關(guān)系及查詢表。通過在這一階段確定代碼的內(nèi)存布局，Java很好地解決了由超類改變而使子類崩潰的問題，同時(shí)也防止了代碼對(duì)地址的非法訪問。
隨后，被裝入的代碼由字節(jié)碼校驗(yàn)器進(jìn)行檢查。校驗(yàn)器可發(fā)現(xiàn)操作數(shù)棧溢出，非法數(shù)據(jù)類型轉(zhuǎn)化等多種錯(cuò)誤。通過校驗(yàn)后，代碼便開始執(zhí)行了。
Java字節(jié)碼的執(zhí)行有兩種方式：
1.即時(shí)編譯方式：解釋器先將字節(jié)碼編譯成機(jī)器碼，然后再執(zhí)行該機(jī)器碼。
2.解釋執(zhí)行方式：解釋器通過每次解釋并執(zhí)行一小段代碼來完成Java字節(jié)碼程序的所有操作。
通常采用的是第二種方法。由于JVM規(guī)格描述具有足夠的靈活性，這使得將字節(jié)碼翻譯為機(jī)器代碼的工作
具有較高的效率。對(duì)于那些對(duì)運(yùn)行速度要求較高的應(yīng)用程序，解釋器可將Java字節(jié)碼即時(shí)編譯為機(jī)器碼，從而很好地保證了Java代碼的可移植性和高性能。
二.JVM規(guī)格描述
JVM的設(shè)計(jì)目標(biāo)是提供一個(gè)基于抽象規(guī)格描述的計(jì)算機(jī)模型，為解釋程序開發(fā)人員提很好的靈活性，同時(shí)也確保Java代碼可在符合該規(guī)范的任何系統(tǒng)上運(yùn)行。JVM對(duì)其實(shí)現(xiàn)的某些方面給出了具體的定義，特別是對(duì)Java可執(zhí)行代碼，即字節(jié)碼(Bytecode)的格式給出了明確的規(guī)格。這一規(guī)格包括操作碼和操作數(shù)的語(yǔ)法和數(shù)值、標(biāo)識(shí)符的數(shù)值表示方式、以及Java類文件中的Java對(duì)象、常量緩沖池在JVM的存儲(chǔ)映象。這些定義為JVM解釋器開發(fā)人員提供了所需的信息和開發(fā)環(huán)境。Java的設(shè)計(jì)者希望給開發(fā)人員以隨心所欲使用Java的自由。
JVM定義了控制Java代碼解釋執(zhí)行和具體實(shí)現(xiàn)的五種規(guī)格，它們是：
JVM指令系統(tǒng)
JVM寄存器
JVM棧結(jié)構(gòu)
JVM碎片回收堆
JVM存儲(chǔ)區(qū)
2.1JVM指令系統(tǒng)
JVM指令系統(tǒng)同其他計(jì)算機(jī)的指令系統(tǒng)極其相似。Java指令也是由操作碼和操作數(shù)兩部分組成。操作碼為8位二進(jìn)制數(shù)，操作數(shù)進(jìn)緊隨在操作碼的后面，其長(zhǎng)度根據(jù)需要而不同。操作碼用于指定一條指令操作的性質(zhì)（在這里我們采用匯編符號(hào)的形式進(jìn)行說明），如iload表示從存儲(chǔ)器中裝入一個(gè)整數(shù)，anewarray表示為一個(gè)新數(shù)組分配空間，iand表示兩個(gè)整數(shù)的"與"，ret用于流程控制，表示從對(duì)某一方法的調(diào)用中返回。當(dāng)長(zhǎng)度大于8位時(shí)，操作數(shù)被分為兩個(gè)以上字節(jié)存放。JVM采用了"big endian"的編碼方式來處理這種情況，即高位bits存放在低字節(jié)中。這同 Motorola及其他的RISC CPU采用的編碼方式是一致的，而與Intel采用的"little endian "的編碼方式即低位bits存放在低位字節(jié)的方法不同。
Java指令系統(tǒng)是以Java語(yǔ)言的實(shí)現(xiàn)為目的設(shè)計(jì)的，其中包含了用于調(diào)用方法和監(jiān)視多先程系統(tǒng)的指令。Java的8位操作碼的長(zhǎng)度使得JVM最多有256種指令，目前已使用了160多種操作碼。
2.2JVM指令系統(tǒng)
所有的CPU均包含用于保存系統(tǒng)狀態(tài)和處理器所需信息的寄存器組。如果虛擬機(jī)定義較多的寄存器，便可以從中得到更多的信息而不必對(duì)棧或內(nèi)存進(jìn)行訪問，這有利于提高運(yùn)行速度。然而，如果虛擬機(jī)中的寄存器比實(shí)際CPU的寄存器多，在實(shí)現(xiàn)虛擬機(jī)時(shí)就會(huì)占用處理器大量的時(shí)間來用常規(guī)存儲(chǔ)器模擬寄存器，這反而會(huì)降低虛擬機(jī)的效率。針對(duì)這種情況，JVM只設(shè)置了4個(gè)最為常用的寄存器。它們是：
pc程序計(jì)數(shù)器
optop操作數(shù)棧頂指針
frame當(dāng)前執(zhí)行環(huán)境指針
vars指向當(dāng)前執(zhí)行環(huán)境中第一個(gè)局部變量的指針
所有寄存器均為32位。pc用于記錄程序的執(zhí)行。optop,frame和vars用于記錄指向Java棧區(qū)的指針。
2.3JVM棧結(jié)構(gòu)
作為基于棧結(jié)構(gòu)的計(jì)算機(jī)，Java棧是JVM存儲(chǔ)信息的主要方法。當(dāng)JVM得到一個(gè)Java字節(jié)碼應(yīng)用程序后，便為該代碼中一個(gè)類的每一個(gè)方法創(chuàng)建一個(gè)棧框架，以保存該方法的狀態(tài)信息。每個(gè)棧框架包括以下三類信息：
局部變量
執(zhí)行環(huán)境
操作數(shù)棧
局部變量用于存儲(chǔ)一個(gè)類的方法中所用到的局部變量。vars寄存器指向該變量表中的第一個(gè)局部變量。
執(zhí)行環(huán)境用于保存解釋器對(duì)Java字節(jié)碼進(jìn)行解釋過程中所需的信息。它們是：上次調(diào)用的方法、局部變量指針和操作數(shù)棧的棧頂和棧底指針。執(zhí)行環(huán)境是一個(gè)執(zhí)行一個(gè)方法的控制中心。例如：如果解釋器要執(zhí)行iadd(整數(shù)加法)，首先要從frame寄存器中找到當(dāng)前執(zhí)行環(huán)境，而后便從執(zhí)行環(huán)境中找到操作數(shù)棧，從棧頂彈出兩個(gè)整數(shù)進(jìn)行加法運(yùn)算，最后將結(jié)果壓入棧頂。
操作數(shù)棧用于存儲(chǔ)運(yùn)算所需操作數(shù)及運(yùn)算的結(jié)果。
2.4JVM碎片回收堆
Java類的實(shí)例所需的存儲(chǔ)空間是在堆上分配的。解釋器具體承擔(dān)為類實(shí)例分配空間的工作。解釋器在為一個(gè)實(shí)例分配完存儲(chǔ)空間后，便開始記錄對(duì)該實(shí)例所占用的內(nèi)存區(qū)域的使用。一旦對(duì)象使用完畢，便將其回收到堆中。
在Java語(yǔ)言中，除了new語(yǔ)句外沒有其他方法為一對(duì)象申請(qǐng)和釋放內(nèi)存。對(duì)內(nèi)存進(jìn)行釋放和回收的工作是由Java運(yùn)行系統(tǒng)承擔(dān)的。這允許Java運(yùn)行系統(tǒng)的設(shè)計(jì)者自己決定碎片回收的方法。在SUN公司開發(fā)的Java解釋器和Hot Java環(huán)境中，碎片回收用后臺(tái)線程的方式來執(zhí)行。這不但為運(yùn)行系統(tǒng)提供了良好的性能，而且使程序設(shè)計(jì)人員擺脫了自己控制內(nèi)存使用的風(fēng)險(xiǎn)。
2.5JVM存儲(chǔ)區(qū)
JVM有兩類存儲(chǔ)區(qū)：常量緩沖池和方法區(qū)。常量緩沖池用于存儲(chǔ)類名稱、方法和字段名稱以及串常量。方法區(qū)則用于存儲(chǔ)Java方法的字節(jié)碼。對(duì)于這兩種存儲(chǔ)區(qū)域具體實(shí)現(xiàn)方式在JVM規(guī)格中沒有明確規(guī)定。這使得Java應(yīng)用程序的存儲(chǔ)布局必須在運(yùn)行過程中確定，依賴于具體平臺(tái)的實(shí)現(xiàn)方式。
JVM是為Java字節(jié)碼定義的一種獨(dú)立于具體平臺(tái)的規(guī)格描述，是Java平臺(tái)獨(dú)立性的基礎(chǔ)。目前的JVM還存在一些限制和不足，有待于進(jìn)一步的完善，但無論如何，JVM的思想是成功的。
對(duì)比分析：如果把Java原程序想象成我們的C++原程序，Java原程序編譯后生成的字節(jié)碼就相當(dāng)于C++原程序編譯后的80x86的機(jī)器碼（二進(jìn)制程序文件），JVM虛擬機(jī)相當(dāng)于80x86計(jì)算機(jī)系統(tǒng),Java解釋器相當(dāng)于80x86CPU。在80x86CPU上運(yùn)行的是機(jī)器碼，在Java解釋器上運(yùn)行的是Java字節(jié)碼。
Java解釋器相當(dāng)于運(yùn)行Java字節(jié)碼的“CPU”,但該“CPU”不是通過硬件實(shí)現(xiàn)的，而是用軟件實(shí)現(xiàn)的。Java解釋器實(shí)際上就是特定的平臺(tái)下的一個(gè)應(yīng)用程序。只要實(shí)現(xiàn)了特定平臺(tái)下的解釋器程序，Java字節(jié)碼就能通過解釋器程序在該平臺(tái)下運(yùn)行，這是Java跨平臺(tái)的根本。當(dāng)前，并不是在所有的平臺(tái)下都有相應(yīng)Java解釋器程序，這也是Java并不能在所有的平臺(tái)下都能運(yùn)行的原因，它只能在已實(shí)現(xiàn)了Java解釋器程序的平臺(tái)下運(yùn)行。
堆和棧的區(qū)別
?
非本人作也!因非常經(jīng)典,所以收歸旗下,與眾人閱之!原作者不祥!
堆和棧的區(qū)別
一、預(yù)備知識(shí)—程序的內(nèi)存分配
一個(gè)由c/C++編譯的程序占用的內(nèi)存分為以下幾個(gè)部分
1、棧區(qū)（stack）—?由編譯器自動(dòng)分配釋放?，存放函數(shù)的參數(shù)值，局部變量的值等。其操作方式類似于數(shù)據(jù)結(jié)構(gòu)中的棧。
2、堆區(qū)（heap）?—?一般由程序員分配釋放，?若程序員不釋放，程序結(jié)束時(shí)可能由OS回收?。注意它與數(shù)據(jù)結(jié)構(gòu)中的堆是兩回事，分配方式倒是類似于鏈表，呵呵。
3、全局區(qū)（靜態(tài)區(qū)）（static）—，全局變量和靜態(tài)變量的存儲(chǔ)是放在一塊的，初始化的全局變量和靜態(tài)變量在一塊區(qū)域，?未初始化的全局變量和未初始化的靜態(tài)變量在相鄰的另一塊區(qū)域。?-?程序結(jié)束后有系統(tǒng)釋放?
4、文字常量區(qū)—常量字符串就是放在這里的。?程序結(jié)束后由系統(tǒng)釋放
5、程序代碼區(qū)—存放函數(shù)體的二進(jìn)制代碼。
二、例子程序?
這是一個(gè)前輩寫的，非常詳細(xì)?
//main.cpp?
int?a?=?0;?全局初始化區(qū)?
char?*p1;?全局未初始化區(qū)?
main()?
{?
int?b;?棧?
char?s[]?=?"abc";?棧?
char?*p2;?棧?
char?*p3?=?"123456";?123456\0在常量區(qū)，p3在棧上。?
static?int?c?=0；?全局（靜態(tài)）初始化區(qū)?
p1?=?(char?*)malloc(10);?
p2?=?(char?*)malloc(20);?
分配得來得10和20字節(jié)的區(qū)域就在堆區(qū)。?
strcpy(p1,?"123456");?123456\0放在常量區(qū)，編譯器可能會(huì)將它與p3所指向的"123456"優(yōu)化成一個(gè)地方。?
}?
?
二、堆和棧的理論知識(shí)?
2.1申請(qǐng)方式?
stack:?
由系統(tǒng)自動(dòng)分配。?例如，聲明在函數(shù)中一個(gè)局部變量?int?b;?系統(tǒng)自動(dòng)在棧中為b開辟空間?
heap:?
需要程序員自己申請(qǐng)，并指明大小，在c中malloc函數(shù)?
如p1?=?(char?*)malloc(10);?
在C++中用new運(yùn)算符?
如p2?=?(char?*)malloc(10);?
但是注意p1、p2本身是在棧中的。?
2.2?
申請(qǐng)后系統(tǒng)的響應(yīng)?
棧：只要棧的剩余空間大于所申請(qǐng)空間，系統(tǒng)將為程序提供內(nèi)存，否則將報(bào)異常提示棧溢出。?
堆：首先應(yīng)該知道操作系統(tǒng)有一個(gè)記錄空閑內(nèi)存地址的鏈表，當(dāng)系統(tǒng)收到程序的申請(qǐng)時(shí)，?
會(huì)遍歷該鏈表，尋找第一個(gè)空間大于所申請(qǐng)空間的堆結(jié)點(diǎn)，然后將該結(jié)點(diǎn)從空閑結(jié)點(diǎn)鏈表中刪除，并將該結(jié)點(diǎn)的空間分配給程序，另外，對(duì)于大多數(shù)系統(tǒng)，會(huì)在這塊內(nèi)存空間中的首地址處記錄本次分配的大小，這樣，代碼中的delete語(yǔ)句才能正確的釋放本內(nèi)存空間。另外，由于找到的堆結(jié)點(diǎn)的大小不一定正好等于申請(qǐng)的大小，系統(tǒng)會(huì)自動(dòng)的將多余的那部分重新放入空閑鏈表中。?
2.3
申請(qǐng)大小的限制?
棧：在Windows下,棧是向低地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)，是一塊連續(xù)的內(nèi)存的區(qū)域。這句話的意思是棧頂?shù)牡刂泛蜅５淖畲笕萘渴窍到y(tǒng)預(yù)先規(guī)定好的，在WINDOWS下，棧的大小是2M（也有的說是1M，總之是一個(gè)編譯時(shí)就確定的常數(shù)），如果申請(qǐng)的空間超過棧的剩余空間時(shí)，將提示overflow。因此，能從棧獲得的空間較小。?
堆：堆是向高地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)，是不連續(xù)的內(nèi)存區(qū)域。這是由于系統(tǒng)是用鏈表來存儲(chǔ)的空閑內(nèi)存地址的，自然是不連續(xù)的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計(jì)算機(jī)系統(tǒng)中有效的虛擬內(nèi)存。由此可見，堆獲得的空間比較靈活，也比較大。?
2.4
申請(qǐng)效率的比較：?
棧由系統(tǒng)自動(dòng)分配，速度較快。但程序員是無法控制的。?
堆是由new分配的內(nèi)存，一般速度比較慢，而且容易產(chǎn)生內(nèi)存碎片,不過用起來最方便.?
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配內(nèi)存，他不是在堆，也不是在棧是直接在進(jìn)程的地址空間中保留一快內(nèi)存，雖然用起來最不方便。但是速度快，也最靈活。?
2.5
堆和棧中的存儲(chǔ)內(nèi)容?
棧：?在函數(shù)調(diào)用時(shí)，第一個(gè)進(jìn)棧的是主函數(shù)中后的下一條指令（函數(shù)調(diào)用語(yǔ)句的下一條可執(zhí)行語(yǔ)句）的地址，然后是函數(shù)的各個(gè)參數(shù)，在大多數(shù)的C編譯器中，參數(shù)是由右往左入棧的，然后是函數(shù)中的局部變量。注意靜態(tài)變量是不入棧的。?
當(dāng)本次函數(shù)調(diào)用結(jié)束后，局部變量先出棧，然后是參數(shù)，最后棧頂指針指向最開始存的地址，也就是主函數(shù)中的下一條指令，程序由該點(diǎn)繼續(xù)運(yùn)行。?
堆：一般是在堆的頭部用一個(gè)字節(jié)存放堆的大小。堆中的具體內(nèi)容有程序員安排。?
2.6
存取效率的比較?
char?s1[]?=?"aaaaaaaaaaaaaaa";?
char?*s2?=?"bbbbbbbbbbbbbbbbb";?
aaaaaaaaaaa
是在運(yùn)行時(shí)刻賦值的；?
而bbbbbbbbbbb是在編譯時(shí)就確定的；?
但是，在以后的存取中，在棧上的數(shù)組比指針?biāo)赶虻淖址?span lang="EN-US">(例如堆)快。?
比如：?
#include?
void?main()?
{?
char?a?=?1;?
char?c[]?=?"1234567890";?
char?*p?="1234567890";?
a?=?c[1];?
a?=?p[1];?
return;?
}?
對(duì)應(yīng)的匯編代碼?
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?
第一種在讀取時(shí)直接就把字符串中的元素讀到寄存器cl中，而第二種則要先把指針值讀到edx中，在根據(jù)edx讀取字符，顯然慢了。?
2.7
小結(jié)：?
堆和棧的區(qū)別可以用如下的比喻來看出：?
使用棧就象我們?nèi)ワ堭^里吃飯，只管點(diǎn)菜（發(fā)出申請(qǐng)）、付錢、和吃（使用），吃飽了就走，不必理會(huì)切菜、洗菜等準(zhǔn)備工作和洗碗、刷鍋等掃尾工作，他的好處是快捷，但是自由度小。?
使用堆就象是自己動(dòng)手做喜歡吃的菜肴，比較麻煩，但是比較符合自己的口味，而且自由度大。?
windows
進(jìn)程中的內(nèi)存結(jié)構(gòu)
在閱讀本文之前，如果你連堆棧是什么多不知道的話，請(qǐng)先閱讀文章后面的基礎(chǔ)知識(shí)。?
接觸過編程的人都知道，高級(jí)語(yǔ)言都能通過變量名來訪問內(nèi)存中的數(shù)據(jù)。那么這些變量在內(nèi)存中是如何存放的呢？程序又是如何使用這些變量的呢？下面就會(huì)對(duì)此進(jìn)行深入的討論。下文中的C語(yǔ)言代碼如沒有特別聲明，默認(rèn)都使用VC編譯的release版。?
首先，來了解一下?C?語(yǔ)言的變量是如何在內(nèi)存分部的。C?語(yǔ)言有全局變量(Global)、本地變量(Local)，靜態(tài)變量(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;?
//
打印出各個(gè)變量的內(nèi)存地址?
printf("0x%08x\n",&v1);?//
打印各本地變量的內(nèi)存地址?
printf("0x%08x\n",&v2);?
printf("0x%08x\n\n",&v3);?
printf("0x%08x\n",&g1);?//打印各全局變量的內(nèi)存地址?
printf("0x%08x\n",&g2);?
printf("0x%08x\n\n",&g3);?
printf("0x%08x\n",&s1);?//打印各靜態(tài)變量的內(nèi)存地址?
printf("0x%08x\n",&s2);?
printf("0x%08x\n\n",&s3);?
return?0;?
}?
編譯后的執(zhí)行結(jié)果是：?
0x0012ff78?
0x0012ff7c?
0x0012ff80?
0x004068d0?
0x004068d4?
0x004068d8?
0x004068dc?
0x004068e0?
0x004068e4?
輸出的結(jié)果就是變量的內(nèi)存地址。其中v1,v2,v3是本地變量，g1,g2,g3是全局變量，s1,s2,s3是靜態(tài)變量。你可以看到這些變量在內(nèi)存是連續(xù)分布的，但是本地變量和全局變量分配的內(nèi)存地址差了十萬八千里，而全局變量和靜態(tài)變量分配的內(nèi)存是連續(xù)的。這是因?yàn)楸镜刈兞亢腿?span lang="EN-US">/靜態(tài)變量是分配在不同類型的內(nèi)存區(qū)域中的結(jié)果。對(duì)于一個(gè)進(jìn)程的內(nèi)存空間而言，可以在邏輯上分成3個(gè)部份：代碼區(qū)，靜態(tài)數(shù)據(jù)區(qū)和動(dòng)態(tài)數(shù)據(jù)區(qū)。動(dòng)態(tài)數(shù)據(jù)區(qū)一般就是“堆棧”。“棧(stack)”和“堆(heap)”是兩種不同的動(dòng)態(tài)數(shù)據(jù)區(qū)，棧是一種線性結(jié)構(gòu)，堆是一種鏈?zhǔn)浇Y(jié)構(gòu)。進(jìn)程的每個(gè)線程都有私有的“棧”，所以每個(gè)線程雖然代碼一樣，但本地變量的數(shù)據(jù)都是互不干擾。一個(gè)堆棧可以通過“基地址”和“棧頂”地址來描述。全局變量和靜態(tài)變量分配在靜態(tài)數(shù)據(jù)區(qū)，本地變量分配在動(dòng)態(tài)數(shù)據(jù)區(qū)，即堆棧中。程序通過堆棧的基地址和偏移量來訪問本地變量。?
├———————┤
低端內(nèi)存區(qū)域?
│?……?│?
├———————┤?
│?動(dòng)態(tài)數(shù)據(jù)區(qū)?│?
├———————┤?
│?……?│?
├———————┤?
│?代碼區(qū)?│?
├———————┤?
│?靜態(tài)數(shù)據(jù)區(qū)?│?
├———————┤?
│?……?│?
├———————┤高端內(nèi)存區(qū)域?
堆棧是一個(gè)先進(jìn)后出的數(shù)據(jù)結(jié)構(gòu)，棧頂?shù)刂房偸切∮诘扔跅５幕刂贰Ｎ覀兛梢韵攘私庖幌潞瘮?shù)調(diào)用的過程，以便對(duì)堆棧在程序中的作用有更深入的了解。不同的語(yǔ)言有不同的函數(shù)調(diào)用規(guī)定，這些因素有參數(shù)的壓入規(guī)則和堆棧的平衡。windows?API的調(diào)用規(guī)則和ANSI?C的函數(shù)調(diào)用規(guī)則是不一樣的，前者由被調(diào)函數(shù)調(diào)整堆棧，后者由調(diào)用者調(diào)整堆棧。兩者通過“__stdcall”和“__cdecl”前綴區(qū)分。先看下面這段代碼：?
#include??
void?__stdcall?func(int?param1,int?param2,int?param3)?
{?
int?var1=param1;?
int?var2=param2;?
int?var3=param3;?
printf("0x%08x\n",?m1);?//
打印出各個(gè)變量的內(nèi)存地址?
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;?
}?
編譯后的執(zhí)行結(jié)果是：?
0x0012ff78?
0x0012ff7c?
0x0012ff80?
0x0012ff68?
0x0012ff6c?
0x0012ff70?
├———————┤<—
函數(shù)執(zhí)行時(shí)的棧頂（ESP）、低端內(nèi)存區(qū)域?
│?……?│?
├———————┤?
│?var?1?│?
├———————┤?
│?var?2?│?
├———————┤?
│?var?3?│?
├———————┤?
│?RET?│?
├———————┤<—“__cdecl”函數(shù)返回后的棧頂（ESP）?
│?parameter?1?│?
├———————┤?
│?parameter?2?│?
├———————┤?
│?parameter?3?│?
├———————┤<—“__stdcall”函數(shù)返回后的棧頂（ESP）?
│?……?│?
├———————┤<—棧底（基地址?EBP）、高端內(nèi)存區(qū)域?
上圖就是函數(shù)調(diào)用過程中堆棧的樣子了。首先，三個(gè)參數(shù)以從又到左的次序壓入堆棧，先壓“param3”，再壓“param2”，最后壓入“param1”；然后壓入函數(shù)的返回地址(RET)，接著跳轉(zhuǎn)到函數(shù)地址接著執(zhí)行（這里要補(bǔ)充一點(diǎn)，介紹UNIX下的緩沖溢出原理的文章中都提到在壓入RET后，繼續(xù)壓入當(dāng)前EBP，然后用當(dāng)前ESP代替EBP。然而，有一篇介紹windows下函數(shù)調(diào)用的文章中說，在windows下的函數(shù)調(diào)用也有這一步驟，但根據(jù)我的實(shí)際調(diào)試，并未發(fā)現(xiàn)這一步，這還可以從param3和var1之間只有4字節(jié)的間隙這點(diǎn)看出來）；第三步，將棧頂(ESP)減去一個(gè)數(shù)，為本地變量分配內(nèi)存空間，上例中是減去12字節(jié)(ESP=ESP-3*4，每個(gè)int變量占用4個(gè)字節(jié))；接著就初始化本地變量的內(nèi)存空間。由于“__stdcall”調(diào)用由被調(diào)函數(shù)調(diào)整堆棧，所以在函數(shù)返回前要恢復(fù)堆棧，先回收本地變量占用的內(nèi)存(ESP=ESP+3*4)，然后取出返回地址，填入EIP寄存器，回收先前壓入?yún)?shù)占用的內(nèi)存(ESP=ESP+3*4)，繼續(xù)執(zhí)行調(diào)用者的代碼。參見下列匯編代碼：?
;--------------func?
函數(shù)的匯編代碼-------------------?
:00401000?83EC0C?sub?esp,?0000000C?//
創(chuàng)建本地變量的內(nèi)存空間?
: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?;
恢復(fù)堆棧，回收本地變量的內(nèi)存空間?
:00401078?C3?ret?000C?;函數(shù)返回，恢復(fù)參數(shù)占用的內(nèi)存空間?
;如果是“__cdecl”的話，這里是“ret”，堆棧將由調(diào)用者恢復(fù)?
;-------------------
函數(shù)結(jié)束-------------------------?
;--------------
主程序調(diào)用func函數(shù)的代碼--------------?
:00401080?6A03?push?00000003?//
壓入?yún)?shù)param3?
:00401082?6A02?push?00000002?//壓入?yún)?shù)param2?
:00401084?6A01?push?00000001?//壓入?yún)?shù)param1?
:00401086?E875FFFFFF?call?00401000?//調(diào)用func函數(shù)?
;如果是“__cdecl”的話，將在這里恢復(fù)堆棧，“add?esp,?0000000C”?
聰明的讀者看到這里，差不多就明白緩沖溢出的原理了。先來看下面的代碼：?
#include??
#include??
void?__stdcall?func()?
{?
char?lpBuff[8]="\0";?
strcat(lpBuff,"AAAAAAAAAAA");?
return;?
}?
int?main()?
{?
func();?
return?0;?
}?
編譯后執(zhí)行一下回怎么樣？哈，“"0x00414141"指令引用的"0x00000000"內(nèi)存。該內(nèi)存不能為"read"。”，“非法操作”嘍！"41"就是"A"的16進(jìn)制的ASCII碼了，那明顯就是strcat這句出的問題了。"lpBuff"的大小只有8字節(jié)，算進(jìn)結(jié)尾的\0，那strcat最多只能寫入7個(gè)"A"，但程序?qū)嶋H寫入了11個(gè)"A"外加1個(gè)\0。再來看看上面那幅圖，多出來的4個(gè)字節(jié)正好覆蓋了RET的所在的內(nèi)存空間，導(dǎo)致函數(shù)返回到一個(gè)錯(cuò)誤的內(nèi)存地址，執(zhí)行了錯(cuò)誤的指令。如果能精心構(gòu)造這個(gè)字符串，使它分成三部分，前一部份僅僅是填充的無意義數(shù)據(jù)以達(dá)到溢出的目的，接著是一個(gè)覆蓋RET的數(shù)據(jù)，緊接著是一段shellcode，那只要著個(gè)RET地址能指向這段shellcode的第一個(gè)指令，那函數(shù)返回時(shí)就能執(zhí)行shellcode了。但是軟件的不同版本和不同的運(yùn)行環(huán)境都可能影響這段shellcode在內(nèi)存中的位置，那么要構(gòu)造這個(gè)RET是十分困難的。一般都在RET和shellcode之間填充大量的NOP指令，使得exploit有更強(qiáng)的通用性。?
├———————┤<—
低端內(nèi)存區(qū)域?
│?……?│?
├———————┤<—由exploit填入數(shù)據(jù)的開始?
│?│?
│?buffer?│<—填入無用的數(shù)據(jù)?
│?│?
├———————┤?
│?RET?│<—指向shellcode，或NOP指令的范圍?
├———————┤?
│?NOP?│?
│?……?│<—填入的NOP指令，是RET可指向的范圍?
│?NOP?│?
├———————┤?
│?│?
│?shellcode?│?
│?│?
├———————┤<—由exploit填入數(shù)據(jù)的結(jié)束?
│?……?│?
├———————┤<—高端內(nèi)存區(qū)域?
windows
下的動(dòng)態(tài)數(shù)據(jù)除了可存放在棧中，還可以存放在堆中。了解C++的朋友都知道，C++可以使用new關(guān)鍵字來動(dòng)態(tài)分配內(nèi)存。來看下面的C++代碼：?
#include??
#include??
#include??
void?func()?
{?
char?*buffer=new?char[128];?
char?bufflocal[128];?
static?char?buffstatic[128];?
printf("0x%08x\n",buffer);?//
打印堆中變量的內(nèi)存地址?
printf("0x%08x\n",bufflocal);?//打印本地變量的內(nèi)存地址?
printf("0x%08x\n",buffstatic);?//打印靜態(tài)變量的內(nèi)存地址?
}?
void?main()?
{?
func();?
return;?
}?
程序執(zhí)行結(jié)果為：?
0x004107d0?
0x0012ff04?
0x004068c0?
可以發(fā)現(xiàn)用new關(guān)鍵字分配的內(nèi)存即不在棧中，也不在靜態(tài)數(shù)據(jù)區(qū)。VC編譯器是通過windows下的“堆(heap)”來實(shí)現(xiàn)new關(guān)鍵字的內(nèi)存動(dòng)態(tài)分配。在講“堆”之前，先來了解一下和“堆”有關(guān)的幾個(gè)API函數(shù)：?
HeapAlloc?
在堆中申請(qǐng)內(nèi)存空間?
HeapCreate?創(chuàng)建一個(gè)新的堆對(duì)象?
HeapDestroy?銷毀一個(gè)堆對(duì)象?
HeapFree?釋放申請(qǐng)的內(nèi)存?
HeapWalk?枚舉堆對(duì)象的所有內(nèi)存塊?
GetProcessHeap?取得進(jìn)程的默認(rèn)堆對(duì)象?
GetProcessHeaps?取得進(jìn)程所有的堆對(duì)象?
LocalAlloc?
GlobalAlloc?
當(dāng)進(jìn)程初始化時(shí)，系統(tǒng)會(huì)自動(dòng)為進(jìn)程創(chuàng)建一個(gè)默認(rèn)堆，這個(gè)堆默認(rèn)所占內(nèi)存的大小為1M。堆對(duì)象由系統(tǒng)進(jìn)行管理，它在內(nèi)存中以鏈?zhǔn)浇Y(jié)構(gòu)存在。通過下面的代碼可以通過堆動(dòng)態(tài)申請(qǐng)內(nèi)存空間：?
HANDLE?hHeap=GetProcessHeap();?
char?*buff=HeapAlloc(hHeap,0,8);?
其中hHeap是堆對(duì)象的句柄，buff是指向申請(qǐng)的內(nèi)存空間的地址。那這個(gè)hHeap究竟是什么呢？它的值有什么意義嗎？看看下面這段代碼吧：?
#pragma?comment(linker,"/entry:main")?//
定義程序的入口?
#include??
_CRTIMP?int?(__cdecl?*printf)(const?char?*,?...);?//
定義STL函數(shù)printf?
/*---------------------------------------------------------------------------?
寫到這里，我們順便來復(fù)習(xí)一下前面所講的知識(shí)：?
(*注)printf函數(shù)是C語(yǔ)言的標(biāo)準(zhǔn)函數(shù)庫(kù)中函數(shù)，VC的標(biāo)準(zhǔn)函數(shù)庫(kù)由msvcrt.dll模塊實(shí)現(xiàn)。?
由函數(shù)定義可見，printf的參數(shù)個(gè)數(shù)是可變的，函數(shù)內(nèi)部無法預(yù)先知道調(diào)用者壓入的參數(shù)個(gè)數(shù)，函數(shù)只能通過分析第一個(gè)參數(shù)字符串的格式來獲得壓入?yún)?shù)的信息，由于這里參數(shù)的個(gè)數(shù)是動(dòng)態(tài)的，所以必須由調(diào)用者來平衡堆棧，這里便使用了__cdecl調(diào)用規(guī)則。BTW，Windows系統(tǒng)的API函數(shù)基本上是__stdcall調(diào)用形式，只有一個(gè)API例外，那就是wsprintf，它使用__cdecl調(diào)用規(guī)則，同printf函數(shù)一樣，這是由于它的參數(shù)個(gè)數(shù)是可變的緣故。?
---------------------------------------------------------------------------*/?
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);?
}?
執(zhí)行結(jié)果為：?
0x00130000?
0x00133100?
0x00133118?
hHeap
的值怎么和那個(gè)buff的值那么接近呢？其實(shí)hHeap這個(gè)句柄就是指向HEAP首部的地址。在進(jìn)程的用戶區(qū)存著一個(gè)叫PEB(進(jìn)程環(huán)境塊)的結(jié)構(gòu)，這個(gè)結(jié)構(gòu)中存放著一些有關(guān)進(jìn)程的重要信息，其中在PEB首地址偏移0x18處存放的ProcessHeap就是進(jìn)程默認(rèn)堆的地址，而偏移0x90處存放了指向進(jìn)程所有堆的地址列表的指針。windows有很多API都使用進(jìn)程的默認(rèn)堆來存放動(dòng)態(tài)數(shù)據(jù)，如windows?2000下的所有ANSI版本的函數(shù)都是在默認(rèn)堆中申請(qǐng)內(nèi)存來轉(zhuǎn)換ANSI字符串到Unicode字符串的。對(duì)一個(gè)堆的訪問是順序進(jìn)行的，同一時(shí)刻只能有一個(gè)線程訪問堆中的數(shù)據(jù)，當(dāng)多個(gè)線程同時(shí)有訪問要求時(shí)，只能排隊(duì)等待，這樣便造成程序執(zhí)行效率下降。?
最后來說說內(nèi)存中的數(shù)據(jù)對(duì)齊。所位數(shù)據(jù)對(duì)齊，是指數(shù)據(jù)所在的內(nèi)存地址必須是該數(shù)據(jù)長(zhǎng)度的整數(shù)倍，DWORD數(shù)據(jù)的內(nèi)存起始地址能被4除盡，WORD數(shù)據(jù)的內(nèi)存起始地址能被2除盡，x86?CPU能直接訪問對(duì)齊的數(shù)據(jù)，當(dāng)他試圖訪問一個(gè)未對(duì)齊的數(shù)據(jù)時(shí)，會(huì)在內(nèi)部進(jìn)行一系列的調(diào)整，這些調(diào)整對(duì)于程序來說是透明的，但是會(huì)降低運(yùn)行速度，所以編譯器在編譯程序時(shí)會(huì)盡量保證數(shù)據(jù)對(duì)齊。同樣一段代碼，我們來看看用VC、Dev-C++和lcc三個(gè)不同編譯器編譯出來的程序的執(zhí)行結(jié)果：?
#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編譯后的執(zhí)行結(jié)果：?
0x0012ff7c?
0x0012ff7b?
0x0012ff80?
變量在內(nèi)存中的順序：b(1字節(jié))-a(4字節(jié))-c(4字節(jié))。?
這是用Dev-C++編譯后的執(zhí)行結(jié)果：?
0x0022ff7c?
0x0022ff7b?
0x0022ff74?
變量在內(nèi)存中的順序：c(4字節(jié))-中間相隔3字節(jié)-b(占1字節(jié))-a(4字節(jié))。?
這是用lcc編譯后的執(zhí)行結(jié)果：?
0x0012ff6c?
0x0012ff6b?
0x0012ff64?
變量在內(nèi)存中的順序：同上。?
三個(gè)編譯器都做到了數(shù)據(jù)對(duì)齊，但是后兩個(gè)編譯器顯然沒VC“聰明”，讓一個(gè)char占了4字節(jié)，浪費(fèi)內(nèi)存哦。?
基礎(chǔ)知識(shí)：?
堆棧是一種簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)，是一種只允許在其一端進(jìn)行插入或刪除的線性表。允許插入或刪除操作的一端稱為棧頂，另一端稱為棧底，對(duì)堆棧的插入和刪除操作被稱為入棧和出棧。有一組CPU指令可以實(shí)現(xiàn)對(duì)進(jìn)程的內(nèi)存實(shí)現(xiàn)堆棧訪問。其中，POP指令實(shí)現(xiàn)出棧操作，PUSH指令實(shí)現(xiàn)入棧操作。CPU的ESP寄存器存放當(dāng)前線程的棧頂指針，EBP寄存器中保存當(dāng)前線程的棧底指針。CPU的EIP寄存器存放下一個(gè)CPU指令存放的內(nèi)存地址，當(dāng)CPU執(zhí)行完當(dāng)前的指令后，從EIP寄存器中讀取下一條指令的內(nèi)存地址，然后繼續(xù)執(zhí)行。?
參考：《Windows下的HEAP溢出及其利用》by:?isno?
《windows核心編程》by:?Jeffrey?Richter?
摘要：?討論常見的堆性能問題以及如何防范它們。（共?9?頁(yè)）
前言
您是否是動(dòng)態(tài)分配的?C/C++?對(duì)象忠實(shí)且幸運(yùn)的用戶？您是否在模塊間的往返通信中頻繁地使用了“自動(dòng)化”？您的程序是否因堆分配而運(yùn)行起來很慢？不僅僅您遇到這樣的問題。幾乎所有項(xiàng)目遲早都會(huì)遇到堆問題。大家都想說，“我的代碼真正好，只是堆太慢”。那只是部分正確。更深入理解堆及其用法、以及會(huì)發(fā)生什么問題，是很有用的。
什么是堆？
（如果您已經(jīng)知道什么是堆，可以跳到“什么是常見的堆性能問題？”部分）
在程序中，使用堆來動(dòng)態(tài)分配和釋放對(duì)象。在下列情況下，調(diào)用堆操作：?
事先不知道程序所需對(duì)象的數(shù)量和大小。
對(duì)象太大而不適合堆棧分配程序。
堆使用了在運(yùn)行時(shí)分配給代碼和堆棧的內(nèi)存之外的部分內(nèi)存。下圖給出了堆分配程序的不同層。
nload="javascript:if(this.width>screen.width-333)this.width=screen.width-333" border=0 dypop="按此在新窗口瀏覽圖片">
GlobalAlloc/GlobalFree
：Microsoft?Win32?堆調(diào)用，這些調(diào)用直接與每個(gè)進(jìn)程的默認(rèn)堆進(jìn)行對(duì)話。
LocalAlloc/LocalFree
：Win32?堆調(diào)用（為了與?Microsoft?Windows?NT?兼容），這些調(diào)用直接與每個(gè)進(jìn)程的默認(rèn)堆進(jìn)行對(duì)話。
COM?
的?IMalloc?分配程序（或?CoTaskMemAlloc?/?CoTaskMemFree）：函數(shù)使用每個(gè)進(jìn)程的默認(rèn)堆。自動(dòng)化程序使用“組件對(duì)象模型?(COM)”的分配程序，而申請(qǐng)的程序使用每個(gè)進(jìn)程堆。
C/C++?
運(yùn)行時(shí)?(CRT)?分配程序：提供了?malloc()?和?free()?以及?new?和?delete?操作符。如?Microsoft?Visual?Basic?和?Java?等語(yǔ)言也提供了新的操作符并使用垃圾收集來代替堆。CRT?創(chuàng)建自己的私有堆，駐留在?Win32?堆的頂部。
Windows?NT?
中，Win32?堆是?Windows?NT?運(yùn)行時(shí)分配程序周圍的薄層。所有?API?轉(zhuǎn)發(fā)它們的請(qǐng)求給?NTDLL。
Windows?NT?
運(yùn)行時(shí)分配程序提供?Windows?NT?內(nèi)的核心堆分配程序。它由具有?128?個(gè)大小從?8?到?1,024?字節(jié)的空閑列表的前端分配程序組成。后端分配程序使用虛擬內(nèi)存來保留和提交頁(yè)。
在圖表的底部是“虛擬內(nèi)存分配程序”，操作系統(tǒng)使用它來保留和提交頁(yè)。所有分配程序使用虛擬內(nèi)存進(jìn)行數(shù)據(jù)的存取。
分配和釋放塊不就那么簡(jiǎn)單嗎？為何花費(fèi)這么長(zhǎng)時(shí)間？
堆實(shí)現(xiàn)的注意事項(xiàng)
傳統(tǒng)上，操作系統(tǒng)和運(yùn)行時(shí)庫(kù)是與堆的實(shí)現(xiàn)共存的。在一個(gè)進(jìn)程的開始，操作系統(tǒng)創(chuàng)建一個(gè)默認(rèn)堆，叫做“進(jìn)程堆”。如果沒有其他堆可使用，則塊的分配使用“進(jìn)程堆”。語(yǔ)言運(yùn)行時(shí)也能在進(jìn)程內(nèi)創(chuàng)建單獨(dú)的堆。（例如，C?運(yùn)行時(shí)創(chuàng)建它自己的堆。）除這些專用的堆外，應(yīng)用程序或許多已載入的動(dòng)態(tài)鏈接庫(kù)?(DLL)?之一可以創(chuàng)建和使用單獨(dú)的堆。Win32?提供一整套?API?來創(chuàng)建和使用私有堆。有關(guān)堆函數(shù)（英文）的詳盡指導(dǎo)，請(qǐng)參見?MSDN。
當(dāng)應(yīng)用程序或?DLL?創(chuàng)建私有堆時(shí)，這些堆存在于進(jìn)程空間，并且在進(jìn)程內(nèi)是可訪問的。從給定堆分配的數(shù)據(jù)將在同一個(gè)堆上釋放。（不能從一個(gè)堆分配而在另一個(gè)堆釋放。）
在所有虛擬內(nèi)存系統(tǒng)中，堆駐留在操作系統(tǒng)的“虛擬內(nèi)存管理器”的頂部。語(yǔ)言運(yùn)行時(shí)堆也駐留在虛擬內(nèi)存頂部。某些情況下，這些堆是操作系統(tǒng)堆中的層，而語(yǔ)言運(yùn)行時(shí)堆則通過大塊的分配來執(zhí)行自己的內(nèi)存管理。不使用操作系統(tǒng)堆，而使用虛擬內(nèi)存函數(shù)更利于堆的分配和塊的使用。
典型的堆實(shí)現(xiàn)由前、后端分配程序組成。前端分配程序維持固定大小塊的空閑列表。對(duì)于一次分配調(diào)用，堆嘗試從前端列表找到一個(gè)自由塊。如果失敗，堆被迫從后端（保留和提交虛擬內(nèi)存）分配一個(gè)大塊來滿足請(qǐng)求。通用的實(shí)現(xiàn)有每塊分配的開銷，這將耗費(fèi)執(zhí)行周期，也減少了可使用的存儲(chǔ)空間。
Knowledge?Base?
文章?Q10758，“用?calloc()?和?malloc()?管理內(nèi)存”?（搜索文章編號(hào)）,?包含了有關(guān)這些主題的更多背景知識(shí)。另外，有關(guān)堆實(shí)現(xiàn)和設(shè)計(jì)的詳細(xì)討論也可在下列著作中找到：“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?
的實(shí)現(xiàn)（Windows?NT?版本?4.0?和更新版本）?使用了?127?個(gè)大小從?8?到?1,024?字節(jié)的?8?字節(jié)對(duì)齊塊空閑列表和一個(gè)“大塊”列表。“大塊”列表（空閑列表[0]）?保存大于?1,024?字節(jié)的塊。空閑列表容納了用雙向鏈表鏈接在一起的對(duì)象。默認(rèn)情況下，“進(jìn)程堆”執(zhí)行收集操作。（收集是將相鄰空閑塊合并成一個(gè)大塊的操作。）收集耗費(fèi)了額外的周期，但減少了堆塊的內(nèi)部碎片。
單一全局鎖保護(hù)堆，防止多線程式的使用。（請(qǐng)參見“Server?Performance?and?Scalability?Killers”中的第一個(gè)注意事項(xiàng),?George?Reilly?所著，在?“MSDN?Online?Web?Workshop”上（站點(diǎn)：http://msdn.microsoft.com/workshop/server/iis/tencom.asp（英文）。）單一全局鎖本質(zhì)上是用來保護(hù)堆數(shù)據(jù)結(jié)構(gòu)，防止跨多線程的隨機(jī)存取。若堆操作太頻繁，單一全局鎖會(huì)對(duì)性能有不利的影響。
什么是常見的堆性能問題？
以下是您使用堆時(shí)會(huì)遇到的最常見問題：?
分配操作造成的速度減慢。光分配就耗費(fèi)很長(zhǎng)時(shí)間。最可能導(dǎo)致運(yùn)行速度減慢原因是空閑列表沒有塊，所以運(yùn)行時(shí)分配程序代碼會(huì)耗費(fèi)周期尋找較大的空閑塊，或從后端分配程序分配新塊。
釋放操作造成的速度減慢。釋放操作耗費(fèi)較多周期，主要是啟用了收集操作。收集期間，每個(gè)釋放操作“查找”它的相鄰塊，取出它們并構(gòu)造成較大塊，然后再把此較大塊插入空閑列表。在查找期間，內(nèi)存可能會(huì)隨機(jī)碰到，從而導(dǎo)致高速緩存不能命中，性能降低。
堆競(jìng)爭(zhēng)造成的速度減慢。當(dāng)兩個(gè)或多個(gè)線程同時(shí)訪問數(shù)據(jù)，而且一個(gè)線程繼續(xù)進(jìn)行之前必須等待另一個(gè)線程完成時(shí)就發(fā)生競(jìng)爭(zhēng)。競(jìng)爭(zhēng)總是導(dǎo)致麻煩；這也是目前多處理器系統(tǒng)遇到的最大問題。當(dāng)大量使用內(nèi)存塊的應(yīng)用程序或?DLL?以多線程方式運(yùn)行（或運(yùn)行于多處理器系統(tǒng)上）時(shí)將導(dǎo)致速度減慢。單一鎖定的使用—常用的解決方案—意味著使用堆的所有操作是序列化的。當(dāng)?shù)却i定時(shí)序列化會(huì)引起線程切換上下文。可以想象交叉路口閃爍的紅燈處走走停停導(dǎo)致的速度減慢。?
競(jìng)爭(zhēng)通常會(huì)導(dǎo)致線程和進(jìn)程的上下文切換。上下文切換的開銷是很大的，但開銷更大的是數(shù)據(jù)從處理器高速緩存中丟失，以及后來線程復(fù)活時(shí)的數(shù)據(jù)重建。
堆破壞造成的速度減慢。造成堆破壞的原因是應(yīng)用程序?qū)Χ褖K的不正確使用。通常情形包括釋放已釋放的堆塊或使用已釋放的堆塊，以及塊的越界重寫等明顯問題。（破壞不在本文討論范圍之內(nèi)。有關(guān)內(nèi)存重寫和泄漏等其他細(xì)節(jié)，請(qǐng)參見?Microsoft?Visual?C++(R)?調(diào)試文檔?。）
頻繁的分配和重分配造成的速度減慢。這是使用腳本語(yǔ)言時(shí)非常普遍的現(xiàn)象。如字符串被反復(fù)分配，隨重分配增長(zhǎng)和釋放。不要這樣做，如果可能，盡量分配大字符串和使用緩沖區(qū)。另一種方法就是盡量少用連接操作。
競(jìng)爭(zhēng)是在分配和釋放操作中導(dǎo)致速度減慢的問題。理想情況下，希望使用沒有競(jìng)爭(zhēng)和快速分配/釋放的堆。可惜，現(xiàn)在還沒有這樣的通用堆，也許將來會(huì)有。
在所有的服務(wù)器系統(tǒng)中（如?IIS、MSProxy、DatabaseStacks、網(wǎng)絡(luò)服務(wù)器、?Exchange?和其他）,?堆鎖定實(shí)在是個(gè)大瓶頸。處理器數(shù)越多，競(jìng)爭(zhēng)就越會(huì)惡化。
盡量減少堆的使用
現(xiàn)在您明白使用堆時(shí)存在的問題了，難道您不想擁有能解決這些問題的超級(jí)魔棒嗎？我可希望有。但沒有魔法能使堆運(yùn)行加快—因此不要期望在產(chǎn)品出貨之前的最后一星期能夠大為改觀。如果提前規(guī)劃堆策略，情況將會(huì)大大好轉(zhuǎn)。調(diào)整使用堆的方法，減少對(duì)堆的操作是提高性能的良方。
如何減少使用堆操作？通過利用數(shù)據(jù)結(jié)構(gòu)內(nèi)的位置可減少堆操作的次數(shù)。請(qǐng)考慮下列實(shí)例：
struct?ObjectA?{
???//?objectA?
的數(shù)據(jù)?
}
struct?ObjectB?{
???//?objectB?
的數(shù)據(jù)?
}
//?
同時(shí)使用?objectA?和?objectB
//
//?
使用指針?
//
struct?ObjectB?{
???struct?ObjectA?*?pObjA;
???//?objectB?的數(shù)據(jù)?
}
//
//?
使用嵌入
//
struct?ObjectB?{
???struct?ObjectA?pObjA;
???//?objectB?的數(shù)據(jù)?
}
//
//?
集合?–?在另一對(duì)象內(nèi)使用?objectA?和?objectB
//
struct?ObjectX?{
???struct?ObjectA??objA;
???struct?ObjectB??objB;
}
避免使用指針關(guān)聯(lián)兩個(gè)數(shù)據(jù)結(jié)構(gòu)。如果使用指針關(guān)聯(lián)兩個(gè)數(shù)據(jù)結(jié)構(gòu)，前面實(shí)例中的對(duì)象?A?和?B?將被分別分配和釋放。這會(huì)增加額外開銷—我們要避免這種做法。
把帶指針的子對(duì)象嵌入父對(duì)象。當(dāng)對(duì)象中有指針時(shí)，則意味著對(duì)象中有動(dòng)態(tài)元素（百分之八十）和沒有引用的新位置。嵌入增加了位置從而減少了進(jìn)一步分配/釋放的需求。這將提高應(yīng)用程序的性能。
合并小對(duì)象形成大對(duì)象（聚合）。聚合減少分配和釋放的塊的數(shù)量。如果有幾個(gè)開發(fā)者，各自開發(fā)設(shè)計(jì)的不同部分，則最終會(huì)有許多小對(duì)象需要合并。集成的挑戰(zhàn)就是要找到正確的聚合邊界。
內(nèi)聯(lián)緩沖區(qū)能夠滿足百分之八十的需要（aka?80-20?規(guī)則）。個(gè)別情況下，需要內(nèi)存緩沖區(qū)來保存字符串/二進(jìn)制數(shù)據(jù)，但事先不知道總字節(jié)數(shù)。估計(jì)并內(nèi)聯(lián)一個(gè)大小能滿足百分之八十需要的緩沖區(qū)。對(duì)剩余的百分之二十，可以分配一個(gè)新的緩沖區(qū)和指向這個(gè)緩沖區(qū)的指針。這樣，就減少分配和釋放調(diào)用并增加數(shù)據(jù)的位置空間，從根本上提高代碼的性能。
在塊中分配對(duì)象（塊化）。塊化是以組的方式一次分配多個(gè)對(duì)象的方法。如果對(duì)列表的項(xiàng)連續(xù)跟蹤，例如對(duì)一個(gè)?{名稱，值}?對(duì)的列表，有兩種選擇：選擇一是為每一個(gè)“名稱-值”對(duì)分配一個(gè)節(jié)點(diǎn)；選擇二是分配一個(gè)能容納（如五個(gè)）“名稱-值”對(duì)的結(jié)構(gòu)。例如，一般情況下，如果存儲(chǔ)四對(duì)，就可減少節(jié)點(diǎn)的數(shù)量，如果需要額外的空間數(shù)量，則使用附加的鏈表指針。?
塊化是友好的處理器高速緩存，特別是對(duì)于?L1-高速緩存，因?yàn)樗峁┝嗽黾拥奈恢?span lang="EN-US">?—不用說對(duì)于塊分配，很多數(shù)據(jù)塊會(huì)在同一個(gè)虛擬頁(yè)中。
正確使用?_amblksiz。C?運(yùn)行時(shí)?(CRT)?有它的自定義前端分配程序，該分配程序從后端（Win32?堆）分配大小為?_amblksiz?的塊。將?_amblksiz?設(shè)置為較高的值能潛在地減少對(duì)后端的調(diào)用次數(shù)。這只對(duì)廣泛使用?CRT?的程序適用。
使用上述技術(shù)將獲得的好處會(huì)因?qū)ο箢愋汀⒋笮〖肮ぷ髁慷兴煌５偰茉谛阅芎涂缮s性方面有所收獲。另一方面，代碼會(huì)有點(diǎn)特殊，但如果經(jīng)過深思熟慮，代碼還是很容易管理的。
其他提高性能的技術(shù)
下面是一些提高速度的技術(shù)：?
使用?Windows?NT5?堆?
由于幾個(gè)同事的努力和辛勤工作，1998?年初?Microsoft?Windows(R)?2000?中有了幾個(gè)重大改進(jìn)：
改進(jìn)了堆代碼內(nèi)的鎖定。堆代碼對(duì)每堆一個(gè)鎖。全局鎖保護(hù)堆數(shù)據(jù)結(jié)構(gòu)，防止多線程式的使用。但不幸的是，在高通信量的情況下，堆仍受困于全局鎖，導(dǎo)致高競(jìng)爭(zhēng)和低性能。Windows?2000?中，鎖內(nèi)代碼的臨界區(qū)將競(jìng)爭(zhēng)的可能性減到最小,從而提高了可伸縮性。
使用?“Lookaside”列表。堆數(shù)據(jù)結(jié)構(gòu)對(duì)塊的所有空閑項(xiàng)使用了大小在?8?到?1,024?字節(jié)（以?8-字節(jié)遞增）的快速高速緩存。快速高速緩存最初保護(hù)在全局鎖內(nèi)。現(xiàn)在，使用?lookaside?列表來訪問這些快速高速緩存空閑列表。這些列表不要求鎖定，而是使用?64?位的互鎖操作，因此提高了性能。
內(nèi)部數(shù)據(jù)結(jié)構(gòu)算法也得到改進(jìn)。
這些改進(jìn)避免了對(duì)分配高速緩存的需求，但不排除其他的優(yōu)化。使用?Windows?NT5?堆評(píng)估您的代碼；它對(duì)小于?1,024?字節(jié)?(1?KB)?的塊（來自前端分配程序的塊）是最佳的。GlobalAlloc()?和?LocalAlloc()?建立在同一堆上，是存取每個(gè)進(jìn)程堆的通用機(jī)制。如果希望獲得高的局部性能，則使用?Heap(R)?API?來存取每個(gè)進(jìn)程堆，或?yàn)榉峙洳僮鲃?chuàng)建自己的堆。如果需要對(duì)大塊操作，也可以直接使用?VirtualAlloc()?/?VirtualFree()?操作。
上述改進(jìn)已在?Windows?2000?beta?2?和?Windows?NT?4.0?SP4?中使用。改進(jìn)后，堆鎖的競(jìng)爭(zhēng)率顯著降低。這使所有?Win32?堆的直接用戶受益。CRT?堆建立于?Win32?堆的頂部，但它使用自己的小塊堆，因而不能從?Windows?NT?改進(jìn)中受益。（Visual?C++?版本?6.0?也有改進(jìn)的堆分配程序。）
使用分配高速緩存?
分配高速緩存允許高速緩存分配的塊，以便將來重用。這能夠減少對(duì)進(jìn)程堆（或全局堆）的分配/釋放調(diào)用的次數(shù)，也允許最大限度的重用曾經(jīng)分配的塊。另外，分配高速緩存允許收集統(tǒng)計(jì)信息,以便較好地理解對(duì)象在較高層次上的使用。
典型地，自定義堆分配程序在進(jìn)程堆的頂部實(shí)現(xiàn)。自定義堆分配程序與系統(tǒng)堆的行為很相似。主要的差別是它在進(jìn)程堆的頂部為分配的對(duì)象提供高速緩存。高速緩存設(shè)計(jì)成一套固定大小（如?32?字節(jié)、64?字節(jié)、128?字節(jié)等）。這一個(gè)很好的策略，但這種自定義堆分配程序丟失與分配和釋放的對(duì)象相關(guān)的“語(yǔ)義信息”。?
與自定義堆分配程序相反，“分配高速緩存”作為每類分配高速緩存來實(shí)現(xiàn)。除能夠提供自定義堆分配程序的所有好處之外，它們還能夠保留大量語(yǔ)義信息。每個(gè)分配高速緩存處理程序與一個(gè)目標(biāo)二進(jìn)制對(duì)象關(guān)聯(lián)。它能夠使用一套參數(shù)進(jìn)行初始化，這些參數(shù)表示并發(fā)級(jí)別、對(duì)象大小和保持在空閑列表中的元素的數(shù)量等。分配高速緩存處理程序?qū)ο缶S持自己的私有空閑實(shí)體池（不超過指定的閥值）并使用私有保護(hù)鎖。合在一起，分配高速緩存和私有鎖減少了與主系統(tǒng)堆的通信量，因而提供了增加的并發(fā)、最大限度的重用和較高的可伸縮性。
需要使用清理程序來定期檢查所有分配高速緩存處理程序的活動(dòng)情況并回收未用的資源。如果發(fā)現(xiàn)沒有活動(dòng)，將釋放分配對(duì)象的池，從而提高性能。
可以審核每個(gè)分配/釋放活動(dòng)。第一級(jí)信息包括對(duì)象、分配和釋放調(diào)用的總數(shù)。通過查看它們的統(tǒng)計(jì)信息可以得出各個(gè)對(duì)象之間的語(yǔ)義關(guān)系。利用以上介紹的許多技術(shù)之一，這種關(guān)系可以用來減少內(nèi)存分配。
分配高速緩存也起到了調(diào)試助手的作用，幫助您跟蹤沒有完全清除的對(duì)象數(shù)量。通過查看動(dòng)態(tài)堆棧返回蹤跡和除沒有清除的對(duì)象之外的簽名，甚至能夠找到確切的失敗的調(diào)用者。
MP?
堆?
MP?堆是對(duì)多處理器友好的分布式分配的程序包，在?Win32?SDK（Windows?NT?4.0?和更新版本）中可以得到。最初由?JVert?實(shí)現(xiàn)，此處堆抽象建立在?Win32?堆程序包的頂部。MP?堆創(chuàng)建多個(gè)?Win32?堆，并試圖將分配調(diào)用分布到不同堆，以減少在所有單一鎖上的競(jìng)爭(zhēng)。
本程序包是好的步驟?—一種改進(jìn)的?MP-友好的自定義堆分配程序。但是，它不提供語(yǔ)義信息和缺乏統(tǒng)計(jì)功能。通常將?MP?堆作為?SDK?庫(kù)來使用。如果使用這個(gè)?SDK?創(chuàng)建可重用組件，您將大大受益。但是，如果在每個(gè)?DLL?中建立這個(gè)?SDK?庫(kù)，將增加工作設(shè)置。
重新思考算法和數(shù)據(jù)結(jié)構(gòu)?
要在多處理器機(jī)器上伸縮，則算法、實(shí)現(xiàn)、數(shù)據(jù)結(jié)構(gòu)和硬件必須動(dòng)態(tài)伸縮。請(qǐng)看最經(jīng)常分配和釋放的數(shù)據(jù)結(jié)構(gòu)。試問，“我能用不同的數(shù)據(jù)結(jié)構(gòu)完成此工作嗎？”例如，如果在應(yīng)用程序初始化時(shí)加載了只讀項(xiàng)的列表，這個(gè)列表不必是線性鏈接的列表。如果是動(dòng)態(tài)分配的數(shù)組就非常好。動(dòng)態(tài)分配的數(shù)組將減少內(nèi)存中的堆塊和碎片，從而增強(qiáng)性能。
減少需要的小對(duì)象的數(shù)量減少堆分配程序的負(fù)載。例如，我們?cè)诜?wù)器的關(guān)鍵處理路徑上使用五個(gè)不同的對(duì)象，每個(gè)對(duì)象單獨(dú)分配和釋放。一起高速緩存這些對(duì)象，把堆調(diào)用從五個(gè)減少到一個(gè)，顯著減少了堆的負(fù)載，特別當(dāng)每秒鐘處理?1,000?個(gè)以上的請(qǐng)求時(shí)。
如果大量使用“Automation”結(jié)構(gòu)，請(qǐng)考慮從主線代碼中刪除“Automation?BSTR”，或至少避免重復(fù)的?BSTR?操作。（BSTR?連接導(dǎo)致過多的重分配和分配/釋放操作。）
摘要
對(duì)所有平臺(tái)往往都存在堆實(shí)現(xiàn)，因此有巨大的開銷。每個(gè)單獨(dú)代碼都有特定的要求，但設(shè)計(jì)能采用本文討論的基本理論來減少堆之間的相互作用。?
評(píng)價(jià)您的代碼中堆的使用。
改進(jìn)您的代碼，以使用較少的堆調(diào)用：分析關(guān)鍵路徑和固定數(shù)據(jù)結(jié)構(gòu)。
在實(shí)現(xiàn)自定義的包裝程序之前使用量化堆調(diào)用成本的方法。
如果對(duì)性能不滿意，請(qǐng)要求?OS?組改進(jìn)堆。更多這類請(qǐng)求意味著對(duì)改進(jìn)堆的更多關(guān)注。
要求?C?運(yùn)行時(shí)組針對(duì)?OS?所提供的堆制作小巧的分配包裝程序。隨著?OS?堆的改進(jìn)，C?運(yùn)行時(shí)堆調(diào)用的成本將減小。
操作系統(tǒng)（Windows?NT?家族）正在不斷改進(jìn)堆。請(qǐng)隨時(shí)關(guān)注和利用這些改進(jìn)。
Murali?Krishnan?是?Internet?Information?Server?(IIS)?組的首席軟件設(shè)計(jì)工程師。從?1.0?版本開始他就設(shè)計(jì)?IIS，并成功發(fā)行了?1.0?版本到?4.0?版本。Murali?組織并領(lǐng)導(dǎo)?IIS?性能組三年?(1995-1998),?從一開始就影響?IIS?性能。他擁有威斯康星州?Madison?大學(xué)的?M.S.和印度?Anna?大學(xué)的?B.S.。工作之外，他喜歡閱讀、打排球和家庭烹飪。
http://yanricheng.javaeye.com/blog/131344