引言　　

　　C 和 C++ 程序中的內(nèi)存錯(cuò)誤非常有害：它們很常見，并且可能導(dǎo)致嚴(yán)重的后果。自從 70 年代末期以來，C 程序員就一直討論此類錯(cuò)誤，但其影響在 2007 年仍然很大。更糟的是，如果按我的思路考慮，當(dāng)今的許多 C 和 C++ 程序員可能都會(huì)認(rèn)為內(nèi)存錯(cuò)誤是不可控制而又神秘的頑癥，它們只能糾正，無法預(yù)防。但事實(shí)并非如此。本文將讓您在短時(shí)間內(nèi)理解與良好內(nèi)存相關(guān)的編碼的所有本質(zhì)： 　　　　　　

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

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

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

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

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

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

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

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

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

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

　　內(nèi)存泄漏　　

　　在分配資源時(shí)會(huì)發(fā)生內(nèi)存泄漏，但是它從不回收。下面是一個(gè)可能出錯(cuò)的模型（請(qǐng)參見清單 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() 對(duì) free() 釋放的內(nèi)存具有不尋常的響應(yīng)能力，否則每次對(duì) f1 的調(diào)用都會(huì)泄漏 100 字節(jié)。在記憶棒增量分發(fā)數(shù)兆字節(jié)內(nèi)存時(shí)，一次泄漏是微不足道的，但是連續(xù)操作數(shù)小時(shí)后，即使如此小的泄漏也會(huì)削弱應(yīng)用程序?！　?/p>

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

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

　　                 
 int getkey(char *filename)
 {
      FILE *fp;
      int key;

      fp = fopen(filename, "r");
      fscanf(fp, "%d", &key);
      return key;
         }
   　　

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

　　內(nèi)存錯(cuò)誤分配　　

　　錯(cuò)誤分配的管理不是很困難。下面是一個(gè)示例（請(qǐng)參見　　清單 3　　）：　　

　　
清單 3. 未初始化的指針

　　                 
 void f2(int datum)
 {
      int *p2;

                 /* Uh-oh!   No one has initialized p2. */
             *p2 = datum;
         ...
         }
    　　

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

　　在此錯(cuò)誤類型中存在多個(gè)變種。free() 釋放的內(nèi)存比 malloc() 更頻繁（請(qǐng)參見　　清單 4　?。骸　?/p>

　　
清單 4. 兩個(gè)錯(cuò)誤的內(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);
 }
    　　

　　這些錯(cuò)誤通常也不太嚴(yán)重。盡管 C 標(biāo)準(zhǔn)在這些情形中沒有定義具體行為，但典型的實(shí)現(xiàn)將忽略錯(cuò)誤，或者快速而明確地對(duì)它們進(jìn)行標(biāo)記；總之，這些都是安全情形?！　?/p>

　　懸空指針　　

　　懸空指針比較棘手。當(dāng)程序員在內(nèi)存資源釋放后使用資源時(shí)會(huì)發(fā)生懸空指針（請(qǐng)參見　　清單 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)試”難以隔離懸空指針。由于下面兩個(gè)明顯原因，它們很難再現(xiàn)： 　　

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

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

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

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

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

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

　　編碼風(fēng)格　　

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

　　
清單 6. 識(shí)別資源的源代碼示例

　　                 
 /********
  * ...
  *
  * 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方法解決內(nèi)存問題： 　　

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

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

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

　　檢測(cè)　　

　　檢測(cè)是編碼標(biāo)準(zhǔn)的補(bǔ)充。二者各有裨益，但結(jié)合使用效果特別好。機(jī)靈的 C 或 C++ 專業(yè)人員甚至可以瀏覽不熟悉的源代碼，并以極低的成本檢測(cè)內(nèi)存問題。通過少量的實(shí)踐和適當(dāng)?shù)奈谋舅阉鳎軌蚩焖衮?yàn)證平衡的 *alloc() 和 free() 或者 new 和 delete 的源主體。人工查看此類內(nèi)容通常會(huì)出現(xiàn)像　　清單 7　　 中一樣的問題?！　?/p>

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

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

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

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

　　內(nèi)存庫　　

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

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

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

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

　　內(nèi)存工具　　

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

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

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

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

　　
清單 8. 示例錯(cuò)誤

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

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

　　結(jié)束語　　

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