共计 2348 个字符，预计需要花费 6 分钟才能阅读完成。
| 导读 | 有很多情况会导致这一问题，像重复使用的某个结构体 / 对象，当再次复用时没有清理上一次使用遗留的数据、系统中存在 cache，但 cache 的过期策略设置不得当等等。 |
大家好，我是小风哥，今天和大家聊一聊内存泄漏这个话题。
我之前写过好几篇关于内存的文章，在这些文章讲到内存申请时我很喜欢用停车场来做类比，内存申请就好比去停车场找停车位，找到停车位后你就可以把车停在这里。
从这个类比看什么是内存泄漏呢? 内存泄漏看上去是停车场的车辆只进不出导致最终找不到停车位，从程序员的角度看就是内存只申请取不释放，如果你去问，可能有不少人认为内存泄漏就是这么回事。
然而这其实是不全面的。
首先内存只申请不释放未必就是内存泄漏，有可能是你的程序的确需要申请很多内存，这是正常的，然而如果是 bug 导致申请了很多内存，这就是内存泄漏了，或者也有人将其称为 space leak，意思是申请的内存超过了正常所需; 不管是有意无意，总之在这种情况下你依然保持对这些内存的引用，因此你总可以找到这些内存并删除它们，就看你删不删。
有很多情况会导致这一问题，像重复使用的某个结构体 / 对象，当再次复用时没有清理上一次使用遗留的数据、系统中存在 cache，但 cache 的过期策略设置不得当等等。
另一类比较有趣的内存泄漏是说你申请了一些内存，但最终却没有什么指向它们：
void memory_leak() {char* mem = (char*)malloc(1024);
// just return
}在这段代码中我们申请了 1k 内存，然而当 memory_leak 函数返回后你就再也不知道这段内存到底在哪里了!
用停车场的示例来说就是有些司机太过土豪，家里的车太多以至于把将车放在停车场这件事忘掉了，导致这些车根本就不会有人再开走，因此白白浪费停车位，并导致可用车位越来越少，而对于编程来说就是粗心大意的程序员申请了一些内存后最终“忘掉”了，再也不会有什么东西 (变量 / 指针) 指向这些内存，因此在这种情况下你没有办法再找到这些内存并将其删除。
内存碎片
这也算的上是一类特殊的内存泄漏，用停车场的例子来说就是两个停车位中间停靠了一辆小型老年代步车，导致尽管这两个停车位剩余的空间足够大但又恰好都没有办法再停靠一辆小汽车。
假定我们系统中宝贵的内存大小只有 8 字节，其中有两个字节已经分配出去了，就像这样：
现在，系统中空闲的内存是 6 字节，下一次的内存申请需要分配 5 字节，糟糕，我们已经没有办法再找到连续的 5 个字节大小的内存空间了，尽管全部空间的内存还有 6 字节，这就是所谓的内存碎片问题。
而对于内存分配器来说如果出现这种情况那么将不得不借助操作系统的帮助来扩大堆区，因此看起来我们的程序占据的内存越来越多，尽管实际上程序可能并不需要那么多内存，仅仅是因为内存碎片的原因导致一部分内存无法被再次被利用起来。
然而对于现代操作系统尤其具备虚拟内存能力的系统来说，内存碎片问题通常可能并不会和我们想象的那样严重，原因就在于分配的内存只需要在虚拟地址空间上连续而不必在物理内存上也连续，假定我们在虚拟内存地址空间需要存放“aabbccdd”这样的字符串，在虚拟地址空间上看这是连续的就像这样：
但在物理内存上可能是这样存放的：
可以看到，利用虚拟内存我们可以更加充分灵活的利用“边边角角”的物理内存，从而减少内存碎片带来的影响。
关于虚拟内存更详细的讲解你可以参考《深入理解操作系统》虚拟内存一章，关于公众号“码农的荒岛求生”并回复“操作系统”即可。
如果你的程序需要重复申请很多对象 / 数据 / 结构体，并在最后一次性全部释放，那么内存池是一个避免内存碎片不错的选择，原理在于尽管从内存池的角度看会有碎片，但当我们以内存池大小为单位从堆区中申请释放内存时，这种碎片将不复存在。
关于内存池你可以参考这篇《高性能服务器内存池是如何实现的》。
在现代操作系统中除非你的程序运行时间足够长或者申请的内存足够快足够多否则内存泄漏可能并不是什么大问题，你甚至可能都察觉不出来有内存泄漏，因为当进程运行结束后其占据的内存会被操作系统收回，在这种情况下你可能不必过于关心这个问题，但对于长时间运行的服务器端程序、数据库程序、操作系统等，内存泄漏就属于比较严重的问题了，因为这些程序必须时刻在线，任何微小的内存泄漏在时间的加持下都会非常明显。
如果内存持续泄漏那么你的电脑可能会爆炸。。。这。。。当然是不可能的。
你的系统会慢到炸是有可能的。
内存的申请速度会对系统性能产生很大的影响，当系统内存不足时，内存分配器找到一块满足要求的空闲内存块将更加困难耗时更多，当程序消耗的内存超过物理内存大小时虚拟内存系统 (如果有的话) 开始发挥作用，将进程地址空间中不常用的一部分 swap 出去，此时系统性能将快速下降，表现出来的就是程序员运行变慢、卡顿。
当然，根据系统配置，像 Linux 系统，可能会将消耗内存很多的进程 kill 掉，这就是 Out of Memory killer，简称 oom killer。
不像程序崩溃 Core dump，这类问题通过 debug 通常能获取一些线索，但内存泄漏问题就没那么直接了，尤其对于 C /C++ 程序来说，这时我们将不得不借助必要的工具。
那么我们该利用什么的工具来解决内存泄漏问题呢? 下一篇文章将给你答案。
这个公众号里所有的文章都已经汇总在了 Github 上，地址 https://github.com/xfenglu/everycodershouldknow，你也可以点击左下方“阅读原文”直达，欢迎访问，求 star，哈哈。
