深度解析内存泄漏：揭示真相与防止策略

当前位置：首页电脑知识游戏

深度解析内存泄漏：揭示真相与防止策略

日期：2024-01-22 09:55:02来源：浏览：

来源丨经授权转自码农的荒岛求生（ID：escape-it）

作者丨码农的荒岛求生

大家好，我是小风哥，今天和大家聊一聊内存泄漏这个话题。

我之前写过好几篇关于内存的文章，在这些文章讲到内存申请时我很喜欢用停车场来做类比，内存申请就好比去停车场找停车位，找到停车位后你就可以把车停在这里。

从这个类比看什么是内存泄漏呢？内存泄漏看上去是停车场的车辆只进不出导致最终找不到停车位，从程序员的角度看就是内存只申请取不释放，如果你去问，可能有不少人认为内存泄漏就是这么回事。

然而这其实是不全面的。

申请过多内存

首先内存申请不释放未必就是内存泄漏，有可能是你的程序的确需要申请很多内存，这是正常的，然而如果是bug导致申请了很多内存，这就是内存泄漏了，或者也有人将其称为space leak，意思是申请的内存超过了正常所需；不管是有意无意，总之在这种情况下你依然保持对这些内存的引用，因此你总可以找到这些内存并删除它们，就看你删不删。

有很多情况会导致这一问题，像重复使用的某个结构体/对象，当再次复用时没有清理上一次使用遗留的数据、系统中存在cache，但cache的过期策略设置不得当等等。

内存无法删除

另一类比较有趣的内存泄漏是说你申请了一些内存，但最终却没有什么指向它们：

void memory_leak() {  char* mem = (char*)malloc(1024);  // just return}

在这段代码中我们申请了1k内存，然而当memory_leak函数返回后你就再也不知道这段内存到底在哪里了！

用停车场的示例来说就是有些司机太过土豪，家里的车太多以至于把将车放在停车场这件事忘掉了，导致这些车根本就不会有人再开走，因此白白浪费停车位，并导致可用车位越来越少，而对于编程来说就是粗心大意的程序员申请了一些内存后最终“忘掉”了，再也不会有什么东西(变量/指针)指向这些内存，因此在这种情况下你没有办法再找到这些内存并将其删除。

内存碎片

这也算得上是一类特殊的内存泄漏，用停车场的例子来说就是两个停车位中间停靠了一辆小型老年代步车，导致尽管这两个停车位剩余的空间足够大但又恰好都没有办法再停靠一辆小汽车。

假定我们系统中宝贵的内存大小只有8字节，其中有两个字节已经分配出去了，就像这样：

现在，系统中空闲的内存是6字节，下一次的内存申请需要分配5字节，糟糕，我们已经没有办法再找到连续的5个字节大小的内存空间了，尽管全部空间的内存还有6字节，这就是所谓的内存碎片问题。

而对于内存分配器来说如果出现这种情况那么将不得不借助操作系统的帮助来扩大堆区，因此看起来我们的程序占据的内存越来越多，尽管实际上程序可能并不需要那么多内存，仅仅是因为内存碎片的原因导致一部分内存无法被再次被利用起来。

然而对于现代操作系统尤其具备虚拟内存能力的系统来说，内存碎片问题通常可能并不会和我们想象的那样严重，原因就在于分配的内存只需要在虚拟地址空间上连续而不必在物理内存上也连续，假定我们在虚拟内存地址空间需要存放“aabbccdd”这样的字符串，在虚拟地址空间上看这是连续的就像这样：

但在物理内存上可能是这样存放的：

可以看到，利用虚拟内存我们可以更加充分灵活地利用“边边角角”的物理内存，从而减少内存碎片带来的影响。

关于虚拟内存更详细地讲解你可以参考《深入理解操作系统》虚拟内存一章，关于公众号“码农的荒岛求生”并回复“操作系统”即可。

如果你的程序需要重复申请很多对象/数据/结构体，并在最后一次性全部释放，那么内存池是一个避免内存碎片不错的选择，原理在于尽管从内存池的角度看会有碎片，但当我们以内存池大小为单位从堆区中申请释放内存时，这种碎片将不复存在。

关于内存池你可以参考这篇《高性能服务器内存池是如何实现的》。

内存泄漏带来的问题

在现代操作系统中除非你的程序运行时间足够长或者申请的内存足够快足够多否则内存泄漏可能并不是什么大问题，你甚至可能都察觉不出来有内存泄漏，因为当进程运行结束后其占据的内存会被操作系统收回，在这种情况下你可能不必过于关心这个问题，但对于长时间运行的服务器端程序、数据库程序、操作系统等，内存泄漏就属于比较严重的问题了，因为这些程序必须时刻在线，任何微小的内存泄漏在时间的加持下都会非常明显。