本文將帶您了解一些良好的和內(nèi)存相關(guān)的編碼實踐，以將內(nèi)存錯誤保持在控制范圍內(nèi)。內(nèi)存錯誤是 C 和 C++ 編程的禍根：它們很普遍，認識其嚴重性已有二十多年，但始終沒有徹底解決，它們可能嚴重影響應(yīng)用程序，并且很少有開發(fā)團隊對其制定明確的管理計劃。但好消息是，它們并不怎么神秘。

引言

C 和 C++ 程序中的內(nèi)存錯誤非常有害：它們很常見，并且可能導(dǎo)致嚴重的后果。來自計算機應(yīng)急響應(yīng)小組（請參見參考資料）和供應(yīng)商的許多最嚴重的安全公告都是由簡單的內(nèi)存錯誤造成的。自從 70 年代末期以來，C 程序員就一直討論此類錯誤，但其影響在 2007 年仍然很大。更糟的是，如果按我的思路考慮，當今的許多 C 和 C++ 程序員可能都會認為內(nèi)存錯誤是不可控制而又神秘的頑癥，它們只能糾正，無法預(yù)防。

但事實并非如此。本文將讓您在短時間內(nèi)理解與良好內(nèi)存相關(guān)的編碼的所有本質(zhì)：

• 正確的內(nèi)存管理的重要性
• 內(nèi)存錯誤的類別
• 內(nèi)存編程的策略
• 結(jié)束語

正確的內(nèi)存管理的重要性

存在內(nèi)存錯誤的 C 和 C++ 程序會導(dǎo)致各種問題。如果它們泄漏內(nèi)存，則運行速度會逐漸變慢，并最終停止運行；如果覆蓋內(nèi)存，則會變得非常脆弱，很容易受到惡意用戶的攻擊。從 1988 年著名的莫里斯蠕蟲 攻擊到有關(guān) Flash Player 和其他關(guān)鍵的零售級程序的最新安全警報都與緩沖區(qū)溢出有關(guān)：“大多數(shù)計算機安全漏洞都是緩沖區(qū)溢出”，Rodney Bates 在 2004 年寫道。

在可以使用 C 或 C++ 的地方，也廣泛支持使用其他許多通用語言（如 Java、Ruby、Haskell、C#、Perl、Smalltalk 等），每種語言都有眾多的愛好者和各自的優(yōu)點。但是，從計算角度來看，每種編程語言優(yōu)于 C 或 C++ 的主要優(yōu)點都與便于內(nèi)存管理密切相關(guān)。與內(nèi)存相關(guān)的編程是如此重要，而在實踐中正確應(yīng)用又是如此困難，以致于它支配著面向?qū)ο缶幊陶Z言、功能性編程語言、高級編程語言、聲明性編程語言和另外一些編程語言的所有其他變量或理論。

與少數(shù)其他類型的常見錯誤一樣，內(nèi)存錯誤還是一種隱性危害：它們很難再現(xiàn)，癥狀通常不能在相應(yīng)的源代碼中找到。例如，無論何時何地發(fā)生內(nèi)存泄漏，都可能表現(xiàn)為應(yīng)用程序完全無法接受，同時內(nèi)存泄漏不是顯而易見。

因此，出于所有這些原因，需要特別關(guān)注 C 和 C++ 編程的內(nèi)存問題。讓我們看一看如何解決這些問題，先不談是哪種語言。

內(nèi)存錯誤的類別

首先，不要失去信心。有很多辦法可以對付內(nèi)存問題。我們先列出所有可能存在的實際問題：

• 內(nèi)存泄漏
• 錯誤分配，包括大量增加 free() 釋放的內(nèi)存和未初始化的引用
• 懸空指針
• 數(shù)組邊界違規(guī)

這是所有類型。即使遷移到 C++ 面向?qū)ο蟮恼Z言，這些類型也不會有明顯變化；無論數(shù)據(jù)是簡單類型還是 C 語言的 struct 或 C++ 的類，C 和 C++ 中內(nèi)存管理和引用的模型在原理上都是相同的。以下內(nèi)容絕大部分是“純 C”語言，對于擴展到 C++ 主要留作練習(xí)使用。

內(nèi)存泄漏

在分配資源時會發(fā)生內(nèi)存泄漏，但是它從不回收。下面是一個可能出錯的模型（請參見清單 1）：

清單 1. 簡單的潛在堆內(nèi)存丟失和緩沖區(qū)覆蓋

void f1(char *explanation) { char p1; p1 = malloc(100); (void) sprintf(p1, "The f1 error occurred because of '%s'.", explanation); local_log(p1); }

您看到問題了嗎？除非 local_log() 對 free() 釋放的內(nèi)存具有不尋常的響應(yīng)能力，否則每次對f1 的調(diào)用都會泄漏 100 字節(jié)。在記憶棒增量分發(fā)數(shù)兆字節(jié)內(nèi)存時，一次泄漏是微不足道的，但是連續(xù)操作數(shù)小時后，即使如此小的泄漏也會削弱應(yīng)用程序。

在實際的 C 和 C++ 編程中，這不足以影響您對 malloc() 或 new 的使用，本部分開頭的句子提到了“資源”不是僅指“內(nèi)存”，因為還有類似以下內(nèi)容的示例（請參見清單 2）。FILE 句柄可能與內(nèi)存塊不同，但是必須對它們給予同等關(guān)注：

清單 2. 來自資源錯誤管理的潛在堆內(nèi)存丟失

int getkey(char *filename) { FILE *fp; int key; fp = fopen(filename, "r"); fscanf(fp, "%d", &key); return key; }

fopen 的語義需要補充性的 fclose。在沒有 fclose() 的情況下，C 標準不能指定發(fā)生的情況時，很可能是內(nèi)存泄漏。其他資源（如信號量、網(wǎng)絡(luò)句柄、數(shù)據(jù)庫連接等）同樣值得考慮。

內(nèi)存錯誤分配

錯誤分配的管理不是很困難。下面是一個示例（請參見清單 3）：

清單 3. 未初始化的指針

void f2(int datum) { int *p2; /* Uh-oh! No one has initialized p2. */ *p2 = datum; ... }

關(guān)于此類錯誤的好消息是，它們一般具有顯著結(jié)果。在 AIX? 下，對未初始化指針的分配通常會立即導(dǎo)致 segmentation fault 錯誤。它的好處是任何此類錯誤都會被快速地檢測到；與花費數(shù)月時間才能確定且難以再現(xiàn)的錯誤相比，檢測此類錯誤的代價要小得多。

在此錯誤類型中存在多個變種。free() 釋放的內(nèi)存比 malloc() 更頻繁（請參見清單 4）：

清單 4. 兩個錯誤的內(nèi)存釋放

/* Allocate once, free twice. */ void f3() { char *p; p = malloc(10); ... free(p); ... free(p); } /* Allocate zero times, free once. */ void f4() { char *p; /* Note that p remains uninitialized here. */ free(p); }

這些錯誤通常也不太嚴重。盡管 C 標準在這些情形中沒有定義具體行為，但典型的實現(xiàn)將忽略錯誤，或者快速而明確地對它們進行標記；總之，這些都是安全情形。

懸空指針

懸空指針比較棘手。當程序員在內(nèi)存資源釋放后使用資源時會發(fā)生懸空指針（請參見清單 5）：

清單 5. 懸空指針

void f8() { struct x *xp; xp = (struct x *) malloc(sizeof (struct x)); xp.q = 13; ... free(xp); ... /* Problem! There's no guarantee that the memory block to which xp points hasn't been overwritten. */ return xp.q; }

傳統(tǒng)的“調(diào)試”難以隔離懸空指針。由于下面兩個明顯原因，它們很難再現(xiàn)：

• 即使影響提前釋放內(nèi)存范圍的代碼已本地化，內(nèi)存的使用仍然可能取決于應(yīng)用程序甚至（在極端情況下）不同進程中的其他執(zhí)行位置。
• 懸空指針可能發(fā)生在以微妙方式使用內(nèi)存的代碼中。結(jié)果是，即使內(nèi)存在釋放后立即被覆蓋，并且新指向的值不同于預(yù)期值，也很難識別出新值是錯誤值。

懸空指針不斷威脅著 C 或 C++ 程序的運行狀態(tài)。

數(shù)組邊界違規(guī)

數(shù)組邊界違規(guī)十分危險，它是內(nèi)存錯誤管理的最后一個主要類別。回頭看一下清單 1；如果explanation 的長度超過 80，則會發(fā)生什么情況？回答：難以預(yù)料，但是它可能與良好情形相差甚遠。特別是，C 復(fù)制一個字符串，該字符串不適于為它分配的 100 個字符。在任何常規(guī)實現(xiàn)中，“超過的”字符會覆蓋內(nèi)存中的其他數(shù)據(jù)。內(nèi)存中數(shù)據(jù)分配的布局非常復(fù)雜并且難以再現(xiàn)，所以任何癥狀都不可能追溯到源代碼級別的具體錯誤。這些錯誤通常會導(dǎo)致數(shù)百萬美元的損失。

內(nèi)存編程的策略

勤奮和自律可以讓這些錯誤造成的影響降至最低限度。下面我們介紹一下您可以采用的幾個特定步驟；我在各種組織中處理它們的經(jīng)驗是，至少可以按一定的數(shù)量級持續(xù)減少內(nèi)存錯誤。

編碼風(fēng)格

編碼風(fēng)格是最重要的，我還從沒有看到過其他任何作者對此加以強調(diào)。影響資源（特別是內(nèi)存）的函數(shù)和方法需要顯式地解釋本身。下面是有關(guān)標頭、注釋或名稱的一些示例（請參見清單 6）。

清單 6. 識別資源的源代碼示例

/******** * ... * * Note that any function invoking protected_file_read() * assumes responsibility eventually to fclose() its * return value, UNLESS that value is NULL. * ********/ FILE *protected_file_read(char *filename) { FILE *fp; fp = fopen(filename, "r"); if (fp) { ... } else { ... } return fp; } /******* * ... * * Note that the return value of get_message points to a * fixed memory location. Do NOT free() it; remember to * make a copy if it must be retained ... * ********/ char *get_message() { static char this_buffer[400]; ... (void) sprintf(this_buffer, ...); return this_buffer; } /******** * ... * While this function uses heap memory, and so * temporarily might expand the over-all memory * footprint, it properly cleans up after itself. * ********/ int f6(char *item1) { my_class c1; int result; ... c1 = new my_class(item1); ... result = c1.x; delete c1; return result; } /******** * ... * Note that f8() is documented to return a value * which needs to be returned to heap; as f7 thinly * wraps f8, any code which invokes f7() must be * careful to free() the return value. * ********/ int *f7() { int *p; p = f8(...); ... return p; }

使這些格式元素成為您日常工作的一部分。可以使用各種方法解決內(nèi)存問題：

• 專用庫
• 語言
• 軟件工具
• 硬件檢查器

在這整個領(lǐng)域中，我始終認為最有用并且投資回報率最大的是考慮改進源代碼的風(fēng)格。它不需要昂貴的代價或嚴格的形式；可以始終取消與內(nèi)存無關(guān)的段的注釋，但影響內(nèi)存的定義當然需要顯式注釋。添加幾個簡單的單詞可使內(nèi)存結(jié)果更清楚，并且內(nèi)存編程會得到改進。

我沒有做受控實驗來驗證此風(fēng)格的效果。如果您的經(jīng)歷與我一樣，您將發(fā)現(xiàn)沒有說明資源影響的策略簡直無法忍受。這樣做很簡單，但帶來的好處太多了。

檢測

檢測是編碼標準的補充。二者各有裨益，但結(jié)合使用效果特別好。機靈的 C 或 C++ 專業(yè)人員甚至可以瀏覽不熟悉的源代碼，并以極低的成本檢測內(nèi)存問題。通過少量的實踐和適當?shù)奈谋舅阉?#xff0c;您能夠快速驗證平衡的*alloc() 和free() 或者 new 和 delete 的源主體。人工查看此類內(nèi)容通常會出現(xiàn)像清單 7中一樣的問題。

清單 7. 棘手的內(nèi)存泄漏

static char *important_pointer = NULL; void f9() { if (!important_pointer) important_pointer = malloc(IMPORTANT_SIZE); ... if (condition) /* Ooops! We just lost the reference important_pointer already held. */ important_pointer = malloc(DIFFERENT_SIZE); ... }

如果 condition 為真，簡單使用自動運行時工具不能檢測發(fā)生的內(nèi)存泄漏。仔細進行源分析可以從此類條件推理出證實正確的結(jié)論。我重復(fù)一下我寫的關(guān)于風(fēng)格的內(nèi)容：盡管大量發(fā)布的內(nèi)存問題描述都強調(diào)工具和語言，對于我來說，最大的收獲來自“軟的”以開發(fā)人員為中心的流程變更。您在風(fēng)格和檢測上所做的任何改進都可以幫助您理解由自動化工具產(chǎn)生的診斷。

靜態(tài)的自動語法分析

當然，并不是只有人類才能讀取源代碼。您還應(yīng)使靜態(tài)語法分析 成為開發(fā)流程的一部分。靜態(tài)語法分析是 lint、嚴格編譯 和幾種商業(yè)產(chǎn)品執(zhí)行的內(nèi)容：掃描編譯器接受的源文本和目標項，但這可能是錯誤的癥狀。

希望讓您的代碼無 lint。盡管 lint 已過時，并有一定的局限性，但是，沒有使用它（或其較高級的后代）的許多程序員犯了很大的錯誤。通常情況下，您能夠編寫忽略lint 的優(yōu)秀的專業(yè)質(zhì)量代碼，但努力這樣做的結(jié)果通常會發(fā)生重大錯誤。其中一些錯誤影響內(nèi)存的正確性。與讓客戶首先發(fā)現(xiàn)內(nèi)存錯誤的代價相比，即使對這種類別的產(chǎn)品支付最昂貴的許可費也失去了意義。清除源代碼。現(xiàn)在，即使lint 標記的編碼可能向您提供所需的功能，但很可能存在更簡單的方法，該方法可滿足lint，并且比較強鍵又可移植。

內(nèi)存庫

補救方法的最后兩個類別與前三個明顯不同。前者是輕量級 的；一個人可以容易地理解并實現(xiàn)它們。另一方面，內(nèi)存庫和工具通常具有較高的許可費用，對部分開發(fā)人員來說，它們需要進一步完善和調(diào)整。有效地使用庫和工具的程序員是理解輕量級的靜態(tài) 方法的人員。可用的庫和工具給人的印象很深：其作為組的質(zhì)量很高。但是，即使最優(yōu)秀的編程人員也可能會被忽略內(nèi)存管理基本原則的非常任性的編程人員攪亂。據(jù)我觀察，普通的編程人員在嘗試利用內(nèi)存庫和工具進行隔離工作時也只能感到灰心。

由于這些原因，我們催促 C 和 C++ 程序員為解決內(nèi)存問題先了解一下自己的源。在這完成之后，才去考慮庫。

使用幾個庫能夠編寫常規(guī)的 C 或 C++ 代碼，并保證改進內(nèi)存管理。Jonathan Bartlett 在 developerWorks 的 2004 評論專欄中介紹了主要的候選項，可以在下面的參考資料部分獲得。庫可以解決多種不同的內(nèi)存問題，以致于直接對它們進行比較是非常困難的；這方面的常見主題包括垃圾收集、智能指針 和 智能容器。大體上說，庫可以自動進行較多的內(nèi)存管理，這樣程序員可以犯更少的錯誤。

我對內(nèi)存庫有各種感受。他們在努力工作，但我看到他們在項目中獲得的成功比預(yù)期要小，尤其在 C 方面。我尚未對這些令人失望的結(jié)果進行仔細分析。例如，業(yè)績應(yīng)該與相應(yīng)的手動 內(nèi)存管理一樣好，但是這是一個灰色區(qū)域——尤其在垃圾收集庫處理速度緩慢的情況下。通過這方面的實踐得出的最明確的結(jié)論是，與 C 關(guān)注的代碼組相比，C++ 似乎可以較好地接受智能指針。

內(nèi)存工具

開發(fā)真正基于 C 的應(yīng)用程序的開發(fā)團隊需要運行時內(nèi)存工具作為其開發(fā)策略的一部分。已介紹的技術(shù)很有價值，而且不可或缺。在您親自嘗試使用內(nèi)存工具之前，其質(zhì)量和功能您可能還不了解。

本文主要討論了基于軟件的內(nèi)存工具。還有硬件內(nèi)存調(diào)試器；在非常特殊的情況下（主要是在使用不支持其他工具的專用主機時）才考慮它們。

市場上的軟件內(nèi)存工具包括專有工具（如 IBM Rational? Purify 和 Electric Fence）和其他開放源代碼工具。其中有許多可以很好地與 AIX 和其他操作系統(tǒng)一起使用。

所有內(nèi)存工具的功能基本相同：構(gòu)建可執(zhí)行文件的特定版本（很像在編譯時通過使用 -g 標記生成的調(diào)試版本）、練習(xí)相關(guān)應(yīng)用程序和研究由工具自動生成的報告。請考慮如清單 8 所示的程序。

清單 8. 示例錯誤

int main() { char p[5]; strcpy(p, "Hello, world."); puts(p); }

此程序可以在許多環(huán)境中“運行”，它編譯、執(zhí)行并將“Hello, world.\n”打印到屏幕。使用內(nèi)存工具運行相同應(yīng)用程序會在第四行產(chǎn)生一個數(shù)組邊界違規(guī)的報告。在了解軟件錯誤（將十四個字符復(fù)制到了只能容納五個字符的空間中）方面，這種方法比在客戶處查找錯誤癥狀的花費小得多。這是內(nèi)存工具的功勞。

結(jié)束語

作為一名成熟的 C 或 C++ 程序員，您認識到內(nèi)存問題值得特別關(guān)注。通過制訂一些計劃和實踐，可以找到控制內(nèi)存錯誤的方法。學(xué)習(xí)內(nèi)存使用的正確模式，快速發(fā)現(xiàn)可能發(fā)生的錯誤，使本文介紹的技術(shù)成為您日常工作的一部分。您可以在開始時就消除應(yīng)用程序中的癥狀，否則可能要花費數(shù)天或數(shù)周時間來調(diào)試。

?

共享本文…… ? 請 Digg 該故事 發(fā)布到 del.icio.us Slashdot 一下！

參考資料

學(xué)習(xí)

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
• 計算機應(yīng)急響應(yīng)團隊：計算機應(yīng)急響應(yīng)小組是“聯(lián)邦政府資助的研發(fā)中心”，通過該中心以及許多其他活動發(fā)布關(guān)于specific software vulnerabilities的技術(shù)計算機安全警報。
• Why do good programmers follow bad practices?：這是助理教授 Rodney Bates 為ACM Queue 撰寫的一篇關(guān)于 C 編程和緩沖區(qū)溢出的文章。
• "內(nèi)存管理內(nèi)幕"（developerWorks，2004 年 11 月）：概述了對 Linux? 程序員有用的內(nèi)存管理技術(shù)，主要適用于 C 語言，但是也適用于其他語言。
• Rational Purify：學(xué)習(xí)更多關(guān)于此主要專有內(nèi)存工具的內(nèi)容。
• Coverity, Incorporated：此站點提供產(chǎn)品和服務(wù)，而且與 C 和 C++ 的靜態(tài)源代碼分析有關(guān)。
• Memory hygiene in C and C++, Part 2:Commercial tools：這是我在 2004 年撰寫的一篇文章。我還維護personal notes on memory debuggers 的網(wǎng)頁。
• AIX and UNIX：AIX and UNIX developerWorks專區(qū)提供了大量與 AIX 系統(tǒng)管理的所有方面相關(guān)并擴展您的 UNIX 技能的信息。
• New to AIX and UNIX：訪問 New to AIX and UNIX 頁面以了解更多關(guān)于 AIX 和 UNIX 的內(nèi)容。
• AIX 5L? Wiki：AIX 相關(guān)技術(shù)信息的協(xié)作環(huán)境。
• 查看 Cameron Laird 撰寫的其他文章和教程。
  • 整個 developerWorks
• 按主題搜索“AIX and UNIX”庫：
  • 系統(tǒng)管理
  • 應(yīng)用程序開發(fā)
  • 性能
  • 移植
  • 安全性
  • 提示
  • 工具和實用程序
  • Java technology
  • Linux
  • 開放源代碼
• Safari 書店：訪問這個電子參考庫以查找特定的技術(shù)資源。
• developerWorks 技術(shù)事件和網(wǎng)絡(luò)廣播：了解最新的 developerWorks 技術(shù)事件和網(wǎng)絡(luò)廣播。
• Podcasts：收聽 Podcast 并與 IBM 技術(shù)專家保持同步。

獲得產(chǎn)品和技術(shù)

• IBM 試用軟件：使用 IBM 試用軟件開發(fā)您的下一個項目，可直接從 developerWorks 下載這些試用軟件。

討論

• 參與 developerWorks blogs，從而加入到 developerWorks 社區(qū)中來。
• 參與“AIX and UNIX”論壇：
  • AIX 5L——技術(shù)論壇
  • AIX for Developers 論壇
  • 集群系統(tǒng)管理
  • IBM Support Assistant
  • 性能工具——技術(shù)
  • 虛擬化——技術(shù)
  • 更多“AIX and UNIX”論壇

關(guān)于作者

?

?		Cameron Laird 是 developerWorks 長期投稿者和前專欄作家。他經(jīng)常編寫關(guān)于促進其公司應(yīng)用程序開發(fā)的開源項目的文章，主要關(guān)注可靠性和安全性。

總結(jié)

以上是生活随笔為你收集整理的内存调试技巧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。