原文標(biāo)題：Anatomy of a Program in Memory

原文地址：http://duartes.org/gustavo/blog/

[注：本人水平有限，只好挑一些國(guó)外高手的精彩文章翻譯一下。一來自己復(fù)習(xí)，二來與大家分享。]

    內(nèi)存管理模塊是操作系統(tǒng)的心臟；它對(duì)應(yīng)用程序和系統(tǒng)管理非常重要。今后的幾篇文章中，我將著眼于實(shí)際的內(nèi)存問題，但也不避諱其中的技術(shù)內(nèi)幕。由于不少概念是通用的，所以文中大部分例子取自32位x86平臺(tái)的Linux和Windows系統(tǒng)。本系列第一篇文章講述應(yīng)用程序的內(nèi)存布局。

    在多任務(wù)操作系統(tǒng)中的每一個(gè)進(jìn)程都運(yùn)行在一個(gè)屬于它自己的內(nèi)存沙盤中。這個(gè)沙盤就是虛擬地址空間（virtual address space），在32位模式下它總是一個(gè)4GB的內(nèi)存地址塊。這些虛擬地址通過頁表（page table）映射到物理內(nèi)存，頁表由操作系統(tǒng)維護(hù)并被處理器引用。每一個(gè)進(jìn)程擁有一套屬于它自己的頁表，但是還有一個(gè)隱情。只要虛擬地址被使能，那么它就會(huì)作用于這臺(tái)機(jī)器上運(yùn)行的所有軟件，包括內(nèi)核本身。因此一部分虛擬地址必須保留給內(nèi)核使用：

    這并不意味著內(nèi)核使用了那么多的物理內(nèi)存，僅表示它可支配這么大的地址空間，可根據(jù)內(nèi)核需要，將其映射到物理內(nèi)存。內(nèi)核空間在頁表中擁有較高的特權(quán)級(jí)（ring 2或以下），因此只要用戶態(tài)的程序試圖訪問這些頁，就會(huì)導(dǎo)致一個(gè)頁錯(cuò)誤（page fault）。在Linux中，內(nèi)核空間是持續(xù)存在的，并且在所有進(jìn)程中都映射到同樣的物理內(nèi)存。內(nèi)核代碼和數(shù)據(jù)總是可尋址的，隨時(shí)準(zhǔn)備處理中斷和系統(tǒng)調(diào)用。與此相反，用戶模式地址空間的映射隨進(jìn)程切換的發(fā)生而不斷變化：

    藍(lán)色區(qū)域表示映射到物理內(nèi)存的虛擬地址，而白色區(qū)域表示未映射的部分。在上面的例子中，Firefox使用了相當(dāng)多的虛擬地址空間，因?yàn)樗莻髡f中的吃內(nèi)存大戶。地址空間中的各個(gè)條帶對(duì)應(yīng)于不同的內(nèi)存段（memory segment），如：堆、棧之類的。記住，這些段只是簡(jiǎn)單的內(nèi)存地址范圍，與Intel處理器的段沒有關(guān)系。不管怎樣，下面是一個(gè)Linux進(jìn)程的標(biāo)準(zhǔn)的內(nèi)存段布局：

    當(dāng)計(jì)算機(jī)開心、安全、可愛、正常的運(yùn)轉(zhuǎn)時(shí)，幾乎每一個(gè)進(jìn)程的各個(gè)段的起始虛擬地址都與上圖完全一致，這也給遠(yuǎn)程發(fā)掘程序安全漏洞打開了方便之門。一個(gè)發(fā)掘過程往往需要引用絕對(duì)內(nèi)存地址：棧地址，庫函數(shù)地址等。遠(yuǎn)程攻擊者必須依賴地址空間布局的一致性，摸索著選擇這些地址。如果讓他們猜個(gè)正著，有人就會(huì)被整了。因此，地址空間的隨機(jī)排布方式逐漸流行起來。Linux通過對(duì)棧、內(nèi)存映射段、堆的起始地址加上隨機(jī)的偏移量來打亂布局。不幸的是，32位地址空間相當(dāng)緊湊，給隨機(jī)化所留下的空當(dāng)不大，削弱了這種技巧的效果。

    進(jìn)程地址空間中最頂部的段是棧，大多數(shù)編程語言將之用于存儲(chǔ)局部變量和函數(shù)參數(shù)。調(diào)用一個(gè)方法或函數(shù)會(huì)將一個(gè)新的棧楨（stack frame）壓入棧中。棧楨在函數(shù)返回時(shí)被清理。也許是因?yàn)閿?shù)據(jù)嚴(yán)格的遵從LIFO的順序，這個(gè)簡(jiǎn)單的設(shè)計(jì)意味著不必使用復(fù)雜的數(shù)據(jù)結(jié)構(gòu)來追蹤棧的內(nèi)容，只需要一個(gè)簡(jiǎn)單的指針指向棧的頂端即可。因此壓棧（pushing）和退棧（popping）過程非常迅速、準(zhǔn)確。另外，持續(xù)的重用棧空間有助于使活躍的棧內(nèi)存保持在CPU緩存中，從而加速訪問。進(jìn)程中的每一個(gè)線程都有屬于自己的棧。

    通過不斷向棧中壓入的數(shù)據(jù)，超出其容量就有會(huì)耗盡棧所對(duì)應(yīng)的內(nèi)存區(qū)域。這將觸發(fā)一個(gè)頁故障（page fault），并被Linux的expand_stack()處理，它會(huì)調(diào)用acct_stack_growth()來檢查是否還有合適的地方用于棧的增長(zhǎng)。如果棧的大小低于RLIMIT_STACK（通常是8MB），那么一般情況下棧會(huì)被加長(zhǎng)，程序繼續(xù)愉快的運(yùn)行，感覺不到發(fā)生了什么事情。這是一種將棧擴(kuò)展至所需大小的常規(guī)機(jī)制。然而，如果達(dá)到了最大的棧空間大小，就會(huì)棧溢出（stack overflow），程序收到一個(gè)段錯(cuò)誤（Segmentation Fault）。當(dāng)映射了的棧區(qū)域擴(kuò)展到所需的大小后，它就不會(huì)再收縮回去，即使棧不那么滿了。這就好比聯(lián)邦預(yù)算，它總是在增長(zhǎng)的。

    動(dòng)態(tài)棧增長(zhǎng)是唯一一種訪問未映射內(nèi)存區(qū)域（圖中白色區(qū)域）而被允許的情形。其它任何對(duì)未映射內(nèi)存區(qū)域的訪問都會(huì)觸發(fā)頁故障，從而導(dǎo)致段錯(cuò)誤。一些被映射的區(qū)域是只讀的，因此企圖寫這些區(qū)域也會(huì)導(dǎo)致段錯(cuò)誤。

    在棧的下方，是我們的內(nèi)存映射段。此處，內(nèi)核將文件的內(nèi)容直接映射到內(nèi)存。任何應(yīng)用程序都可以通過Linux的mmap()系統(tǒng)調(diào)用（實(shí)現(xiàn)）或Windows的CreateFileMapping() / MapViewOfFile()請(qǐng)求這種映射。內(nèi)存映射是一種方便高效的文件I/O方式，所以它被用于加載動(dòng)態(tài)庫。創(chuàng)建一個(gè)不對(duì)應(yīng)于任何文件的匿名內(nèi)存映射也是可能的，此方法用于存放程序的數(shù)據(jù)。在Linux中，如果你通過malloc()請(qǐng)求一大塊內(nèi)存，C運(yùn)行庫將會(huì)創(chuàng)建這樣一個(gè)匿名映射而不是使用堆內(nèi)存。‘大塊’意味著比MMAP_THRESHOLD還大，缺省是128KB，可以通過mallopt()調(diào)整。

    說到堆，它是接下來的一塊地址空間。與棧一樣，堆用于運(yùn)行時(shí)內(nèi)存分配；但不同點(diǎn)是，堆用于存儲(chǔ)那些生存期與函數(shù)調(diào)用無關(guān)的數(shù)據(jù)。大部分語言都提供了堆管理功能。因此，滿足內(nèi)存請(qǐng)求就成了語言運(yùn)行時(shí)庫及內(nèi)核共同的任務(wù)。在C語言中，堆分配的接口是malloc()系列函數(shù)，而在具有垃圾收集功能的語言（如C#）中，此接口是new關(guān)鍵字。

    如果堆中有足夠的空間來滿足內(nèi)存請(qǐng)求，它就可以被語言運(yùn)行時(shí)庫處理而不需要內(nèi)核參與。否則，堆會(huì)被擴(kuò)大，通過brk()系統(tǒng)調(diào)用（實(shí)現(xiàn)）來分配請(qǐng)求所需的內(nèi)存塊。堆管理是很復(fù)雜的，需要精細(xì)的算法，應(yīng)付我們程序中雜亂的分配模式，優(yōu)化速度和內(nèi)存使用效率。處理一個(gè)堆請(qǐng)求所需的時(shí)間會(huì)大幅度的變動(dòng)。實(shí)時(shí)系統(tǒng)通過特殊目的分配器來解決這個(gè)問題。堆也可能會(huì)變得零零碎碎，如下圖所示：

    最后，我們來看看最底部的內(nèi)存段：BSS，數(shù)據(jù)段，代碼段。在C語言中，BSS和數(shù)據(jù)段保存的都是靜態(tài)（全局）變量的內(nèi)容。區(qū)別在于BSS保存的是未被初始化的靜態(tài)變量?jī)?nèi)容，它們的值不是直接在程序的源代碼中設(shè)定的。BSS內(nèi)存區(qū)域是匿名的：它不映射到任何文件。如果你寫static int cntActiveUsers，則cntActiveUsers的內(nèi)容就會(huì)保存在BSS中。

    另一方面，數(shù)據(jù)段保存在源代碼中已經(jīng)初始化了的靜態(tài)變量?jī)?nèi)容。這個(gè)內(nèi)存區(qū)域不是匿名的。它映射了一部分的程序二進(jìn)制鏡像，也就是源代碼中指定了初始值的靜態(tài)變量。所以，如果你寫static int cntWorkerBees = 10，則cntWorkerBees的內(nèi)容就保存在數(shù)據(jù)段中了，而且初始值為10。盡管數(shù)據(jù)段映射了一個(gè)文件，但它是一個(gè)私有內(nèi)存映射，這意味著更改此處的內(nèi)存不會(huì)影響到被映射的文件。也必須如此，否則給全局變量賦值將會(huì)改動(dòng)你硬盤上的二進(jìn)制鏡像，這是不可想象的。

    下圖中數(shù)據(jù)段的例子更加復(fù)雜，因?yàn)樗昧艘粋€(gè)指針。在此情況下，指針gonzo（4字節(jié)內(nèi)存地址）本身的值保存在數(shù)據(jù)段中。而它所指向的實(shí)際字符串則不在這里。這個(gè)字符串保存在代碼段中，代碼段是只讀的，保存了你全部的代碼外加零零碎碎的東西，比如字符串字面值。代碼段將你的二進(jìn)制文件也映射到了內(nèi)存中，但對(duì)此區(qū)域的寫操作都會(huì)使你的程序收到段錯(cuò)誤。這有助于防范指針錯(cuò)誤，雖然不像在C語言編程時(shí)就注意防范來得那么有效。下圖展示了這些段以及我們例子中的變量：

    你可以通過閱讀文件/proc/pid_of_process/maps來檢驗(yàn)一個(gè)Linux進(jìn)程中的內(nèi)存區(qū)域。記住一個(gè)段可能包含許多區(qū)域。比如，每個(gè)內(nèi)存映射文件在mmap段中都有屬于自己的區(qū)域，動(dòng)態(tài)庫擁有類似BSS和數(shù)據(jù)段的額外區(qū)域。下一篇文章講說明這些“區(qū)域”（area）的真正含義。有時(shí)人們提到“數(shù)據(jù)段”，指的就是全部的數(shù)據(jù)段 + BSS + 堆。

    你可以通過nm和objdump命令來察看二進(jìn)制鏡像，打印其中的符號(hào)，它們的地址，段等信息。最后需要指出的是，前文描述的虛擬地址布局在Linux中是一種“靈活布局”（flexible layout），而且以此作為默認(rèn)方式已經(jīng)有些年頭了。它假設(shè)我們有值RLIMIT_STACK。當(dāng)情況不是這樣時(shí)，Linux退回使用“經(jīng)典布局”（classic layout），如下圖所示：

    對(duì)虛擬地址空間的布局就講這些吧。下一篇文章將討論內(nèi)核是如何跟蹤這些內(nèi)存區(qū)域的。我們會(huì)分析內(nèi)存映射，看看文件的讀寫操作是如何與之關(guān)聯(lián)的，以及內(nèi)存使用概況的含義