https://www.ibm.com/developerworks/cn/aix/library/au-memorytechniques.html
内存错误的类别
首先，不要失去信心。有很多办法可以对付内存问题。我们先列出所有可能存在的实际问题：
- 内存泄漏
- 错误分配，包括大量增加
free()释放的内存和未初始化的引用 - 悬空指针
- 数组边界违规
这是所有类型。即使迁移到 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 个字符。在任何常规实现中，“超过的”字符会覆盖内存中的其他数据。内存中数据分配的布局非常复杂并且难以再现，所以任何症状都不可能追溯到源代码级别的具体错误。这些错误通常会导致数百万美元的损失。
内存编程的策略
勤奋和自律可以让这些错误造成的影响降至最低限度。下面我们介绍一下您可以采用的几个特定步骤；我在各种组织中处理它们的经验是，至少可以按一定的数量级持续减少内存错误。