本文将带您了解一些良好的和内存相关的编码实践，以将内存错误保持在控制范围内。内存错误是 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++ 编程的内存问题。让我们看一看如何解决这些问题，先不谈是哪种语言。

      内存错误的类别

　　首先，不要失去信心。有很多办法可以对付内存问题。我们先列出所有可能存在的实际问题：

　　1.内存泄漏

　　2.错误分配，包括大量增加 free()释放的内存和未初始化的引用

　　3.悬空指针

　　4.数组边界违规

      这是所有类型。即使迁移到 C++ 面向对象的语言，这些类型也不会有明显变化;无论数据是简单类型还是 C 语言的 struct或 C++ 的类，C 和 C++ 中内存管理和引用的模型在原理上都是相同的。以下内容绝大部分是“纯 C”语言，对于扩展到 C++ 主要留作练习使用。

      内存泄漏

　　在分配资源时会发生内存泄漏，但是它从不回收。下面是一个可能出错的模型(请参见清单 1)：

      清单 1. 简单的潜在堆内存丢失和缓冲区覆盖

以下是引用片段： 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()释放的内存具有不寻常的响应能力，否则每次对 f1的调用都会泄漏 100 字节。在记忆棒增量分发数兆字节内存时，一次泄漏是微不足道的，但是连续操作数小时后，即使如此小的泄漏也会削弱应用程序。

　　在实际的 C 和 C++ 编程中，这不足以影响您对 malloc()或 new的使用，本部分开头的句子提到了“资源”不是仅指“内存”，因为还有类似以下内容的示例(请参见清单 2)。FILE句柄可能与内存块不同，但是必须对它们给予同等关注：

      清单 2. 来自资源错误管理的潜在堆内存丢失

以下是引用片段： int getkey(char *filename) {     FILE *fp;     int key;     fp = fopen(filename, "r");     fscanf(fp, "%d", &key);     return key;         }

　　fopen的语义需要补充性的 fclose。在没有 fclose()的情况下，C 标准不能指定发生的情况时，很可能是内存泄漏。其他资源(如信号量、网络句柄、数据库连接等)同样值得考虑。

      内存错误分配

　　错误分配的管理不是很困难。下面是一个示例(请参见清单 3)：

      清单 3. 未初始化的指针

以下是引用片段： void f2(int datum) {     int *p2;                 /* Uh-oh!  No one has initialized p2. */             *p2 = datum;        ...         }

　　关于此类错误的好消息是，它们一般具有显著结果。在 AIX 下，对未初始化指针的分配通常会立即导致 segmentation fault错误。它的好处是任何此类错误都会被快速地检测到;与花费数月时间才能确定且难以再现的错误相比，检测此类错误的代价要小得多。

　　在此错误类型中存在多个变种。free()释放的内存比 malloc()更频繁(请参见清单 4)：

      清单 4. 两个错误的内存释放

以下是引用片段： /* 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 标准在这些情形中没有定义具体行为，但典型的实现将忽略错误，或者快速而明确地对它们进行标记;总之，这些都是安全情形。

      悬空指针

　　悬空指针比较棘手。当程序员在内存资源释放后使用资源时会发生悬空指针(请参见清单 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++ 程序的运行状态。

      数组边界违规

　　数组边界违规十分危险，它是内存错误管理的最后一个主要类别。回头看一下清单 1;如果 explanation的长度超过 80，则会发生什么情况?回答：难以预料，但是它可能与良好情形相差甚远。特别是，C 复制一个字符串，该字符串不适于为它分配的 100 个字符。在任何常规实现中，“超过的”字符会覆盖内存中的其他数据。内存中数据分配的布局非常复杂并且难以再现，所以任何症状都不可能追溯到源代码级别的具体错误。这些错误通常会导致数百万美元的损失。

      内存编程的策略

　　勤奋和自律可以让这些错误造成的影响降至最低限度。下面我们介绍一下您可以采用的几个特定步骤;我在各种组织中处理它们的经验是，至少可以按一定的数量级持续减少内存错误。

[1] [2] 下一页