Cameron Laird (claird@phaseit.net), 副总裁, Phaseit Inc.
2007 年 6 月 21 日 本文将带您了解一些良好的和内存相关的编码实践，以将内存错误保持在控制范围内。内存错误是 C 和 C++ 编程的祸根：它们很普遍，认识其严重性已有二十多年，但始终没有彻底解决，它们可能严重影响应用程序，并且很少有开发团队对其制定明确的管理计划。但好消息是，它们并不怎么神秘。
引言
C 和 C++ 程序中的内存错误非常有害：它们很常见，并且可能导致严重的后果。来自计算机应急响应小组（请参见参考资料）和供应商的许多最严重的安全公告都是由简单的内存错误造成的。自从 70 年代末期以来，C 程序员就一直讨论此类错误，但其影响在 2007 年仍然很大。更糟的是，如果按我的思路考虑，当今的许多 C 和 C++ 程序员可能都会认为内存错误是不可控制而又神秘的顽症，它们只能纠正，无法预防。
存在内存错误的 C 和 C++ 程序会导致各种问题。如果它们泄漏内存，则运行速度会逐渐变慢，并最终停止运行；如果覆盖内存，则会变得非常脆弱，很容易受到恶意用户的攻击。从 1988 年著名的莫里斯蠕虫 攻击到有关 Flash Player 和其他关键的零售级程序的最新安全警报都与缓冲区溢出有关：“大多数计算机安全漏洞都是缓冲区溢出”，Rodney Bates 在 2004 年写道。
在可以使用 C 或 C++ 的地方，也广泛支持使用其他许多通用语言（如 Java™、Ruby、Haskell、C#、Perl、Smalltalk 等），每种语言都有众多的爱好者和各自的优点。但是，从计算角度来看，每种编程语言优于 C 或 C++ 的主要优点都与便于内存管理密切相关。与内存相关的编程是如此重要，而在实践中正确应用又是如此困难，以致于它支配着面向对象编程语言、功能性编程语言、高级编程语言、声明性编程语言和另外一些编程语言的所有其他变量或理论。
因此，出于所有这些原因，需要特别关注 C 和 C++ 编程的内存问题。让我们看一看如何解决这些问题，先不谈是哪种语言。
内存错误的类别
首先，不要失去信心。有很多办法可以对付内存问题。我们先列出所有可能存在的实际问题： 内存泄漏 错误分配，包括大量增加 free() 释放的内存和未初始化的引用 悬空指针 数组边界违规 这是所有类型。即使迁移到 C++ 面向对象的语言，这些类型也不会有明显变化；无论数据是简单类型还是 C 语言的 struct 或 C++ 的类，C 和 C++ 中内存管理和引用的模型在原理上都是相同的。以下内容绝大部分是“纯 C”语言，对于扩展到 C++ 主要留作练习使用。
/* Note that p remains uninitialized here. */ free(p); }
这些错误通常也不太严重。尽管 C 标准在这些情形中没有定义具体行为，但典型的实现将忽略错误，或者快速而明确地对它们进行标记；总之，这些都是安全情形。
悬空指针
悬空指针比较棘手。当程序员在内存资源释放后使用资源时会发生悬空指针（请参见清单 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; }
传统的“调试”难以隔离悬空指针。由于下面两个明显原因，它们很难再现： 即使影响提前释放内存范围的代码已本地化，内存的使用仍然可能取决于应用程序甚至（在极端情况下）不同进程中的其他执行位置。 悬空指针可能发生在以微妙方式使用内存的代码中。结果是，即使内存在释放后立即被覆盖，并且新指向的值不同于预期值，也很难识别出新值是错误值。 悬空指针不断威胁着 C 或 C++ 程序的运行状态。
清单 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;
/******* * ... * * 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];
/******** * ... * 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;
检测是编码标准的补充。二者各有裨益，但结合使用效果特别好。机灵的 C 或 C++ 专业人员甚至可以浏览不熟悉的源代码，并以极低的成本检测内存问题。通过少量的实践和适当的文本搜索，您能够快速验证平衡的 *alloc() 和 free() 或者 new 和 delete 的源主体。人工查看此类内容通常会出现像清单 7 中一样的问题。
清单 7. 棘手的内存泄漏 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); ... }
由于这些原因，我们催促 C 和 C++ 程序员为解决内存问题先了解一下自己的源。在这完成之后，才去考虑库。
使用几个库能够编写常规的 C 或 C++ 代码，并保证改进内存管理。Jonathan Bartlett 在 developerWorks 的 2004 评论专栏中介绍了主要的候选项，可以在下面的参考资料部分获得。库可以解决多种不同的内存问题，以致于直接对它们进行比较是非常困难的；这方面的常见主题包括垃圾收集、智能指针 和 智能容器。大体上说，库可以自动进行较多的内存管理，这样程序员可以犯更少的错误。
我对内存库有各种感受。他们在努力工作，但我看到他们在项目中获得的成功比预期要小，尤其在 C 方面。我尚未对这些令人失望的结果进行仔细分析。例如，业绩应该与相应的手动 内存管理一样好，但是这是一个灰色区域——尤其在垃圾收集库处理速度缓慢的情况下。通过这方面的实践得出的最明确的结论是，与 C 关注的代码组相比，C++ 似乎可以较好地接受智能指针。
内存工具
开发真正基于 C 的应用程序的开发团队需要运行时内存工具作为其开发策略的一部分。已介绍的技术很有价值，而且不可或缺。在您亲自尝试使用内存工具之前，其质量和功能您可能还不了解。
