C/C++作爲偏底層的語言，我們往往可以使用其對內存進行直接操作，相對來說比較靈活，但任何事情都有兩面性，對內存的操作簡便也經常導致程序出現內存bug。所以我們在編程時要特別重視內存和指針等概念，儘量避免bug，而這均取決於我們對內存的理解。
本文就從C/C++的內存基礎知識講起，讓我們對內存有一個更深入的理解。
一、對內的分配
32位操作系統支持4GB內存的連續訪問，但通常把內存分爲兩個2GB的空間，每個進程在運行時最大可以使用2GB的私有內存（0x00000000—0x7FFFFFFF）。即理論上支持如下的大數組：
C++代碼
char szBuffer[2*1024*1024*1024];
當然，由於在實際運行時，程序還有代碼段、臨時變量段、動態內存申請等，實際上是不可能用到上述那麼大的數組的。
至於高端的2GB內存地址（0x80000000—0xFFFFFFFF），操作系統一般內部保留使用，即供操作系統內核代碼使用。在Windows和Linux平臺上，一些動態鏈接庫（Windows的dll，Linux的so）以及ocx控件等，由於是跨進程服務的，因此一般也在高2GB內存空間運行。
可以看到，每個進程都能看到自己的2GB內存以及系統的2GB內存，但是不同進程之間是無法彼此看到對方的。當然，操作系統在底層做了很多工作，比如磁盤上的虛擬內存交換（請看下以標題），不同的內存塊動態映射等等。
二、虛擬內存
虛擬內存的基本思想是：用廉價但緩慢的磁盤來擴充快速卻昂貴的內存。在一定時刻，程序實際需要使用的虛擬內存區段的內容就被載入物理內存中。當物理內存中的數據有一段時間未被使用，它們就可能被轉移到硬盤中，節省下來的物理內存空間用於載入需要使用的其他數據。
在進程執行過程中，操作系統負責具體細節，使每個進程都以爲自己擁有整個地址空間的獨家訪問權。這個幻覺是通過“虛擬內存”實現的。所有進程共享機器的 物理內存，當內存使用完時就用磁盤保存數據。在進程運行時，數據在磁盤和內存之間來回移動。內存管理硬件負責把虛擬地址翻譯爲物理地址，並讓一個進程始終 運行於系統的真正內存中，應用程序員只看到虛擬地址，並不知道自己的進程在磁盤與內存之間來回切換。
從潛在的可能性上說，與進程有關的所有內存都將被系統所使用，如果該進程可能不會馬上運行（可能它的優先級低，也可能是它處於睡眠狀態），操作系統可以暫時取回所有分配給它的物理內存資源，將該進程的所有相關信息都備份到磁盤上。
進程只能操作位於物理內存中的頁面。當進程引用一個不在物理內存中的頁面時，MMU就會產生一個頁錯誤。內存對此事做出響應，並判斷該引用是否有效。如 果無效，內核向進程發出一個“segmentation violation（段違規）”的信號，內核從磁盤取回該頁，換入內存中，一旦頁面進入內存，進程便被解鎖，可以重新運行--進程本身並不知道它曾經因爲 頁面換入事件等待了一會。
三、內存的使用
對於程序員，我們最重要的是能理解不同進程間私有內存空間的含義。C和C++的編譯器把私有內存分爲3塊：基棧、浮動棧和堆。如下圖：
（1）基棧：也叫靜態存儲區，這是編譯器在編譯期間就已經固定下來必須要使用的內存，如程序的代碼段、靜態變量、全局變量、const常量等。
（2）浮動棧：很多書上稱爲“棧”，就是程序開始運行，隨着函數、對象的一段執行，函數內部變量、對象的內部成員變量開始動態佔用內存，浮動棧一般都有生命週期，函數結束或者對象析構，其對應的浮動棧空間的就拆除了，這部分內容總是變來變去，內存佔用也不是固定，因此叫浮動棧。
（3）堆：C 和C++語言都支持動態內存申請，即程序運行期可以自由申請內存，這部分內存就是在堆空間申請的。堆位於2GB的最頂端，自上向下分配，這是避免和浮動棧 混到一起，不好管理。我們用到malloc和new都是從堆空間申請的內存，new比malloc多了對象的支持，可以自動調用構造函數。另外，new創 建對象，其成員變量位於堆裏面。
我們來看一個例子：
C++代碼
const int n = 100;
void Func(void)
{
char ch = 0;
char* pBuff = (char*)malloc(10);
//…
}
這個函數如果運行，其中n由於是全局靜態變量，位於基棧，ch和pBuff這兩個函數內部變量，ch位於浮動棧，而pBuff指向的由malloc分配的內存區，則位於堆棧。
在內存理解上，最著名的例子就是線程啓動時的參數傳遞。
函數啓動一個線程，很多時候需要向線程傳參數，但是線程是異步啓動的，即很可能啓動函數已經退出了，而線程函數都還沒有正式開始運行，因此，絕不能用啓 動函數的內部變量給線程傳參。道理很簡單，函數的內部變量在浮動棧，但函數退出時，浮動棧自動拆除，內存空間已經被釋放了。當線程啓動時，按照給的參數指 針去查詢變量，實際上是在讀一塊無效的內存區域，程序會因此而崩潰。
那怎麼辦呢？我們應該直接用malloc函數給需要傳遞的參數分配一塊內存區域，將指針傳入線程，線程收到後使用，最後線程退出時，free釋放。
我們來看例子：
C++代碼
//這個結構體就是參數表
typedef struct _CListen_ListenAcceptTask_Param_
{
Linux_Win_SOCKET m_nSocket;
//其他參量… …
}SCListenAcceptTaskParam;
//習慣性寫法，設置結構體後，立即聲明結構體的尺寸，爲後續malloc提供方便
const ULONG SCListenAcceptTaskParamSize = sizeof(SCListenAcceptTaskParam);
//這裏接收到連接請求，申請參數區域，將關鍵信息帶入參數區域，幫助後續線程工作。
bool CListen::ListenTaskCallback(void* pCallParam,int& nStatus)
{
//正常的函數邏輯… …
//假定s是accept到的socket，需要傳入後續線程工作
//在此準備一塊參數區域，從遠堆上申請
SCListenAcceptTaskParam* pParam = (SCListenAcceptTaskParam*) malloc(SCListenAcceptTaskParamSize);
//給參數區域賦值
pParam->m_nSocket = s;
//此處啓動線程，將pParam傳遞給線程… …
//正常的函數邏輯… …
}
//這是線程函數，負責處理上文accept到的socket
bool CListen::ListenAcceptTask(void* pCallParam,int& nStatus)
{
//第一句話就是強制指針類型轉換，獲得外界傳入的參數區域
SCListenAcceptTaskParam* pParam= (SCListenAcceptTaskParam*)pCallParam;
//正常的函數邏輯… …
//退出前，必須要做的工作，確保資源不被泄露
close(pParam->m_nSocket); //關閉socket
free(pCallParam); // free傳入的參數區域
//… …
}
四、內存bug
無規則的濫用內存和指針會導致大量的bug，程序員應該對內存的使用保持高度的敏感性和警惕性，謹慎地使用內存資源。
使用內存時最容易出現的bug是：
（1）壞指針值錯誤：在指針賦值之前就用它來引用內存，或者向庫函數傳送一個壞指針，第三種可能導致壞指針的原因是對指針進行釋放之後再訪問它的內容。可以修改free語句，在指針釋放之後再將它置爲空值。
C++代碼
free(p);
p = NULL;
這樣，如果在指針釋放之後繼續使用該指針，至少程序能在終止之前進行信息轉儲。
（2）改寫（overwrite）錯誤：越過數組邊界寫入數據，在動態分配的內存兩端之外寫入數據，或改寫一些堆管理數據結構（在動態分配內存之前的區域寫入數據就很容易發生這種情況）
C++代碼
p = malloc(256);
p[-1] = 0;
p[256] = 0;
（3）指針釋放引起的錯誤：釋放同一個內存塊兩次，或釋放一塊未曾使用malloc分配的內存，或釋放仍在使用中的內存，或釋放一個無效的指針。一個極爲常見的與釋放內存有關的錯誤就像下面這樣：
C++代碼
struct node *p, *tart, *temp;
for(p = start; p ; p = p->next)
{
free(p);
}
上面的代碼會在第二次迭代時對已經釋放的指針再次進行釋放，這樣就會導致不可預料的錯誤。
正確的迭代方法：
C++代碼
struct node *p, *tart, *temp;
for(p = start; p ; p = temp)
{
temp = p->next;
free(p);
}
轉載地址：http://www.jizhuomi.com/software/281.html