解密C語言中的指針和內存泄漏，這些陷阱要避開

對于任何使用 C 語言的人，如果問他們 C 語言的最大煩惱是什么，其中許多人可能會回答說是指針和內存泄漏。這些的確是消耗了開發(fā)人員大多數(shù)調試時間的事項。指針和內存泄漏對某些開發(fā)人員來說似乎令人畏懼，但是一旦您了解了指針及其關聯(lián)內存操作的基礎，它們就是您在 C 語言中擁有的最強大工具。

本文將與您分享開發(fā)人員在開始使用指針來編程前應該知道的秘密。本文內容包括：

1. 導致內存破壞的指針操作類型
2. 在使用動態(tài)內存分配時必須考慮的檢查點
3. 導致內存泄漏的場景

如果您預先知道什么地方可能出錯，那么您就能夠小心避免陷阱，并消除大多數(shù)與指針和內存相關的問題。

內存泄露在維基百科中的解釋如下：

在計算機科學中，內存泄漏指由于疏忽或錯誤造成程序未能釋放已經不再使用的內存。內存泄漏并非指內存在物理上的消失，而是應用程序分配某段內存后，由于設計錯誤，導致在釋放該段內存之前就失去了對該段內存的控制，從而造成了內存的浪費。

在C++中出現(xiàn)內存泄露的主要原因就是程序猿在申請了內存后(malloc(), new)，沒有及時釋放沒用的內存空間，甚至消滅了指針導致該區(qū)域內存空間根本無法釋放。

知道了出現(xiàn)內存泄露的原因就能知道如何應對內存泄露，即：不用了的內存空間記得釋放，不釋放留著過年哇！

內存泄漏可能會導致嚴重的后果：
●  程序運行后，隨著時間占用了更多的內存，最后無內存可用而崩潰；
●  程序消耗了大量的內存，導致其他程序無法正常使用；
●  程序消耗了大量內存，導致消費者選用了別人的程序而不是你的；
●  經常做出內存泄露bug的程序猿被公司開出而貧困潦倒。

如何知道自己的程序存在內存泄露？
根據(jù)內存泄露的原因及其惡劣的后果，我們可以通過其主要表現(xiàn)來發(fā)現(xiàn)程序是否存在內存泄漏：程序長時間運行后內存占用率一直不斷的緩慢的上升，而實際上在你的邏輯中并沒有這么多的內存需求。

如何定位到泄露點呢？
根據(jù)原理，我們可以先review自己的代碼，利用"查找"功能，查詢new與delete，看看內存的申請與釋放是不是成對釋放的，這使你迅速發(fā)現(xiàn)一些邏輯較為簡單的內存泄露情況。

如果依舊發(fā)生內存泄露，可以通過記錄申請與釋放的對象數(shù)目是否一致來判斷。在類中追加一個靜態(tài)變量 static int count;在構造函數(shù)中執(zhí)行count++;在析構函數(shù)中執(zhí)行count--;，通過在程序結束前將所有類析構，之后輸出靜態(tài)變量，看count的值是否為0，如果為0,則問題并非出現(xiàn)在該處，如果不為0，則是該類型對象沒有完全釋放。

檢查類中申請的空間是否完全釋放，尤其是存在繼承父類的情況，看看子類中是否調用了父類的析構函數(shù)，有可能會因為子類析構時沒有是否父類中申請的內存空間。

對于函數(shù)中申請的臨時空間，認真檢查，是否存在提前跳出函數(shù)的地方沒有釋放內存。

有幾種問題場景可能會出現(xiàn)，從而可能在完成生成后導致問題。在處理指針時，您可以使用本文中的信息來避免許多問題。

在本例中，p 已被分配了 10 個字節(jié)。這 10 個字節(jié)可能包含垃圾數(shù)據(jù)，如圖 1 所示。

char *p = malloc ( 10 );

圖 1. 垃圾數(shù)據(jù)

如果在對這個 p 賦值前，某個代碼段嘗試訪問它，則可能會獲得垃圾值，您的程序可能具有不可預測的行為。p 可能具有您的程序從未曾預料到的值。

良好的習慣是始終結合使用 memset 和 malloc分配內存，或者使用 calloc。

char *p = malloc (10);
memset(p,’\0’,10);

現(xiàn)在，即使同一個代碼段嘗試在對 p 賦值前訪問它，該代碼段也能正確處理 Null 值（在理想情況下應具有的值），然后將具有正確的行為。

由于 p 已被分配了 10 個字節(jié)，如果某個代碼片段嘗試向 p 寫入一個 11 字節(jié)的值，則該操作將在不告訴您的情況下自動從其他某個位置“吃掉”一個字節(jié)。讓我們假設指針 q 表示該內存。

圖 2. 原始 q 內容

圖 3. 覆蓋后的 q 內容

結果，指針 q 將具有從未預料到的內容。即使您的模塊編碼得足夠好，也可能由于某個共存模塊執(zhí)行某些內存操作而具有不正確的行為。下面的示例代碼片段也可以說明這種場景。

char *name = (char *) malloc(11); // Assign some value to namememcpy ( p,name,11); // Problem begins here

在本例中，memcpy 操作嘗試將 11 個字節(jié)寫到 p，而后者僅被分配了 10 個字節(jié)。

作為良好的實踐，每當向指針寫入值時，都要確保對可用字節(jié)數(shù)和所寫入的字節(jié)數(shù)進行交叉核對。一般情況下，memcpy 函數(shù)將是用于此目的的檢查點。

內存讀取越界 (overread) 是指所讀取的字節(jié)數(shù)多于它們應有的字節(jié)數(shù)。這個問題并不太嚴重，在此就不再詳述了。下面的代碼提供了一個示例。

char *ptr = (char *)malloc(10);char name[20] ;memcpy ( name,ptr,20); // Problem begins here

在本例中，memcpy 操作嘗試從 ptr 讀取 20 個字節(jié)，但是后者僅被分配了 10 個字節(jié)。這還會導致不希望的輸出。

內存泄漏可能真正令人討厭。下面的列表描述了一些導致內存泄漏的場景。

重新賦值
我將使用一個示例來說明重新賦值問題。

char *memoryArea = malloc(10);char *newArea = malloc(10);

這向如下面的圖 4 所示的內存位置賦值。

圖 4. 內存位置

memoryArea 和 newArea 分別被分配了 10 個字節(jié)，它們各自的內容如圖 4 所示。如果某人執(zhí)行如下所示的語句（指針重新賦值）……

memoryArea = newArea;

則它肯定會在該模塊開發(fā)的后續(xù)階段給您帶來麻煩。

在上面的代碼語句中，開發(fā)人員將 memoryArea 指針賦值給 newArea 指針。結果，memoryArea 以前所指向的內存位置變成了孤立的，如下面的圖 5 所示。它無法釋放，因為沒有指向該位置的引用。這會導致 10 個字節(jié)的內存泄漏。

圖 5. 內存泄漏

在對指針賦值前，請確保內存位置不會變?yōu)楣铝⒌摹?/p>

首先釋放父塊
假設有一個指針 memoryArea，它指向一個 10 字節(jié)的內存位置。該內存位置的第三個字節(jié)又指向某個動態(tài)分配的 10 字節(jié)的內存位置，如圖 6 所示。

圖 6. 動態(tài)分配的內存

free(memoryArea)

如果通過調用 free 來釋放了 memoryArea，則 newArea 指針也會因此而變得無效。newArea 以前所指向的內存位置無法釋放，因為已經沒有指向該位置的指針。換句話說，newArea 所指向的內存位置變?yōu)榱斯铝⒌?，從而導致了內存泄漏?/p>

每當釋放結構化的元素，而該元素又包含指向動態(tài)分配的內存位置的指針時，應首先遍歷子內存位置（在此例中為 newArea），并從那里開始釋放，然后再遍歷回父節(jié)點。

這里的正確實現(xiàn)應該為：

free( memoryArea->newArea);free(memoryArea);

返回值的不正確處理
有時，某些函數(shù)會返回對動態(tài)分配的內存的引用。跟蹤該內存位置并正確地處理它就成為了 calling 函數(shù)的職責。

char *func ( ){ return malloc(20); // make sure to memset this location to ‘\0’…}
void callingFunc ( ){ func ( ); // Problem lies here}

在上面的示例中，callingFunc() 函數(shù)中對 func() 函數(shù)的調用未處理該內存位置的返回地址。結果，func() 函數(shù)所分配的 20 個字節(jié)的塊就丟失了，并導致了內存泄漏。

在開發(fā)組件時，可能存在大量的動態(tài)內存分配。您可能會忘了跟蹤所有指針（指向這些內存位置），并且某些內存段沒有釋放，還保持分配給該程序。

始終要跟蹤所有內存分配，并在任何適當?shù)臅r候釋放它們。事實上，可以開發(fā)某種機制來跟蹤這些分配，比如在鏈表節(jié)點本身中保留一個計數(shù)器（但您還必須考慮該機制的額外開銷）。

訪問空指針是非常危險的，因為它可能使您的程序崩潰。始終要確保您不是 在訪問空指針。

沒有躲過的坑--指針（內存泄露）

C++被人罵娘最多的就是指針。

夜深人靜的時候，拿出幾個使用指針容易出現(xiàn)的坑兒?？赡芪业恼Z言描述有些讓人費勁，盡量用代碼說話。

通過指向類的NULL指針調用類的成員函數(shù)

試圖用一個null指針調用類的成員函數(shù)，導致崩潰：

#include <iostream>using namespace std;class A{int value;public:void dumb() const {cout << "dumb()\n";}void set(int x) {cout << "set()\n"; value=x;}int get() const {cout << "get()\n"; return value;}};int main(){A *pA1 = new A;A *pA2 = NULL;pA1->dumb();pA1->set(10);pA1->get();pA2->dumb();pA2->set(20);//崩潰pA2->get();return 0;}

為什么會這樣？ 

通過非法指針調用函數(shù)，就相當于給函數(shù)傳遞了一個指向函數(shù)的非法指針！ 

但是為什么pA2->dumb()會成功呢？ 
因為導致崩潰的是訪問了成員變量??！

使用已經釋放的指針

struct X{int data;};int foo(){struct X *pX;pX = (struct X *) malloc(sizeof (struct X));pX->data = 10;free(pX);...return pX->data;}

使用未初始化的指針

如果你這樣寫，編譯器會提示你使用了未初始化的變量p。

void fooA(){int *p;*p = 100;}

那么如果我釋放一個初始化的指針呢？

void fooB(){int *p;free(p);}

結果是一樣的??！

釋放已經釋放的指針

直接看看代碼：

void fooA(){char *p;p = (char *)malloc(100);cout << "free(p)\n";free(p);cout << "free(p)\n";free(p);}

這樣的問題也許不會立即使你的程序崩潰，那樣后果更加嚴重?。?/p>

沒有調用子類的析構函數(shù)
之前的博客講過，父類的析構函數(shù)最好聲明為虛??！

ParentClass *pObj = new ChildClass;...delete pObj;

上述代碼會造成崩潰，如果父類的析構函數(shù)不聲明為虛，那么不會調用繼承類的析構函數(shù)，造成內存泄露。

內存溢出

當我們拷貝字符串的時候，我們常常會用到 memcpy函數(shù)。這里特別需要注意的就是字符串結尾的null字符：

char *p = (char *)malloc(strlen(str));strcpy(p, str);

為了躲過這個坑，只需要把 strlen(str) 改為 strlen(str)+1。

記一次指針使用不當造成的內存泄露

剛寫完一段代碼，由于將很運行在移動設備上， 我決定先測試一下內存的使用量， 結果發(fā)現(xiàn)了很嚴重的內存泄漏， 在前前后后翻看了new 和delete并確認沒有漏寫的情況下， 泄露依然存在！調試后最終確認了問題是因為union的不當使用造成的， 下面開始還原現(xiàn)場：

typedef struct DATA_{ DATA_(int size = 10) { pVoid = new char[nSize];this->size = size; }virtual ~DATA_() {if (pVoid) {delete pVoid; } }int nSize;void *pVoid;}DATA, *LPDATA;
struct STRUCT1{ STRUCT1(int count) { pVoid = new DATA[count];this->count = count; }virtual ~STRUCT1() {if (pVoid) {delete pVoid; } }int count;union {void *pVoid; LPDATA pData; }}
int main(int argc, char* argv[]){for( int i = 0; i < 1000; i++) {void *p = new STRUCT1( 10 );delete p; }return 0;}

在上面這段代碼中，STRUCT1中包含了若干個DATA結構，DATA結構又申請了默認為10byte大小的內存，并且內存在對象析構的時候會用delete回收。乍一看這個代碼貌似不會泄露內存，其實不然，待我分析：

在C++中構造函數(shù)與析構函數(shù)的調用是由編譯器完成的，其中構造函數(shù)的調用一般是在對象空間開辟完以后（棧對象或者堆對象都是一樣的），將參數(shù)壓棧，this指針（對象的起始地址）放入eax寄存器（不同的編譯器做法可能不同），然后跳到構造函數(shù)去執(zhí)行。而析構函數(shù)的調用則是當對象內存被回收的時候被調用（棧對象是當代碼執(zhí)行到變量可見域外之前調用， 堆對象是在delete語句的位置進行調用）。

然而編譯器并是那么智能的可以理解coder的意圖，析構函數(shù)的調用是根據(jù)當前delete的指針類型來確定的，而（下面）這段代碼卻沒有提供類型， 這導致了DATA_的析構函數(shù)將不會被調用，內存泄漏就在所難免了。

virtual ~STRUCT1() {if (pVoid)  {delete pVoid;//問題在這, 應該使用delete pData; } }

本文討論了幾種在使用動態(tài)內存分配時應該避免的陷阱。要避免內存相關的問題，良好的習慣是：

1.  始終結合使用 memset 和 malloc分配內存，或始終使用 calloc。
2.  每當向指針寫入值時，都要確保對可用字節(jié)數(shù)和所寫入的字節(jié)數(shù)進行交叉核對。
3.  在對指針賦值前，要確保沒有內存位置會變?yōu)楣铝⒌摹?br style="box-sizing: border-box;">4.  每當釋放結構化的元素（而該元素又包含指向動態(tài)分配的內存位置的指針）時，都應首先遍歷子內存位置并從那里開始釋放，然后再遍歷回父節(jié)點。

5. 始終正確處理返回動態(tài)分配的內存引用的函數(shù)返回值。
6. 每個 malloc 都要有一個對應的 free。
7. 確保您不是在訪問空指針。