當前位置:首頁 > 公眾號精選 > 21ic電子網(wǎng)
[導(dǎo)讀]引言 對于任何使用 C 語言的人,如果問他們 C 語言的最大煩惱是什么,其中許多人可能會回答說是指針和內(nèi)存泄漏。這些的確是消耗了開發(fā)人員大多數(shù)調(diào)試時間的事項。指針和內(nèi)存泄漏對某些開發(fā)人員來說似乎令人畏懼,但是一旦您了解了指針及其關(guān)聯(lián)內(nèi)存操作的基礎(chǔ)

引言

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


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

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


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


啥是內(nèi)存泄漏

內(nèi)存泄露在維基百科中的解釋如下:

在計算機科學(xué)中,內(nèi)存泄漏指由于疏忽或錯誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存。內(nèi)存泄漏并非指內(nèi)存在物理上的消失,而是應(yīng)用程序分配某段內(nèi)存后,由于設(shè)計錯誤,導(dǎo)致在釋放該段內(nèi)存之前就失去了對該段內(nèi)存的控制,從而造成了內(nèi)存的浪費。

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

知道了出現(xiàn)內(nèi)存泄露的原因就能知道如何應(yīng)對內(nèi)存泄露,即:不用了的內(nèi)存空間記得釋放,不釋放留著過年哇!

內(nèi)存泄漏可能會導(dǎo)致嚴重的后果:
●  程序運行后,隨著時間占用了更多的內(nèi)存,最后無內(nèi)存可用而崩潰;
●  程序消耗了大量的內(nèi)存,導(dǎo)致其他程序無法正常使用;
●  程序消耗了大量內(nèi)存,導(dǎo)致消費者選用了別人的程序而不是你的;
●  經(jīng)常做出內(nèi)存泄露bug的程序猿被公司開出而貧困潦倒。

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


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

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

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

對于函數(shù)中申請的臨時空間,認真檢查,是否存在提前跳出函數(shù)的地方?jīng)]有釋放內(nèi)存。


什么地方可能出錯?

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


未初始化的內(nèi)存

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

解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開

char *p = malloc ( 10 );

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


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

良好的習(xí)慣是始終結(jié)合使用 memset 和 malloc分配內(nèi)存,或者使用 calloc。

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


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


內(nèi)存覆蓋

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


解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開

圖 2. 原始 q 內(nèi)容

解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開

圖 3. 覆蓋后的 q 內(nèi)容


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

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ù)將是用于此目的的檢查點。


內(nèi)存讀取越界

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

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


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


內(nèi)存泄漏

內(nèi)存泄漏可能真正令人討厭。下面的列表描述了一些導(dǎo)致內(nèi)存泄漏的場景。


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

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

這向如下面的圖 4 所示的內(nèi)存位置賦值。

解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開

圖 4. 內(nèi)存位置


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

memoryArea = newArea;


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


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

解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開

圖 5. 內(nèi)存泄漏


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


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

解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開

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


free(memoryArea)

如果通過調(diào)用 free 來釋放了 memoryArea,則 newArea 指針也會因此而變得無效。newArea 以前所指向的內(nèi)存位置無法釋放,因為已經(jīng)沒有指向該位置的指針。換句話說,newArea 所指向的內(nèi)存位置變?yōu)榱斯铝⒌模瑥亩鴮?dǎo)致了內(nèi)存泄漏。


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


這里的正確實現(xiàn)應(yīng)該為:

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


返回值的不正確處理
有時,某些函數(shù)會返回對動態(tài)分配的內(nèi)存的引用。跟蹤該內(nè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ù)的調(diào)用未處理該內(nèi)存位置的返回地址。結(jié)果,func() 函數(shù)所分配的 20 個字節(jié)的塊就丟失了,并導(dǎo)致了內(nèi)存泄漏。


歸還您所獲得的

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

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


訪問空指針

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


沒有躲過的坑--指針(內(nèi)存泄露)


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


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


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

試圖用一個null指針調(diào)用類的成員函數(shù),導(dǎo)致崩潰:

#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;}


為什么會這樣? 

通過非法指針調(diào)用函數(shù),就相當于給函數(shù)傳遞了一個指向函數(shù)的非法指針! 


但是為什么pA2->dumb()會成功呢? 
因為導(dǎo)致崩潰的是訪問了成員變量?。?/p>

使用已經(jīng)釋放的指針

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);}

結(jié)果是一樣的??!

釋放已經(jīng)釋放的指針


直接看看代碼:

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


這樣的問題也許不會立即使你的程序崩潰,那樣后果更加嚴重??!

沒有調(diào)用子類的析構(gòu)函數(shù)
之前的博客講過,父類的析構(gòu)函數(shù)最好聲明為虛??!

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


上述代碼會造成崩潰,如果父類的析構(gòu)函數(shù)不聲明為虛,那么不會調(diào)用繼承類的析構(gòu)函數(shù),造成內(nèi)存泄露。


內(nèi)存溢出

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

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

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


記一次指針使用不當造成的內(nèi)存泄露


剛寫完一段代碼,由于將很運行在移動設(shè)備上, 我決定先測試一下內(nèi)存的使用量, 結(jié)果發(fā)現(xiàn)了很嚴重的內(nèi)存泄漏, 在前前后后翻看了new 和delete并確認沒有漏寫的情況下, 泄露依然存在!調(diào)試后最終確認了問題是因為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結(jié)構(gòu),DATA結(jié)構(gòu)又申請了默認為10byte大小的內(nèi)存,并且內(nèi)存在對象析構(gòu)的時候會用delete回收。乍一看這個代碼貌似不會泄露內(nèi)存,其實不然,待我分析:


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


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

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


總結(jié)

本文討論了幾種在使用動態(tài)內(nèi)存分配時應(yīng)該避免的陷阱。要避免內(nèi)存相關(guān)的問題,良好的習(xí)慣是:

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

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




免責聲明:本文系網(wǎng)絡(luò)轉(zhuǎn)載,版權(quán)歸原作者所有。如有問題,請聯(lián)系我們,謝謝!


推薦閱讀

解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開

你和大牛工程師之間到底差了啥?
加入技術(shù)交流群,與高手面對面 
添加管理員微信
解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開
加入“中國電子網(wǎng)微信群”交流

解密C語言中的指針和內(nèi)存泄漏,這些陷阱要避開
具體加群詳情請戳

免責聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

21ic電子網(wǎng)

掃描二維碼,關(guān)注更多精彩內(nèi)容

本站聲明: 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉