引言
對於任何使用 C 語言的人，如果問他們 C 語言的最大煩惱是什麼，其中許多人可能會回答說是指標和記憶體洩漏。這些的確是消耗了開發人員大多數除錯時間的事項。指標和記憶體洩漏對某些開發人員來說似乎令人畏懼，但是一旦您瞭解了指標及其關聯記憶體操作的基礎，它們就是您在 C 語言中擁有的最強大工具。
本文將與您分享開發人員在開始使用指標來程式設計前應該知道的祕密。本文內容包括：
- 導致記憶體破壞的指標操作型別
- 在使用動態記憶體分配時必須考慮的檢查點
- 導致記憶體洩漏的場景
如果您預先知道什麼地方可能出錯，那麼您就能夠小心避免陷阱，並消除大多數與指標和記憶體相關的問題。
什麼地方可能出錯？
有幾種問題場景可能會出現，從而可能在完成生成後導致問題。在處理指標時，您可以使用本文中的資訊來避免許多問題。
未初始化的記憶體
在本例中，p 已被分配了 10 個位元組。這 10 個位元組可能包含垃圾資料，如圖 1 所示。
|
1 |
char *p = malloc ( 10 ); |
圖 1. 垃圾資料
如果在對這個 p 賦值前，某個程式碼段嘗試訪問它，則可能會獲得垃圾值，您的程式可能具有不可預測的行為。p 可能具有您的程式從未曾預料到的值。
良好的實踐是始終結合使用 memset 和 malloc，或者使用 calloc。
|
1 2 |
char *p = malloc (10); memset(p,’’,10); |
現在，即使同一個程式碼段嘗試在對 p 賦值前訪問它，該程式碼段也能正確處理 Null 值（在理想情況下應具有的值），然後將具有正確的行為。
記憶體覆蓋
由於 p 已被分配了 10 個位元組，如果某個程式碼片段嘗試向 p 寫入一個 11 位元組的值，則該操作將在不告訴您的情況下自動從其他某個位置“吃掉”一個位元組。讓我們假設指標 q 表示該記憶體。
圖 2. 原始 q 內容
圖 3. 覆蓋後的 q 內容
結果，指標 q 將具有從未預料到的內容。即使您的模組編碼得足夠好，也可能由於某個共存模組執行某些記憶體操作而具有不正確的行為。下面的示例程式碼片段也可以說明這種場景。
|
1 2 3 |
char *name = (char *) malloc(11); // Assign some value to name memcpy ( p,name,11); // Problem begins here |
在本例中，memcpy 操作嘗試將 11 個位元組寫到 p，而後者僅被分配了 10 個位元組。
作為良好的實踐，每當向指標寫入值時，都要確保對可用位元組數和所寫入的位元組數進行交叉核對。一般情況下，memcpy 函式將是用於此目的的檢查點。
記憶體讀取越界
記憶體讀取越界 (overread) 是指所讀取的位元組數多於它們應有的位元組數。這個問題並不太嚴重，在此就不再詳述了。下面的程式碼提供了一個示例。
|
1 2 3 |
char *ptr = (char *)malloc(10); char name[20] ; memcpy ( name,ptr,20); // Problem begins here |
在本例中，memcpy 操作嘗試從 ptr 讀取 20 個位元組，但是後者僅被分配了 10 個位元組。這還會導致不希望的輸出。
記憶體洩漏
記憶體洩漏可能真正令人討厭。下面的列表描述了一些導致記憶體洩漏的場景。
- 重新賦值我將使用一個示例來說明重新賦值問題。
|
1 2 |
char *memoryArea = malloc(10); char *newArea = malloc(10); |
這向如下面的圖 4 所示的記憶體位置賦值。
圖 4. 記憶體位置
memoryArea 和 newArea 分別被分配了 10 個位元組，它們各自的內容如圖 4 所示。如果某人執行如下所示的語句（指標重新賦值）……
|
1 |
memoryArea = newArea; |
則它肯定會在該模組開發的後續階段給您帶來麻煩。
在上面的程式碼語句中，開發人員將 memoryArea 指標賦值給 newArea 指標。結果，memoryArea 以前所指向的記憶體位置變成了孤立的，如下面的圖 5 所示。它無法釋放，因為沒有指向該位置的引用。這會導致 10 個位元組的記憶體洩漏。
圖 5. 記憶體洩漏
- 在對指標賦值前，請確保記憶體位置不會變為孤立的。
- 首先釋放父塊假設有一個指標
memoryArea，它指向一個 10 位元組的記憶體位置。該記憶體位置的第三個位元組又指向某個動態分配的 10 位元組的記憶體位置，如圖 6所示。
圖 6. 動態分配的記憶體
|
1 |
free(memoryArea) |
如果通過呼叫 free 來釋放了 memoryArea，則 newArea 指標也會因此而變得無效。newArea 以前所指向的記憶體位置無法釋放，因為已經沒有指向該位置的指標。換句話說，newArea 所指向的記憶體位置變為了孤立的，從而導致了記憶體洩漏。
每當釋放結構化的元素，而該元素又包含指向動態分配的記憶體位置的指標時，應首先遍歷子記憶體位置（在此例中為 newArea），並從那裡開始釋放，然後再遍歷回父節點。
這裡的正確實現應該為：
|
1 2 |
free( memoryArea->newArea); free(memoryArea); |
返回值的不正確處理
有時，某些函式會返回對動態分配的記憶體的引用。跟蹤該記憶體位置並正確地處理它就成為了 calling 函式的職責。
|
1 2 3 4 5 6 7 8 9 |
char *func ( ) { return malloc(20); // make sure to memset this location to ‘’… } void callingFunc ( ) { func ( ); // Problem lies here } |
在上面的示例中，callingFunc() 函式中對 func() 函式的呼叫未處理該記憶體位置的返回地址。結果，func() 函式所分配的 20 個位元組的塊就丟失了，並導致了記憶體洩漏。
歸還您所獲得的
在開發元件時，可能存在大量的動態記憶體分配。您可能會忘了跟蹤所有指標（指向這些記憶體位置），並且某些記憶體段沒有釋放，還保持分配給該程式。
始終要跟蹤所有記憶體分配，並在任何適當的時候釋放它們。事實上，可以開發某種機制來跟蹤這些分配，比如在連結串列節點本身中保留一個計數器（但您還必須考慮該機制的額外開銷）。
訪問空指標
訪問空指標是非常危險的，因為它可能使您的程式崩潰。始終要確保您不是 在訪問空指標。
總結
本文討論了幾種在使用動態記憶體分配時可以避免的陷阱。要避免記憶體相關的問題，良好的實踐是：
- 始終結合使用
memset和 malloc，或始終使用calloc。 - 每當向指標寫入值時，都要確保對可用位元組數和所寫入的位元組數進行交叉核對。
- 在對指標賦值前，要確保沒有記憶體位置會變為孤立的。
- 每當釋放結構化的元素（而該元素又包含指向動態分配的記憶體位置的指標）時，都應首先遍歷子記憶體位置並從那裡開始釋放，然後再遍歷回父節點。
- 始終正確處理返回動態分配的記憶體引用的函式返回值。
- 每個
malloc都要有一個對應的 free。 - 確保您不是在訪問空指標。