剖析內存中的程序之秘，快來看吧！
內存管理是操作系統的核心任務；它對程序員和系統管理員來說也是至關重要的。在接下來的幾篇文章中，我將從實踐出發著眼于內存管理，并深入到它的內部結構。雖然這些概念很通用，但示例大都來自于 32 位 x86 架構的 Linux 和 Windows 上。這第一篇文章描述了在內存中程序如何分布。
在一個多任務操作系統中的每個進程都運行在它自己的內存“沙箱”中。這個沙箱是一個虛擬地址空間，在 32 位的模式中它總共有 4GB 的內存地址塊。這些虛擬地址是通過內核頁表映射到物理地址的，并且這些虛擬地址是由操作系統內核來維護，進而被進程所消費的。每個進程都有它自己的一組頁表，但是這里有點玄機。一旦虛擬地址被啟用，這些虛擬地址將被應用到這臺電腦上的 所有軟件，包括內核本身。因此，一部分虛擬地址空間必須保留給內核使用：
Kernel/User Memory Split
但是，這并不是說內核就使用了很多的物理內存，恰恰相反，它只使用了很少一部分可用的地址空間映射到其所需要的物理內存。內核空間在內核頁表中被標記為獨占使用于 特權代碼 （ring 2 或更低），因此，如果一個用戶模式的程序嘗試去訪問它，將觸發一個頁面故障錯誤。在 Linux 中，內核空間是始終存在的，并且在所有進程中都映射相同的物理內存。內核代碼和數據總是可尋址的，準備隨時去處理中斷或者系統調用。相比之下，用戶模式中的地址空間，在每次進程切換時都會發生變化：
Process Switch Effects on Virtual Memory
藍色的區域代表映射到物理地址的虛擬地址空間，白色的區域是尚未映射的部分。在上面的示例中，眾所周知的內存“饕餮” Firefox 使用了大量的虛擬內存空間。在地址空間中不同的條帶對應了不同的內存段，像堆、棧等等。請注意，這些段只是一系列內存地址的簡化表示，它與 Intel 類型的段 并沒有任何關系 。不過，這是一個在 Linux 進程的標準段布局：
Flexible Process Address Space Layout In Linux
當計算機還是快樂、安全的時代時，在機器中的幾乎每個進程上，那些段的起始虛擬地址都是完全相同的。這將使遠程挖掘安全漏洞變得容易。漏洞利用經常需要去引用絕對內存位置：比如在棧中的一個地址，一個庫函數的地址，等等。遠程攻擊可以閉著眼睛選擇這個地址，因為地址空間都是相同的。當攻擊者們這樣做的時候，人們就會受到傷害。因此，地址空間隨機化開始流行起來。Linux 會通過在其起始地址上增加偏移量來隨機化棧、內存映射段、以及堆。不幸的是，32 位的地址空間是非常擁擠的，為地址空間隨機化留下的空間不多，因此 妨礙了地址空間隨機化的效果。
在進程地址空間中最高的段是棧，在大多數編程語言中它存儲本地變量和函數參數。調用一個方法或者函數將推送一個新的棧幀到這個棧。當函數返回時這個棧幀被刪除。這個簡單的設計，可能是因為數據嚴格遵循 后進先出（LIFO） 的次序，這意味著跟蹤棧內容時不需要復雜的數據結構 —— 一個指向棧頂的簡單指針就可以做到。推入和彈出也因此而非常快且準確。也可能是，持續的棧區重用往往會在 CPU 緩存 中保持活躍的棧內存，這樣可以加快訪問速度。進程中的每個線程都有它自己的棧。
向棧中推送更多的而不是剛合適的數據可能會耗盡棧的映射區域。這將觸發一個頁面故障，在 Linux 中它是通過 expand_stack() 來處理的，它會去調用 acct_stack_growth() 來檢查棧的增長是否正常。如果棧的大小低于 RLIMIT_STACK 的值（一般是 8MB 大小），那么這是一個正常的棧增長和程序的合理使用，否則可能是發生了未知問題。這是一個棧大小按需調節的常見機制。但是，棧的大小達到了上述限制，將會發生一個棧溢出，并且，程序將會收到一個段故障錯誤。當映射的棧區為滿足需要而擴展后，在棧縮小時，映射區域并不會收縮。就像美國聯邦政府的預算一樣，它只會擴張。
動態棧增長是 唯一例外的情況 ，當它去訪問一個未映射的內存區域，如上圖中白色部分，是允許的。除此之外的任何其它訪問未映射的內存區域將觸發一個頁面故障，導致段故障。一些映射區域是只讀的，因此，嘗試去寫入到這些區域也將觸發一個段故障。
在棧的下面，有內存映射段。在這里，內核將文件內容直接映射到內存。任何應用程序都可以通過 Linux 的 mmap() 系統調用（ 代碼實現）或者 Windows 的 CreateFileMapping() / MapViewOfFile() 來請求一個映射。內存映射是實現文件 I/O 的方便高效的方式。因此，它經常被用于加載動態庫。有時候，也被用于去創建一個并不匹配任何文件的匿名內存映射，這種映射經常被用做程序數據的替代。在 Linux 中，如果你通過 malloc() 去請求一個大的內存塊，C 庫將會創建這樣一個匿名映射而不是使用堆內存。這里所謂的“大”表示是超過了MMAP_THRESHOLD 設置的字節數，它的缺省值是 128 kB，可以通過 mallopt() 去調整這個設置值。
接下來講的是“堆”，就在我們接下來的地址空間中，堆提供運行時內存分配，像棧一樣，但又不同于棧的是，它分配的數據生存期要長于分配它的函數。大多數編程語言都為程序提供了堆管理支持。因此，滿足內存需要是編程語言運行時和內核共同來做的事情。在 C 中，堆分配的接口是 malloc() 一族，然而在支持垃圾回收的編程語言中，像 C#，這個接口使用 new 關鍵字。
如果在堆中有足夠的空間可以滿足內存請求，它可以由編程語言運行時來處理內存分配請求，而無需內核參與。否則將通過 brk() 系統調用（代碼實現）來擴大堆以滿足內存請求所需的大小。堆管理是比較 復雜的，在面對我們程序的混亂分配模式時，它通過復雜的算法，努力在速度和內存使用效率之間取得一種平衡。服務一個堆請求所需要的時間可能是非常可觀的。實時系統有一個 特定用途的分配器 去處理這個問題。堆也會出現 碎片化 ，如下圖所示：
Fragmented Heap
最后，我們抵達了內存的低位段：BSS、數據、以及程序文本。在 C 中，靜態（全局）變量的內容都保存在 BSS 和數據中。它們之間的不同之處在于，BSS 保存 未初始化的 靜態變量的內容，它的值在源代碼中并沒有被程序員設置。BSS 內存區域是 匿名 的：它沒有映射到任何文件上。如果你在程序中寫這樣的語句 static int cntActiveUsers，cntActiveUsers 的內容就保存在 BSS 中。
反過來，數據段，用于保存在源代碼中靜態變量 初始化后 的內容。這個內存區域是 非匿名 的。它映射了程序的二進值鏡像上的一部分，包含了在源代碼中給定初始化值的靜態變量內容。因此，如果你在程序中寫這樣的語句 static int cntWorkerBees = 10，那么，cntWorkerBees 的內容就保存在數據段中，并且初始值為 10。盡管可以通過數據段映射到一個文件，但是這是一個私有內存映射，意味著，如果改變內存，它并不會將這種變化反映到底層的文件上。必須是這樣的，否則，分配的全局變量將會改變你磁盤上的二進制文件鏡像，這種做法就太不可思議了！
用圖去展示一個數據段是很困難的，因為它使用一個指針。在那種情況下，指針 gonzo 的內容（一個 4 字節的內存地址）保存在數據段上。然而，它并沒有指向一個真實的字符串。而這個字符串存在于文本段中，文本段是只讀的，它用于保存你的代碼中的類似于字符串常量這樣的內容。文本段也會在內存中映射你的二進制文件，但是，如果你的程序寫入到這個區域，將會觸發一個段故障錯誤。盡管在 C 中，它比不上從一開始就避免這種指針錯誤那么有效，但是，這種機制也有助于避免指針錯誤。這里有一個展示這些段和示例變量的圖：
ELF Binary Image Mapped Into Memory
你可以通過讀取 /proc/pid_of_process/maps 文件來檢查 Linux 進程中的內存區域。請記住，一個段可以包含很多的區域。例如，每個內存映射的文件一般都在 mmap 段中的它自己的區域中，而動態庫有類似于 BSS 和數據一樣的額外的區域。下一篇文章中我們將詳細說明“區域”的真正含義是什么。此外，有時候人們所說的“數據段”是指“數據 + BSS + 堆”。
你可以使用 nm 和 objdump 命令去檢查二進制鏡像，去顯示它們的符號、地址、段等等。最終，在 Linux 中上面描述的虛擬地址布局是一個“彈性的”布局，這就是這幾年來的缺省情況。它假設 RLIMIT_STACK 有一個值。如果沒有值的話，Linux 將恢復到如下所示的“經典” 布局：
Classic Process Address Space Layout In Linux
這就是虛擬地址空間布局。接下來的文章將討論內核如何對這些內存區域保持跟蹤、內存映射、文件如何讀取和寫入、以及內存使用數據的意義。
