對於任何使用C語言的人,如果問他們C語言的最大煩惱是什麼,其中許多人可能會回答說是指針和內存洩漏。這些的確是消耗了開發人員大多數調試時間的事項。指針和內存洩漏對某些開發人員來說似乎令人畏懼,但是一旦您了解了指針及其關聯內存操作的基礎,它們就是您在 C 語言中擁有的最強大工具。
本文將與您分享開發人員在開始使用指針來編程前應該知道的秘密。本文內容包括:
如果您預先知道什麼地方可能出錯,那麼您就能夠小心避免陷阱,並消除大多數與指針和內存相關的問題。
本文地址:http://www.cnblogs.com/archimedes/p/c-point-memory-leak.html,轉載請注明源地址。
有幾種問題場景可能會出現,從而可能在完成生成後導致問題。在處理指針時,您可以使用本文中的信息來避免許多問題。
常見的內存錯誤及其對策如下:
1、內存分配未成功,卻使用了它
編程新手常犯這種錯誤,因為他們沒有意識到內存分配會不成功。常用解決辦法是,在使用內存之前檢查指針是否為NULL。如果指針p是函數的參數,那麼在函數
的入口處用assert(p!=NULL)進行檢查。如果是用malloc或new來申請內存,應該用if(p==NULL) 或if(p!=NULL)進行防錯處理。
2、內存分配雖然成功,但是尚未初始化就引用它
犯這種錯誤主要有兩個起因:一是沒有初始化的觀念;二是誤以為內存的缺省初值全為零,導致引用初值錯誤(例如數組)。
內存的缺省初值究竟是什麼並沒有統一的標准,盡管有些時候為零值,我們寧可信其無不可信其有。所以無論用何種方式創建數組,都別忘了賦初值,即便是賦零
值也不可省略,不要嫌麻煩。
3、內存分配成功並且已經初始化,但操作越過了內存的邊界
例如在使用數組時經常發生下標“多1”或者“少1”的操作。特別是在for循環語句中,循環次數很容易搞錯,導致數組操作越界。
4、忘記了釋放內存,造成內存洩露
含有這種錯誤的函數每被調用一次就丟失一塊內存。剛開始時系統的內存充足,你看不到錯誤。終有一次程序突然死掉,系統出現提示:內存耗盡。
在本例中,p
已被分配了 10 個字節。這 10 個字節可能包含垃圾數據,如圖 1 所示。
char *p = malloc ( 10 );
圖 1. 垃圾數據
如果在對這個 p
賦值前,某個代碼段嘗試訪問它,則可能會獲得垃圾值,您的程序可能具有不可預測的行為。p
可能具有您的程序從未曾預料到的值。
良好的實踐是始終結合使用 memset
和 malloc
,或者使用 calloc
。
char *p = malloc (10); memset(p,’\0’,10);
現在,即使同一個代碼段嘗試在對 p
賦值前訪問它,該代碼段也能正確處理 Null
值(在理想情況下應具有的值),然後將具有正確的行為。
由於 p
已被分配了 10 個字節,如果某個代碼片段嘗試向 p
寫入一個 11 字節的值,則該操作將在不告訴您的情況下自動從其他某個位置“吃掉”一個字節。讓我們假設指針 q
表示該內存。
結果,指針 q
將具有從未預料到的內容。即使您的模塊編碼得足夠好,也可能由於某個共存模塊執行某些內存操作而具有不正確的行為。下面的示例代碼片段也可以說明這種場景。
char *name = (char *) malloc(11); // Assign some value to name memcpy ( p,name,11); // Problem begins here
在本例中,memcpy
操作嘗試將 11 個字節寫到 p
,而後者僅被分配了 10 個字節。
作為良好的實踐,每當向指針寫入值時,都要確保對可用字節數和所寫入的字節數進行交叉核對。一般情況下,memcpy
函數將是用於此目的的檢查點。
內存讀取越界 (overread) 是指所讀取的字節數多於它們應有的字節數。這個問題並不太嚴重,在此就不再詳述了。下面的代碼提供了一個示例。
char *ptr = (char *)malloc(10); char name[20] ; memcpy ( name,ptr,20); // Problem begins here
在本例中,memcpy
操作嘗試從 ptr
讀取 20 個字節,但是後者僅被分配了 10 個字節。這還會導致不希望的輸出。
內存洩漏可能真正令人討厭。下面的列表描述了一些導致內存洩漏的場景。
我將使用一個示例來說明重新賦值問題。
char *memoryArea = malloc(10); char *newArea = malloc(10);
這向如下面的圖 4 所示的內存位置賦值。
memoryArea
和 newArea
分別被分配了 10 個字節,它們各自的內容如圖 4 所示。如果某人執行如下所示的語句(指針重新賦值)……
memoryArea = newArea;
則它肯定會在該模塊開發的後續階段給您帶來麻煩。
在上面的代碼語句中,開發人員將 memoryArea
指針賦值給 newArea
指針。結果,memoryArea
以前所指向的內存位置變成了孤立的,如下面的圖 5 所示。它無法釋放,因為沒有指向該位置的引用。這會導致 10 個字節的內存洩漏。
圖 5. 內存洩漏
在對指針賦值前,請確保內存位置不會變為孤立的。
假設有一個指針 memoryArea
,它指向一個 10 字節的內存位置。該內存位置的第三個字節又指向某個動態分配的 10 字節的內存位置,如圖 6所示。
如果通過調用 free 來釋放了 memoryArea
,則 newArea
指針也會因此而變得無效。newArea
以前所指向的內存位置無法釋放,因為已經沒有指向該位置的指針。換句話說,newArea
所指向的內存位置變為了孤立的,從而導致了內存洩漏。
每當釋放結構化的元素,而該元素又包含指向動態分配的內存位置的指針時,應首先遍歷子內存位置(在此例中為 newArea
),並從那裡開始釋放,然後再遍歷回父節點。
這裡的正確實現應該為:
free( memoryArea->newArea); free(memoryArea);
有時,某些函數會返回對動態分配的內存的引用。跟蹤該內存位置並正確地處理它就成為了 calling
函數的職責。
char *func( ) { return malloc(20); // make sure to memset this location to ‘\0’… } void callingFunc( ) { func ( ); // Problem lies here }
在上面的示例中,callingFunc()
函數中對 func()
函數的調用未處理該內存位置的返回地址。結果,func()
函數所分配的 20 個字節的塊就丟失了,並導致了內存洩漏。
在開發組件時,可能存在大量的動態內存分配。您可能會忘了跟蹤所有指針(指向這些內存位置),並且某些內存段沒有釋放,還保持分配給該程序。
始終要跟蹤所有內存分配,並在任何適當的時候釋放它們。事實上,可以開發某種機制來跟蹤這些分配,比如在鏈表節點本身中保留一個計數器(但您還必須考慮該機制的額外開銷)。
訪問空指針是非常危險的,因為它可能使您的程序崩潰。始終要確保您不是 在訪問空指針。
本文討論了幾種在使用動態內存分配時可以避免的陷阱。要避免內存相關的問題,良好的實踐是:
memset
和 malloc,或始終使用 calloc
。malloc
都要有一個對應的 free。