剖析內存中的程序之秘

內存管理是操作系統的核心任務；它對程序員和系統管理員來說也是至關重要的。在接下來的幾篇文章中，我將從實踐出發著眼於內存管理，並深入到它的內部結構。雖然這些概念很通用，但示例大都來自於 32 位 x86 架構的 Linux 和 Windows 上。這第一篇文章描述了在內存中程序如何分布。

在一個多任務操作系統中的每個進程都運行在它自己的內存「沙箱」中。這個沙箱是一個 虛擬地址空間 virtual address space ，在 32 位的模式中它總共有 4GB 的內存地址塊。這些虛擬地址是通過內核 頁表 page table 映射到物理地址的，並且這些虛擬地址是由操作系統內核來維護，進而被進程所消費的。每個進程都有它自己的一組頁表，但是這裡有點玄機。一旦虛擬地址被啟用，這些虛擬地址將被應用到這台電腦上的 所有軟體，包括內核本身。因此，一部分虛擬地址空間必須保留給內核使用：

但是，這並不是說內核就使用了很多的物理內存，恰恰相反，它只使用了很少一部分可用的地址空間映射到其所需要的物理內存。內核空間在內核頁表中被標記為獨佔使用於 特權代碼 （ring 2 或更低），因此，如果一個用戶模式的程序嘗試去訪問它，將觸發一個頁面故障錯誤。在 Linux 中，內核空間是始終存在的，並且在所有進程中都映射相同的物理內存。內核代碼和數據總是可定址的，準備隨時去處理中斷或者系統調用。相比之下，用戶模式中的地址空間，在每次進程切換時都會發生變化：

藍色的區域代表映射到物理地址的虛擬地址空間，白色的區域是尚未映射的部分。在上面的示例中，眾所周知的內存「饕餮」 Firefox 使用了大量的虛擬內存空間。在地址空間中不同的條帶對應了不同的內存段，像 堆 heap 、 棧 stack 等等。請注意，這些段只是一系列內存地址的簡化表示，它與 Intel 類型的段 並沒有任何關係 。不過，這是一個在 Linux 進程的標準段布局：

當計算機還是快樂、安全的時代時，在機器中的幾乎每個進程上，那些段的起始虛擬地址都是完全相同的。這將使遠程挖掘安全漏洞變得容易。漏洞利用經常需要去引用絕對內存位置：比如在棧中的一個地址，一個庫函數的地址，等等。遠程攻擊可以閉著眼睛選擇這個地址，因為地址空間都是相同的。當攻擊者們這樣做的時候，人們就會受到傷害。因此，地址空間隨機化開始流行起來。Linux 會通過在其起始地址上增加偏移量來隨機化棧、內存映射段、以及堆。不幸的是，32 位的地址空間是非常擁擠的，為地址空間隨機化留下的空間不多，因此 妨礙了地址空間隨機化的效果。

在進程地址空間中最高的段是棧，在大多數編程語言中它存儲本地變數和函數參數。調用一個方法或者函數將推送一個新的 棧幀 stack frame 到這個棧。當函數返回時這個棧幀被刪除。這個簡單的設計，可能是因為數據嚴格遵循 後進先出（LIFO） 的次序，這意味著跟蹤棧內容時不需要複雜的數據結構 —— 一個指向棧頂的簡單指針就可以做到。推入和彈出也因此而非常快且準確。也可能是，持續的棧區重用往往會在 CPU 緩存 中保持活躍的棧內存，這樣可以加快訪問速度。進程中的每個線程都有它自己的棧。

向棧中推送更多的而不是剛合適的數據可能會耗盡棧的映射區域。這將觸發一個頁面故障，在 Linux 中它是通過 expand_stack() 來處理的，它會去調用 acct_stack_growth() 來檢查棧的增長是否正常。如果棧的大小低於 RLIMIT_STACK 的值（一般是 8MB 大小），那麼這是一個正常的棧增長和程序的合理使用，否則可能是發生了未知問題。這是一個棧大小按需調節的常見機制。但是，棧的大小達到了上述限制，將會發生一個棧溢出，並且，程序將會收到一個 段故障 Segmentation Fault 錯誤。當映射的棧區為滿足需要而擴展後，在棧縮小時，映射區域並不會收縮。就像美國聯邦政府的預算一樣，它只會擴張。

動態棧增長是 唯一例外的情況 ，當它去訪問一個未映射的內存區域，如上圖中白色部分，是允許的。除此之外的任何其它訪問未映射的內存區域將觸發一個頁面故障，導致段故障。一些映射區域是只讀的，因此，嘗試去寫入到這些區域也將觸發一個段故障。

在棧的下面，有內存映射段。在這裡，內核將文件內容直接映射到內存。任何應用程序都可以通過 Linux 的 mmap() 系統調用（ 代碼實現）或者 Windows 的 CreateFileMapping() / MapViewOfFile() 來請求一個映射。內存映射是實現文件 I/O 的方便高效的方式。因此，它經常被用於載入動態庫。有時候，也被用於去創建一個並不匹配任何文件的匿名內存映射，這種映射經常被用做程序數據的替代。在 Linux 中，如果你通過 malloc() 去請求一個大的內存塊，C 庫將會創建這樣一個匿名映射而不是使用堆內存。這裡所謂的「大」表示是超過了MMAP_THRESHOLD 設置的位元組數，它的預設值是 128 kB，可以通過 mallopt() 去調整這個設置值。

接下來講的是「堆」，就在我們接下來的地址空間中，堆提供運行時內存分配，像棧一樣，但又不同於棧的是，它分配的數據生存期要長於分配它的函數。大多數編程語言都為程序提供了堆管理支持。因此，滿足內存需要是編程語言運行時和內核共同來做的事情。在 C 中，堆分配的介面是 malloc() 一族，然而在支持垃圾回收的編程語言中，像 C#，這個介面使用 new 關鍵字。

如果在堆中有足夠的空間可以滿足內存請求，它可以由編程語言運行時來處理內存分配請求，而無需內核參與。否則將通過 brk() 系統調用（代碼實現）來擴大堆以滿足內存請求所需的大小。堆管理是比較 複雜的，在面對我們程序的混亂分配模式時，它通過複雜的演算法，努力在速度和內存使用效率之間取得一種平衡。服務一個堆請求所需要的時間可能是非常可觀的。實時系統有一個 特定用途的分配器 去處理這個問題。堆也會出現 碎片化 ，如下圖所示：

最後，我們抵達了內存的低位段：BSS、數據、以及程序文本。在 C 中，靜態（全局）變數的內容都保存在 BSS 和數據中。它們之間的不同之處在於，BSS 保存 未初始化的 靜態變數的內容，它的值在源代碼中並沒有被程序員設置。BSS 內存區域是 匿名 的：它沒有映射到任何文件上。如果你在程序中寫這樣的語句 static int cntActiveUsers，cntActiveUsers 的內容就保存在 BSS 中。

反過來，數據段，用於保存在源代碼中靜態變數 初始化後 的內容。這個內存區域是 非匿名 的。它映射了程序的二進值鏡像上的一部分，包含了在源代碼中給定初始化值的靜態變數內容。因此，如果你在程序中寫這樣的語句 static int cntWorkerBees = 10，那麼，cntWorkerBees 的內容就保存在數據段中，並且初始值為 10。儘管可以通過數據段映射到一個文件，但是這是一個私有內存映射，意味著，如果改變內存，它並不會將這種變化反映到底層的文件上。必須是這樣的，否則，分配的全局變數將會改變你磁碟上的二進位文件鏡像，這種做法就太不可思議了！

用圖去展示一個數據段是很困難的，因為它使用一個指針。在那種情況下，指針 gonzo 的內容（一個 4 位元組的內存地址）保存在數據段上。然而，它並沒有指向一個真實的字元串。而這個字元串存在於文本段中，文本段是只讀的，它用於保存你的代碼中的類似於字元串常量這樣的內容。文本段也會在內存中映射你的二進位文件，但是，如果你的程序寫入到這個區域，將會觸發一個段故障錯誤。儘管在 C 中，它比不上從一開始就避免這種指針錯誤那麼有效，但是，這種機制也有助於避免指針錯誤。這裡有一個展示這些段和示例變數的圖：

你可以通過讀取 /proc/pid_of_process/maps 文件來檢查 Linux 進程中的內存區域。請記住，一個段可以包含很多的區域。例如，每個內存映射的文件一般都在 mmap 段中的它自己的區域中，而動態庫有類似於 BSS 和數據一樣的額外的區域。下一篇文章中我們將詳細說明「 區域 area 」的真正含義是什麼。此外，有時候人們所說的「 數據段 data segment 」是指「 數據 data + BSS + 堆」。

你可以使用 nm 和 objdump 命令去檢查二進位鏡像，去顯示它們的符號、地址、段等等。最終，在 Linux 中上面描述的虛擬地址布局是一個「彈性的」布局，這就是這幾年來的預設情況。它假設 RLIMIT_STACK 有一個值。如果沒有值的話，Linux 將恢復到如下所示的「經典」 布局：

這就是虛擬地址空間布局。接下來的文章將討論內核如何對這些內存區域保持跟蹤、內存映射、文件如何讀取和寫入、以及內存使用數據的意義。

via: http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/

作者：Gustavo Duarte 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive