如果你完全理解如下內容， 請聯系我：szu030606@163.com，? 討論更深層次合作 。

1.????????大內高手—內存模型

單線程模型

多線程模型

?

2.????????大內高手—棧/堆

?????? backtrace的實現

?????? alloca的實現

??????可變參數的實現。

?????? malloc/free系列函數簡介

?????? new/delete系列操作符簡介

??????

3.????????大內高手—全局內存

?????? .bss說明

?????? .data說明

?????? .rodata說明

?????? violatile關鍵字說明

?????? static關鍵字說明

?????? const關鍵字說明

?

4.????????大內高手—內存分配算法

??????標準C(glibc)分配算法

?????? STL(STLPort)分配算法

?????? OS內部分配算法（伙伴/SLAB）

?

5.????????大內高手—慣用手法

??????引用計數

??????預先分配

??????內存池

??????會話池

?????? …

6.????????大內高手—共享內存與線程局部存儲

7.????????大內高手—自動內存回收機制

8.????????大內高手—常見內存錯誤

9.????????大內高手—常用調試工具

?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++

大內高手—內存模型

?++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

了解linux的內存模型，或許不能讓你大幅度提高編程能力，但是作為一個基本知識點應該熟悉。坐火車外出旅行時，即時你對沿途的地方一無所知，仍然可以到達目標地。但是你對整個路途都很比較清楚的話，每到一個站都知道自己在哪里，知道當地的風土人情，對比一下所見所想，旅程可能更有趣一些。

?

類似的，了解linux的內存模型，你知道每塊內存，每個變量，在系統中處于什么樣的位置。這同樣會讓你心情愉快，知道這些，有時還會讓你的生活輕更松些。看看變量的地址，你可以大致斷定這是否是一個有效的地址。一個變量被破壞了，你可以大致推斷誰是犯罪嫌疑人。

?

Linux的內存模型，一般為：

?

?

很多書上都有類似的描述，本圖取自于《深入理解計算機系統》p603，略做修改。本圖比較清析，很容易理解，但仍然有兩點不足。下面補充說明一下：

?

1.????????第一點是關于運行時堆的。

為說明這個問題，我們先運行一個測試程序，并觀察其結果：

?

運行后，輸出結果為：

main=0x8048404 print=0x8048324

first=0xbfcd1264

p0=0x9253008 p1=0xb7ec0008 p2=0x97ebf008 p3=0x57ebe008

?

l????????main和print兩個函數是代碼段(.text)的，其地址符合表一的描述。

l????????first是第一個臨時變量，由于在first之前還有一些環境變量，它的值并非0xbfffffff，而是0xbfcd1264，這是正常的。

l????????p0是在堆中分配的，其地址小于0x4000 0000，這也是正常的。

l????????但p1和p2也是在堆中分配的，而其地址竟大于0x4000 0000，與表一描述不符。

?

原因在于：運行時堆的位置與內存管理算法相關，也就是與malloc的實現相關。關于內存管理算法的問題，我們在后繼文章中有詳細描述，這里只作簡要說明。在glibc實現的內存管理算法中，Malloc小塊內存是在小于0x4000 0000的內存中分配的，通過brk/sbrk不斷向上擴展，而分配大塊內存，malloc直接通過系統調用mmap實現，分配得到的地址在文件映射區，所以其地址大于0x4000 0000。

?

從maps文件中可以清楚的看到一點：

?

?

2.????????第二是關于多線程的。

現在的應用程序，多線程的居多。表一所描述的模型無法適用于多線程環境。按表一所述，程序最多擁有上G的棧空間，事實上，在多線程情況下，能用的棧空間是非常有限的。為了說明這個問題，我們再看另外一個測試：

?

運行后，輸出結果為：

first=0xbfd3d35c

(0xb7f2cbb0): first=0xb7f2c454

(0xb7f2cbb0): p0=0x84d52d8 p1=0xb4c27008

(0xb752bbb0): first=0xb752b454

(0xb752bbb0): p0=0x84d56e0 p1=0xb4b26008

(0xb6b2abb0): first=0xb6b2a454

(0xb6b2abb0): p0=0x84d5ae8 p1=0xb4a25008

(0xb6129bb0): first=0xb6129454

(0xb6129bb0): p0=0x84d5ef0 p1=0xb4924008

(0xb5728bb0): first=0xb5728454

(0xb5728bb0): p0=0x84d62f8 p1=0xb7e2c008

?

我們看一下:

主線程與第一個線程的棧之間的距離：0xbfd3d35c - 0xb7f2c454=0x7e10f08=126M

第一個線程與第二個線程的棧之間的距離：0xb7f2c454 - 0xb752b454=0xa01000=10M

其它幾個線程的棧之間距離均為10M。

也就是說，主線程的棧空間最大為126M，而普通線程的棧空間僅為10M，超這個范圍就會造成棧溢出。

?

棧溢出的后果是比較嚴重的，或者出現Segmentation fault錯誤，或者出現莫名其妙的錯誤。

進階2：

l????????棧

棧作為一種基本數據結構，我并不感到驚訝，用來實現函數調用，這也司空見慣的作法。直到我試圖找到另外一種方式實現遞歸操作時，我才感嘆于它的巧妙。要實現遞歸操作，不用棧不是不可能，而是找不出比它更優雅的方式。

?

盡管大多數編譯器在優化時，會把常用的參數或者局部變量放入寄存器中。但用棧來管理函數調用時的臨時變量（局部變量和參數）是通用做法，前者只是輔助手段，且只在當前函數中使用，一旦調用下一層函數，這些值仍然要存入棧中才行。

?

通常情況下，棧向下（低地址）增長，每向棧中PUSH一個元素，棧頂就向低地址擴展，每從棧中POP一個元素，棧頂就向高地址回退。一個有興趣的問題：在x86平臺上，棧頂寄存器為ESP，那么ESP的值在是PUSH操作之前修改呢，還是在PUSH操作之后修改呢？PUSH ESP這條指令會向棧中存入什么數據呢？據說x86系列CPU中，除了286外，都是先修改ESP，再壓棧的。由于286沒有CPUID指令，有的OS用這種方法檢查286的型號。

?

一個函數內的局部變量以及其調用下一級函數的參數，所占用的內存空間作為一個基本的單元，稱為一個幀(frame)。在gdb里，f命令就是用來查看指定幀的信息的。在兩個frame之間通過還存有其它信息，比如上一層frame的分界地址(EBP)等。

?

關于棧的基本知識，就先介紹這么多，我們下面來看看一些關于棧的技巧及應用：

1.????????backtrace的實現

callstack調試器的基本功能之一，利用此功能，你可以看到各級函數的調用關系。在gdb中，這一功能被稱為backtrace，輸入bt命令就可以看到當前函數的callstack。它的實現多少有些有趣，我們在這里研究一下。

?

我們先看看棧的基本模型

?

?

要實現callstack我們需要知道以下信息：

l????????調用函數時的指令地址（即當時的EIP）。

l????????指令地址對應的源代碼代碼位置。

關于第一點，從上表中，我們可以看出，棧中存有各級EIP的值，我們取出來就行了。用下面的代碼可以輕易實現：

?

程序輸出：

0x8048460

0x804849c

0x80484a9

0x80484cc

?

關于第二點，如何把指令地址與行號對應起來，這也很簡單。可以從MAP文件或者ELF中查詢。Binutil帶有一個addr2line的小工具，可以幫助實現這一點。

[root@linux bt]# addr2line? 0x804849c -e bt.exe

/root/test/bt/bt.c:42

?

2.????????alloca的實現

大家都知道動態分配的內存，一定要釋放掉，否則就會有內存泄露。可能鮮有人知，動態分配的內存，可以不用釋放。Alloca就是這樣一個函數，最后一個a代表auto，即自動釋放的意思。

?

Alloca是在棧中分配內存的。即然是在棧中分配，就像其它在棧中分配的臨時變量一樣，在當前函數調用完成時，這塊內存自動釋放。

?

正如我們前面講過，棧的大小是有限制的，普通線程的棧只有10M大小，所以在分配時，要量力而行，且不要分配過大內存。

?

Alloca可能會漸漸的退出歷史舞臺，原因是新的C/C++標準都支持變長數組。比如int array[n]，老版本的編譯器要求n是常量，而新編譯器允許n是變量。編譯器支持的這一功能完全可以取代alloca。

?

這不是一個標準函數，但像linux和win32等大多數平臺都支持。即使少數平臺不支持，要自己實現也不難。這里我們簡單介紹一下alloca的實現方法。

?

我們先看看一個小程序，再看看它對應的匯編代碼，一切都清楚了。

?

匯編代碼為：

?

?

其中關鍵的一條指令為：sub??? $0x410,%esp

由此可以看出實現alloca，僅僅是把ESP減去指定大小，擴大棧空間（記記住棧是向下增長），這塊空間就是分配的內存。

?

3.????????可變參數的實現。

對新手來說，可變參數的函數也是比較神奇。還是以一個小程序來說明它的實現。

?

?

我們看看對應的匯編代碼：

?

?

從匯編代碼中，我們可以看出，參數是逆序入棧的。在取參數時，先讓ap指向第一個參數，又因為棧是向下增長的，不斷把指針向上移動就可以取出所有參數了。

進階3：

全局內存

?

?

有人可能會說，全局內存就是全局變量嘛，有必要專門一章來介紹嗎？這么簡單的東西，還能玩出花來？我從來沒有深究它，不一樣寫程序嗎？關于全局內存這個主題雖然玩不出花來，但確實有些重要，了解這些知識，對于優化程序的時間和空間很有幫助。因為有好幾次這樣經歷，我才決定花一章篇幅來介紹它。

?

正如大家所知道的，全局變量是放在全局內存中的，但反過來卻未必成立。用static修飾的局部變量就是放在放全局內存的，它的作用域是局部的，但生命期是全局的。在有的嵌入式平臺中，堆實際上就是一個全局變量，它占用相當大的一塊內存，在運行時，把這塊內存進行二次分配。

?

這里我們并不強調全局變量和全局內存的差別。在本文中，全局強調的是它的生命期，而不是它的作用域，所以有時可能把兩者的概念互換。

?

一般來說，在一起定義的兩個全局變量，在內存的中位置是相鄰的。這是一個簡單的常識，但有時挺有用，如果一個全局變量被破壞了，不防先查查其前后相關變量的訪問代碼，看看是否存在越界訪問的可能。

?

在ELF格式的可執行文件中，全局內存包括三種：bss、data和rodata。其它可執行文件格式與之類似。了解了這三種數據的特點，我們才能充分發揮它們的長處，達到速度與空間的最優化。

?

1.????????bss

已經記不清bss代表Block Storage Start還是Block Started by Symbol。像這我這種沒有用過那些史前計算機的人，終究無法明白這樣怪異的名字，也就記不住了。不過沒有關系，重要的是，我們要清楚bss全局變量有什么樣特點，以及如何利用它。

?

通俗的說，bss是指那些沒有初始化的和初始化為0的全局變量。它有什么特點呢，讓我們來看看一個小程序的表現。

?

[root@localhost bss]# gcc -g bss.c -o bss.exe

[root@localhost bss]# ll

total 12

-rw-r--r-- 1root root?? 84Jun 22 14:32 bss.c

-rwxr-xr-x1 root root 5683 Jun 22 14:32 bss.exe

?

變量bss_array的大小為4M，而可執行文件的大小只有5K。由此可見，bss類型的全局變量只占運行時的內存空間，而不占文件空間。

?

另外，大多數操作系統，在加載程序時，會把所有的bss全局變量全部清零，無需要你手工去清零。但為保證程序的可移植性，手工把這些變量初始化為0也是一個好習慣。

?

2.????????data

與bss相比，data就容易明白多了，它的名字就暗示著里面存放著數據。當然，如果數據全是零，為了優化考慮，編譯器把它當作bss處理。通俗的說，data指那些初始化過（非零）的非const的全局變量。它有什么特點呢，我們還是來看看一個小程序的表現。

?

?

[root@localhostdata]# gcc-gdata.c -odata.exe

[root@localhostdata]# ll

total 4112

-rw-r--r-- 1root root????? 85Jun 22 14:35 data.c

-rwxr-xr-x1 root root 4200025 Jun 22 14:35 data.exe

?

僅僅是把初始化的值改為非零了，文件就變為4M多。由此可見，data類型的全局變量是即占文件空間，又占用運行時內存空間的。

?

3.????????rodata

rodata的意義同樣明顯，ro代表read only，即只讀數據(const)。關于rodata類型的數據，要注意以下幾點：

l????????常量不一定就放在rodata里，有的立即數直接編碼在指令里，存放在代碼段(.text)中。

l????????對于字符串常量，編譯器會自動去掉重復的字符串，保證一個字符串在一個可執行文件(EXE/SO)中只存在一份拷貝。

l????????rodata是在多個進程間是共享的，這可以提高空間利用率。

l????????在有的嵌入式系統中，rodata放在ROM(如norflash)里，運行時直接讀取ROM內存，無需要加載到RAM內存中。

l????????在嵌入式linux系統中，通過一種叫作XIP（就地執行）的技術，也可以直接讀取，而無需要加載到RAM內存中。

?

由此可見，把在運行過程中不會改變的數據設為rodata類型的，是有很多好處的：在多個進程間共享，可以大大提高空間利用率，甚至不占用RAM空間。同時由于rodata在只讀的內存頁面(page)中，是受保護的，任何試圖對它的修改都會被及時發現，這可以幫助提高程序的穩定性。

?

4.????????變量與關鍵字

static關鍵字用途太多，以致于讓新手模糊。不過，總結起來就有兩種作用，改變生命期和限制作用域。如：

l????????修飾inline函數：限制作用域

l????????修飾普通函數：限制作用域

l????????修飾局部變量：改變生命期

l????????修飾全局變量：限制作用域

?

const關鍵字倒是比較明了，用const修飾的變量放在rodata里，字符串默認就是常量。對const，注意以下幾點就行了。

l????????指針常量：指向的數據是常量。如 const char* p = “abc”; p指向的內容是常量，但p本身不是常量，你可以讓p再指向”123”。

l????????常量指針：指針本身是常量。如：char* const p = “abc”; p本身就是常量，你不能讓p再指向”123”。

l????????指針常量 +常量指針：指針和指針指向的數據都是常量。const char* const p =”abc”;兩者都是常量，不能再修改。

?

violatile關鍵字通常用來修飾多線程共享的全局變量和IO內存。告訴編譯器，不要把此類變量優化到寄存器中，每次都要老老實實的從內存中讀取，因為它們隨時都可能變化。這個關鍵字可能比較生僻，但千萬不要忘了它，否則一個錯誤讓你調試好幾天也得不到一點線索。

進階4：

內存管理器(一)

?

?

?

內存管理算法多少有些神秘，我們很少想著去實現自己的內存管理算法，這也難怪：有這樣需求的情況并不多。其實，至于內存分配算法的實現，說簡單也簡單，說復雜也復雜。要寫一個簡單的，或許半天時間就可以搞掂，而要寫一個真正實用的，可能要花上你幾周甚至幾個月的時間。

?

malloc和free是兩個核心函數，而calloc和realloc之所以存在，完全是為了提高效率的緣故。否則完全可以用malloc和free的組合來模擬它們。

?

拿calloc函數的實現來說，在32位機上，內存管理器保證內存至少是4字節對齊的，其長度也會擴展到能被4字節整除，那么其清零算法就可以優化。可以一次清零4個字節，這大大提高清零速度。

?

拿realloc函數的實現來說，如果realloc的指針后面有足夠的空間，內存管理器可以直接擴展其大小，而無須拷貝原有內容。當然，新大小比原來還小時，更不拷貝了。相反，通過malloc和free來實現realloc時，兩種情況下都要拷貝，效率自然會低不少。

?

另外還有兩個非機標準的，但很常用的函數，也涉及到內存分配：strdup和strndup。這兩個函數在linux和win32下都支持，非常方便。這完全可以用malloc來模擬，而且沒有性能上的損失。

?

這里我們主要關注malloc和free兩個函數的實現，并以glibc 2.3.5(32位linux)為例分析。

?

內存管理器的目標

內存管理器為什么難寫？在設計內存管理算法時，要考慮什么因素？管理內存這是內存管理器的功能需求。正如設計其它軟件一樣，質量需求一樣占有重要的地位。分析內存管理算法之前，我們先看看對內存管理算法的質量需求有哪些：

?

l????????最大化兼容性

要實現內存管理器時，先要定義出分配器的接口函數。接口函數沒有必要標新立異，而是要遵循現有標準(如POSIX或者Win32)，讓使用者可以平滑的過度到新的內存管理器上。

?

l????????最大化可移植性

通常情況下，內存管理器要向OS申請內存，然后進行二次分配。所以，在適當的時候要擴展內存或釋放多余的內存，這要調用OS提供的函數才行。OS提供的函數則是因平臺而異，盡量抽象出平臺相關的代碼，保證內存管理器的可移植性。

?

l????????浪費最小的空間

內存管理器要管理內存，必然要使用自己一些數據結構，這些數據結構本身也要占內存空間。在用戶眼中，這些內存空間毫無疑問是浪費掉了，如果浪費在內存管理器身的內存太多，顯然是不可以接受的。

?

內存碎片也是浪費空間的罪魁禍首，若內存管理器中有大量的內存碎片，它們是一些不連續的小塊內存，它們總量可能很大，但無法使用，這也是不可以接受的。

?

l????????最快的速度

內存分配/釋放是常用的操作。按著2/8原則，常用的操作就是性能熱點，熱點函數的性能對系統的整體性能尤為重要。

?

l????????最大化可調性（以適應于不同的情況）

內存管理算法設計的難點就在于要適應用不同的情況。事實上，如果缺乏應用的上下文，是無法評估內存管理算法的好壞的。可以說在任何情況下，專用算法都比通用算法在時/空性能上的表現更優。

?

為每種情況都寫一套內存管理算法，顯然是不太合適的。我們不需要追求最優算法，那樣代價太高，能達到次優就行了。設計一套通用內存管理算法，通過一些參數對它進行配置，可以讓它在特定情況也有相當出色的表現，這就是可調性。

?

l????????最大化局部性(Locality)

大家都知道，使用cache可以提高程度的速度，但很多人未必知道cache使程序速度提高的真正原因。拿CPU內部的cache和RAM的訪問速度相比，速度可能相差一個數量級。兩者的速度上的差異固然重要，但這并不是提高速度的充分條件，只是必要條件。

?

另外一個條件是程序訪問內存的局部性(Locality)。大多數情況下，程序總訪問一塊內存附近的內存，把附近的內存先加入到cache中，下次訪問cache中的數據，速度就會提高。否則，如果程序一會兒訪問這里，一會兒訪問另外一塊相隔十萬八千里的內存，這只會使數據在內存與cache之間來回搬運，不但于提高速度無益，反而會大大降低程序的速度。

?

因此，內存管理算法要考慮這一因素，減少cache miss和page fault。

?

l????????最大化調試功能

作為一個C/C++程序員，內存錯誤可以說是我們的噩夢，上一次的內存錯誤一定還讓你記憶猶新。內存管理器提供的調試功能，強大易用，特別對于嵌入式環境來說，內存錯誤檢測工具缺乏，內存管理器提供的調試功能就更是不可或缺了。

?

l????????最大化適應性

前面說了最大化可調性，以便讓內存管理器適用于不同的情況。但是，對于不同情況都要去調設置，無疑太麻煩，是非用戶友好的。要盡量讓內存管理器適用于很廣的情況，只有極少情況下才去調設置。

?

設計是一個多目標優化的過程，有些目標之間存在著競爭。如何平衡這些競爭力是設計的難點之一。在不同的情況下，這些目標的重要性又不一樣，所以根本不存在一個最好的內存分配算法。

?

關于glibc的內存分配器，我們并打算做代碼級分析，只談談幾點有趣的東西：

1.????????Glibc分配算法概述：

l????????小于等于64字節：用pool算法分配。

l????????64到512字節之間：在最佳憑配算法分配和pool算法分配中取一種合適的。

l????????大于等于512字節：用最佳憑配算法分配。

l????????大于等于128K：直接調用OS提供的函數(如mmap)分配。

?

2.????????Glibc擴展內存的方式：

?

l????????int brk(void *end_data_segment);

本函數用于擴展堆空間（堆空間的定義可參考內存模型一章），用end_data_segment指明堆的結束地址。

l????????void *sbrk(ptrdiff_t increment);

本函數用于擴展堆空間（堆空間的定義可參考內存模型一章），用increment指定要增加的大小。

l????????void*? mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);

本函數用于分配大塊內存了，如前面所述大于128K的內存。

?

3.????????空指針和零長度內存

l????????free(NULL)會讓程序crash嗎？答案是不會，標準C要求free接受空指針，然后什么也不做。

l????????malloc(0)會分配成功嗎？答案是會的，它會返回一塊最小內存給你。

?

4.????????對齊與取整

l????????內存管理器會保證分配出來的內存地址是對齊的，通常是4或8字節對齊。

l????????內存管理器會對要求內存長度取整，讓內存長度能被4或8的整除。

5.????????已經分配內存的結構

?

如果前面有一塊有效內存塊的，則第一個size_t指明前一塊內存的大小。

第二個size_t指明自己的大小，同時還指明：自己是不是用mmap分配的(M)，前面是否有一個效內存塊（P）。你可能覺得奇怪，在32位機上，sizeof(size_t)就是32位，怎么還能留下兩個位來保存標志呢？前面我們說了，會對內存長度取整，保證最低2或3bits為0，即是空閑的。

?

6.????????空閑內存的管理

?

由此可以看出，最小內存塊的長度為16字節：

sizeof(size_t) +

sizeof(size_t) +

sizeof(void*) +

sizeof(void*) +

0

這一招非常管用，第一次看到時，感覺簡直太巧妙了。這使得無需要額外的內存來管理空閑塊，利用空閑塊自己，把空閑塊強制轉換成一個雙向鏈表就行了。

?

?

大內高手—共享內存與線程局部存儲

??

城里的人想出去，城外的人想進來。這是《圍城》里的一句話，它可能比《圍城》本身更加有名。我想這句話的前提是，要么住在城里，要么住在城外，二者只能居其一。否則想住在城里就可以住在城里，想住在城外就可以住在城外，你大可以選擇單日住在城里，雙日住在城外，也就沒有心思去想出去還是進來了。

?

理想情況是即可以住在城里又可以住在城外，而不是走向極端。盡管像青蛙一樣的兩棲動物絕不會比人類更高級，但能適應于更多環境的能力畢竟有它的優勢。技術也是如此，共享內存和線程局部存儲就是實例，它們是為了防止走向內存完全隔離和完全共享兩個極端的產物。

?

當我們發明了MMU時，大家認為天下太平了，各個進程空間獨立，互不影響，程序的穩定性將大提高。但馬上又認識到，進程完全隔離也不行，因為各個進程之間需要信息共享。于是就搞出一種稱為共享內存的東西。

?

當我們發明了線程的時，大家認為這下可爽了，線程可以并發執行，創建和切換的開銷相對進程來說小多了。線程之間的內存是共享的，線程間通信快捷又方便。但馬上又認識到，有些信息還是不共享為好，應該讓各個線程保留一點隱私。于是就搞出一個線程局部存儲的玩意兒。

?

共享內存和線程局部存儲是兩個重要又不常用的東西，平時很少用，但有時候又離不了它們。本文介紹將兩者的概念、原理和使用方法，把它們放在自己的工具箱里，以供不時之需。

?

1.????????共享內存

大家都知道進程空間是獨立的，它們之間互不影響。比如同是0xabcd1234地址的內存，在不同的進程中，它們的數據是不同的，沒有關系的。這樣做的好處很多：每個進程的地址空間變大了，它們獨占4G(32位)的地址空間，讓編程實現更容易。各個進程空間獨立，一個進程死掉了，不會影響其它進程，提高了系統的穩定性。

?

要做到進程空間獨立，光靠軟件是難以實現的，通常要依賴于硬件的幫助。這種硬件通常稱為MMU(Memory Manage Unit)，即所謂的內存管理單元。在這種體系結構下，內存分為物理內存和虛擬內存兩種。物理內存就是實際的內存，你機器上裝了多大內存就有多大內存。而應用程序中使用的是虛擬內存，訪問內存數據時，由MMU根據頁表把虛擬內存地址轉換對應的物理內存地址。

?

MMU把各個進程的虛擬內存映射到不同的物理內存上，這樣就保證了進程的虛擬內存是獨立的。然而，物理內存往往遠遠少于各個進程的虛擬內存的總和。怎么辦呢，通常的辦法是把暫時不用的內存寫到磁盤上去，要用的時候再加載回內存中來。一般會搞一個專門的分區保存內存數據，這就是所謂的交換分區。

?

這些工作由內核配合MMU硬件完成，內存管理是操作系統內核的重要功能。其中為了優化性能，使用了不少高級技術，所以內存管理通常比較復雜。比如：在決定把什么數據換出到磁盤上時，采用最近最少使用的策略，把常用的內存數據放在物理內存中，把不常用的寫到磁盤上，這種策略的假設是最近最少使用的內存在將來也很少使用。在創建進程時使用COW(Copy on Write)的技術，大大減少了內存數據的復制。為了提高從虛擬地址到物理地址的轉換速度，硬件通常采用TLB技術，把剛轉換的地址存在cache里，下次可以直接使用。

?

從虛擬內存到物理內存的映射并不是一個字節一個字節映射的，而是以一個稱為頁(page)最小單位的為基礎的，頁的大小視硬件平臺而定，通常是4K。當應用程序訪問的內存所在頁面不在物理內存中時，MMU產生一個缺頁中斷，并掛起當前進程，缺頁中斷負責把相應的數據從磁盤讀入內存中，再喚醒掛起的進程。

?

進程的虛擬內存與物理內存映射關系如下圖所示(灰色頁為被不在物理內存中的頁):

?

?

?

也許我們很少直接使用共享內存，實際上除非性能上有特殊要求，我更愿意采用socket或者管道作為進程間通信的方式。但我們常常間接的使用共享內存，大家都知道共享庫（或稱為動態庫）的優點是，多個應用程序可以公用。如果每個應用程序都加載一份共享庫到內存中，顯然太浪費了。所以操作系統把共享庫放在共享內存中，讓多個應用程序共享。另外，同一個應用程序運行多個實例時，也采用同樣的方式，保證內存中只有一份可執行代碼。這樣的共享內存是設為只讀屬性的，防止應用程序無意中破壞它們。當調試器要設置斷點時，相應的頁面被拷貝一分，設置為可寫的，再向其中寫入斷點指令。這些事情完全由操作系統等底層軟件處理了，應用程序本身無需關心。

?

共享內存是怎么實現的呢？我們來看看下圖(黃色頁為共享內存)：

?

?

?

由上圖可見，實現共享內存非常容易，只是把兩個進程的虛擬內存映射同一塊物理內存就行了。不過要注意，物理內存相同而虛擬地址卻不一定相同，如圖中所示進程1的page5和進程2的page2都映射到物理內存的page1上。

?

如何在程序中使用共享內存呢？通常很簡單，操作系統或者函數庫提供了一些API給我們使用。如：

?

Linux:

?

?

Win32:

?

HANDLE CreateFileMapping(

? HANDLE hFile,?????? ????????????????// handle to file

? LPSECURITY_ATTRIBUTES lpAttributes, // security

? DWORD flProtect,??????????????????? // protection

? DWORD dwMaximumSizeHigh,??????????? // high-order DWORD of size

? DWORD dwMaximumSizeLow,???????????? // low-order DWORD of size

? LPCTSTR lpName????????????????????? // object name

);

BOOL UnmapViewOfFile(

? LPCVOID lpBaseAddress?? // starting address

);

?

2.????????線程局部存儲(TLS)

同一個進程中的多個線程，它們的內存空間是共享的（棧除外），在一個線程修改的內存內容，對所有線程都生效。這是一個優點也是一個缺點。說它是優點，線程的數據交換變得非常快捷。說它是缺點，一個線程死掉了，其它線程也性命不保;多個線程訪問共享數據，需要昂貴的同步開銷，也容易造成同步相關的BUG;。

?

在unix下，大家一直都對線程不是很感興趣，直到很晚以后才引入線程這東西。像X Sever要同時處理N個客戶端的連接，每秒鐘要響應上百萬個請求，開發人員寧愿自己實現調度機制也不用線程。讓人很難想象X Server是單進程單線程模型的。再如Apache(1.3x)，在unix下的實現也是采用多進程模型的，把像記分板等公共信息放入共享內存中，也不愿意采用多線程模型。

?

正如《unix編程藝術》中所說，線程局部存儲的出現，使得這種情況出現了轉機。采用線程局部存儲，每個線程有一定的私有空間。這可以避免部分無意的破壞，不過仍然無法避免有意的破壞行為。

?

個人認為，這完全是因為unix程序不喜歡面向對象方法引起的，數據沒有很好的封裝起來，全局變量滿天飛，在多線程情況下自然容易出問題。如果采用面向對象的方法，可以讓這種情況大為改觀，而無需要線程局部存儲來幫忙。

?

當然，多一種技術就多一種選擇，知道線程局部存儲還是有用的。盡管只用過幾次線程局部存儲的方法，在那種情況下，沒有線程局部存儲，確實很難用其它辦法實現。

?

線程局部存儲在不同的平臺有不同的實現，可移植性不太好。幸好要實現線程局部存儲并不難，最簡單的辦法就是建立一個全局表，通過當前線程ID去查詢相應的數據，因為各個線程的ID不同，查到的數據自然也不同了。

?

大多數平臺都提供了線程局部存儲的方法，無需要我們自己去實現：

?

linux:

?

Win32

?

?

~~end~~

進階5：

常見內存錯誤

?

?

隨著諸如代碼重構和單元測試等方法引入實踐，調試技能漸漸弱化了，甚至有人主張廢除調試器。這是有道理的，原因在于調試的代價往往太大了，特別是調試系統集成之后的BUG，一個BUG花了幾天甚至數周時間并非罕見。

?

而這些難以定位的BUG基本上可以歸為兩類：內存錯誤和并發問題。而又以內存錯誤最為普遍，即使是久經沙場的老手，也有時也難免落入陷阱。前事不忘，后世之師，了解這些常見的錯誤，在編程時就加以注意，把出錯的概率降到最低，可以節省不少時間。

?

這些列舉一些常見的內存錯誤，供新手參考。

?

1.????????內存泄露。

大家都知道，在堆上分配的內存，如果不再使用了，應該把它釋放掉，以便后面其它地方可以重用。在C/C++中，內存管理器不會幫你自動回收不再使用的內存。如果你忘了釋放不再使用的內存，這些內存就不能被重用，就造成了所謂的內存泄露。

?

把內存泄露列為首位，倒并不是因為它有多么嚴重的后果，而因為它是最為常見的一類錯誤。一兩處內存泄露通常不至于讓程序崩潰，也不會出現邏輯上的錯誤，加上進程退出時，系統會自動釋放該進程所有相關的內存，所以內存泄露的后果相對來說還是比較溫和的。當然了，量變會產生質變，一旦內存泄露過多以致于耗盡內存，后續內存分配將會失敗，程序可能因此而崩潰。

?

現在的PC機內存夠大了，加上進程有獨立的內存空間，對于一些小程序來說，內存泄露已經不是太大的威脅。但對于大型軟件，特別是長時間運行的軟件，或者嵌入式系統來說，內存泄露仍然是致命的因素之一。

?

不管在什么情況下，采取比較謹慎的態度，杜絕內存泄露的出現，都是可取的。相反，認為內存有的是，對內存泄露放任自流都不是負責的。盡管一些工具可以幫助我們檢查內存泄露問題，我認為還是應該在編程時就仔細一點，及早排除這類錯誤，工具只是用作驗證的手段。

?

2.????????內存越界訪問。

內存越界訪問有兩種：一種是讀越界，即讀了不屬于自己的數據，如果所讀的內存地址是無效的，程度立刻就崩潰了。如果所讀內存地址是有效的，在讀的時候不會出問題，但由于讀到的數據是隨機的，它會產生不可預料的后果。另外一種是寫越界，又叫緩沖區溢出。所寫入的數據對別人來說是隨機的，它也會產生不可預料的后果。

?

內存越界訪問造成的后果非常嚴重，是程序穩定性的致命威脅之一。更麻煩的是，它造成的后果是隨機的，表現出來的癥狀和時機也是隨機的，讓BUG的現象和本質看似沒有什么聯系，這給BUG的定位帶來極大的困難。

?

一些工具可以夠幫助檢查內存越界訪問的問題，但也不能太依賴于工具。內存越界訪問通常是動態出現的，即依賴于測試數據，在極端的情況下才會出現，除非精心設計測試數據，工具也無能為力。工具本身也有一些限制，甚至在一些大型項目中，工具變得完全不可用。比較保險的方法還是在編程是就小心，特別是對于外部傳入的參數要仔細檢查。

?

3.????????野指針。

野指針是指那些你已經釋放掉的內存指針。當你調用free(p)時，你真正清楚這個動作背后的內容嗎？你會說p指向的內存被釋放了。沒錯，p本身有變化嗎？答案是p本身沒有變化。它指向的內存仍然是有效的，你繼續讀寫p指向的內存，沒有人能攔得住你。

?

釋放掉的內存會被內存管理器重新分配，此時，野指針指向的內存已經被賦予新的意義。對野指針指向內存的訪問，無論是有意還是無意的，都為此會付出巨大代價，因為它造成的后果，如同越界訪問一樣是不可預料的。

?

釋放內存后立即把對應指針置為空值，這是避免野指針常用的方法。這個方法簡單有效，只是要注意，當然指針是從函數外層傳入的時，在函數內把指針置為空值，對外層的指針沒有影響。比如，你在析構函數里把this指針置為空值，沒有任何效果，這時應該在函數外層把指針置為空值。

?

4.????????訪問空指針。

空指針在C/C++中占有特殊的地址，通常用來判斷一個指針的有效性。空指針一般定義為0。現代操作系統都會保留從0開始的一塊內存，至于這塊內存有多大，視不同的操作系統而定。一旦程序試圖訪問這塊內存，系統就會觸發一個異常。

?

操作系統為什么要保留一塊內存，而不是僅僅保留一個字節的內存呢？原因是：一般內存管理都是按頁進行管理的，無法單純保留一個字節，至少要保留一個頁面。保留一塊內存也有額外的好處，可以檢查諸如p=NULL; p[1]之類的內存錯誤。

?

在一些嵌入式系統(如arm7)中，從0開始的一塊內存是用來安裝中斷向量的，沒有MMU的保護，直接訪問這塊內存好像不會引發異常。不過這塊內存是代碼段的，不是程序中有效的變量地址，所以用空指針來判斷指針的有效性仍然可行。

?

在訪問指針指向的內存時，在確保指針不是空指針。訪問空指針指向的內存，通常會導致程度崩潰，或者不可預料的錯誤。

?

5.????????引用未初始化的變量。

未初始化變量的內容是隨機的(像VC一類的編譯器會把它們初始化為固定值，如0xcc)，使用這些數據會造成不可預料的后果，調試這樣的BUG也是非常困難的。

?

對于態度嚴謹的程度員來說，防止這類BUG非常容易。在聲明變量時就對它進行初始化，是一個編程的好習慣。另外也要重視編譯器的警告信息，發現有引用未初始化的變量，立即修改過來。

?

6.????????不清楚指針運算。

對于一些新手來說，指針常常讓他們犯糊涂。

?

比如int *p = …; p+1等于(size_t)p + 1嗎

老手自然清楚，新手可能就搞不清了。事實上, p+n等于 (size_t)p + n * sizeof(*p)

?

指針是C/C++中最有力的武器，功能非常強大，無論是變量指針還是函數指針，都應該掌握都非常熟練。只要有不確定的地方，馬上寫個小程序驗證一下。對每一個細節都了然于胸，在編程時會省下不少時間。

?

7.????????結構的成員順序變化引發的錯誤。

在初始化一個結構時，老手可能很少像新手那樣老老實實的，一個成員一個成員的為結構初始化，而是采用快捷方式，如：

?

?

以上這種方式是非常危險的，原因在于你對結構的內存布局作了假設。如果這個結構是第三方提供的，他很可能調整結構中成員的相對位置。而這樣的調整往往不會在文檔中說明，你自然很少去關注。如果調整的兩個成員具有相同數據類型，編譯時不會有任何警告，而程序的邏輯上可能相距十萬八千里了。

?

正確的初始化方法應該是（當然，一個成員一個成員的初始化也行）：

?

?

8.????????結構的大小變化引發的錯誤。