10 个内存引发的大坑，你能躲开几个？（2）
对程序员来说内存相关的 bug 排查难度几乎和多线程问题并驾齐驱，当程序出现运行异常时可能距离真正有 bug 的那行代码已经很远了，这就导致问题定位排查非常困难，这篇文章将总结涉及内存的一些经典 bug ，快来看看你知道几个，或者你的程序中现在有几个。。。
读取未初始化的内存
我们来看这样一段代码：
void add() {
int* a = (int*)malloc(sizeof(int));
*a += 10;
}上述代码的错误之处在于假设从堆上动态分配的内存总是初始化为 0，实际上并不是这样的。
我们需要知道，当调用 malloc 时实际上有以下两种可能：
- 如果 malloc 自己维护的内存够用，那么 malloc 从空闲内存中找到一块大小合适的返回，注意，这一块内存可能是之前用过后释放的。在这种情况下，这块内存包含了上次使用时留下的信息，因此不一定为0
- 如果 malloc 自己维护的内存不够用，那么通过 brk 等系统调用向操作系统申请内存，在这种情况下操作系统返回的内存确实会被初始化为0。 原因很简单，操作系统返回的这块内存可能之前被其它进程使用过，这里面也许会包含了一些敏感信息，像密码之类，因此出于安全考虑防止你读取到其它进程的信息，操作系统在把内存交给你之前会将其初始化为0。
现在你应该知道了吧，你不能想当然的假定 malloc 返回给你的内存已经被初始化为 0，你需要自己手动清空。
内存泄漏
void memory_leak() {
int *p = (int *)malloc(sizeof(int));
return;
}上述代码在申请一段内存后直接返回，这样申请到的这块内存在代码中再也没有机会释放掉了，这就是内存泄漏。
内存泄漏是一类极为常见的问题，尤其对于不支持自动垃圾回收的语言来说，但并不是说自带垃圾回收的语言像 Java 等就不会有内存泄漏，这类语言同样会遇到内存泄漏问题。
有内存泄漏问题的程序会不断的申请内存，但不去释放，这会导致进程的堆区越来越大直到进程被操作系统 Kill 掉，在 Linux 系统中这就是有名的 OOM 机制，Out Of Memory Killer。
幸好，有专门的工具来检测内存泄漏出在了哪里，像valgrind、gperftools等。
内存泄漏是一个很有意思的问题，对于那些运行时间很短的程序来说，内存泄漏根本就不是事儿，因为对现代操作系统来说，进程退出后操作系统回收其所有内存，这就是意味着对于这类程序即使有内存泄漏也就是发生在短时间内，甚至你根本就察觉不出来。
但是对于服务器一类需要长时间运行的程序来说内存泄漏问题就比较严重了，内存泄漏将会影响系统性能最终导致进程被 OOM 杀掉，对于一些关键的程序来说，进程退出就意味着收入损失，特别是在节假日等重要节点出现内存泄漏的话，那么肯定又有一批程序员要被问责了。
引用已被释放的内存
void add() {
int* a = (int*)malloc(sizeof(int));
...
free(a);
int* b = (int*)malloc(sizeof(int));
*b = *a;
}这段代码在堆区申请了一块内存装入整数，之后释放，可是在后续代码中又再一次引用了被释放的内存块，此时a指向的内存保存什么内容取决于malloc 内部的工作状态：
- 指针a指向的那块内存释放后没有被 malloc 再次分配出去，那么此时a指向的值和之前一样
- 指针a指向的那块内存已经被 malloc分配出去了，此时a指向的内存可能已经被覆盖，那么*b得到的就是一个被覆盖掉的数据，这类问题可能要等程序运行很久才会发现，而且往往难以定位。
循环遍历是0开始的
void init(int n) {
int* arr = (int*)malloc(n * sizeof(int));
for (int i = 0; i <= n; i++) {
arr[i] = i;
}
}这段代码的本意是要初始化数组，但忘记了数组遍历是从 0 开始的，实际上述代码执行了 n+1 次赋值操作，同时将数组 arr 之后的内存用 i 覆盖掉了。
这同样取决于 malloc 的工作状态，如果 malloc 给到 arr 的内存本身比n*sizeof(int)要大，那么覆盖掉这块内存可能也不会有什么问题，但如果覆盖的这块内存中保存有 malloc 用于维护内存分配信息的话，那么此举将破坏 malloc 的工作状态。
