什么是内存碎片？

Question

我曾多次听说过 C++ 动态内存分配中使用过“内存碎片”这个术语。我发现了一些关于如何处理内存碎片的问题，但找不到处理它本身的直接问题。那么：

• 什么是内存碎片？
• 如何判断内存碎片是否是我的应用程序的问题？什么样的程序最有可能受到影响？
• 处理内存碎片的常用方法有哪些？

另外：

• 我听说大量使用动态分配会增加内存碎片。这是真的吗？在 C++ 上下文中，我了解所有标准容器（std::string、std::vector 等）都使用动态内存分配。如果在整个程序中使用这些（尤其是 std::string），内存碎片是否更有可能成为问题？
• 在 STL 密集型应用程序中如何处理内存碎片？

Answer 1

想象一下，您有一个“大”（32 字节）的可用内存：

----------------------------------
|                                |
----------------------------------

现在，分配其中一些（5 次分配）：

----------------------------------
|aaaabbccccccddeeee              |
----------------------------------

现在，释放前四个分配，但不释放第五个：

----------------------------------
|              eeee              |
----------------------------------

现在，尝试分配 16 字节。哎呀，我不能，尽管有几乎两倍的免费空间。

在具有虚拟内存的系统上，碎片问题比您想象的要小，因为大型分配只需要在虚拟地址空间中连续，而不是在物理地址空间中连续。因此，在我的示例中，如果我的虚拟内存页面大小为 2 字节，那么我可以毫无问题地进行 16 字节分配。物理内存看起来像这样：

----------------------------------
|ffffffffffffffeeeeff            |
----------------------------------

而虚拟内存（更大）可能看起来像这样：

------------------------------------------------------...
|              eeeeffffffffffffffff                   
------------------------------------------------------...

内存碎片的典型症状是，你尝试分配一个大块，但你不能，即使你看起来有足够的可用内存。另一个可能的结果是进程无法将内存释放回操作系统（因为它从操作系统分配的每个大块，用于 malloc 等进行细分，都会留下一些东西它，即使每个块的大部分现在都未使用）。

C++ 中防止内存碎片的策略是根据对象的大小和/或预期寿命从不同区域分配对象。因此，如果您要创建大量对象并稍后将它们全部销毁，请从内存池中分配它们。您在它们之间进行的任何其他分配都不会来自池，因此不会位于内存中的它们之间，因此内存不会因此而产生碎片。或者，如果您要分配大量相同大小的对象，则从同一个池中分配它们。那么池中的一段可用空间永远不会小于您尝试从该池分配的大小。

一般来说，您不需要太担心，除非您的程序长时间运行并且进行大量分配和释放。当您同时拥有短期和长期对象时，您面临的风险最大，但即使如此，malloc 也会尽力提供帮助。基本上，忽略它，直到您的程序分配失败或意外导致系统内存不足（在测试中捕捉到这一点，以供优先选择！）。

标准库并不比任何分配内存的东西差，标准容器都有一个 Alloc 模板参数，如果绝对必要，您可以使用它来微调它们的分配策略。

Answer 2

什么是内存碎片？

内存碎片是指大部分内存被分配在大量不连续的块或块中 - 总内存中有很大一部分未分配，但对于大多数典型情况来说无法使用场景。这会导致内存不足异常或分配错误（即 malloc 返回 null）。

思考这个问题的最简单方法是想象您有一面空荡荡的大墙，您需要在上面放置不同尺寸的图片。每张图片都占据一定的大小，显然您无法将其分割成更小的部分以使其适合。墙上需要有一个空位，和照片的大小一样，否则你就无法把它挂起来。现在，如果您开始将图片挂在墙上，并且不小心如何排列它们，那么您很快就会看到墙壁部分被图片覆盖，即使您可能有空位，大多数新图片也无法容纳因为它们比可用的位置大。您仍然可以悬挂非常小的图片，但大多数图片都不适合。因此，您必须重新排列（压缩）墙上已有的内容，以便为更多内容腾出空间。

现在，想象一下墙壁是您的（堆）内存，而图片是对象。这就是内存碎片

。 strong>如何判断内存碎片是否是我的应用程序的问题？哪种程序最有可能受到影响？

一个明显的迹象表明您可能正在处理内存碎片问题，那就是如果您遇到许多分配错误，特别是当已用内存的百分比很高时 - 但并非您还没有遇到这种情况用尽了所有内存 - 因此从技术上讲，您应该有足够的空间来容纳您尝试分配的对象。

当内存碎片严重时，内存分配可能会花费更长的时间，因为内存分配器必须做更多的工作来为新对象找到合适的空间。如果反过来你有很多内存分配（你可能会这样做，因为你最终产生了内存碎片），分配时间甚至可能会导致明显的延迟。

处理内存碎片的常用方法有哪些？

使用好的算法来分配内存。不要为大量小对象分配内存，而是为这些较小对象的连续数组预先分配内存。有时，分配内存时稍微浪费一点可以提高性能，并且可以省去处理内存碎片的麻烦。

Answer 3

内存碎片与磁盘碎片的概念相同：它指的是由于正在使用的区域没有足够紧密地排列在一起而浪费的空间。

假设一个简单的玩具示例，您有 10 个字节的内存：

 |   |   |   |   |   |   |   |   |   |   |
   0   1   2   3   4   5   6   7   8   9

现在让我们分配三个三字节块，名称为 A、B 和 C：

 | A | A | A | B | B | B | C | C | C |   |
   0   1   2   3   4   5   6   7   8   9

现在释放块 B：

 | A | A | A |   |   |   | C | C | C |   |
   0   1   2   3   4   5   6   7   8   9

现在如果我们尝试分配一个四字节块 D 会发生什么？好吧，我们有四个字节的空闲内存，但是我们没有四个连续字节的空闲内存，所以我们无法分配 D！这是对内存的低效利用，因为我们本来应该能够存储 D，但我们却做不到。我们无法移动 C 来腾出空间，因为我们程序中的某些变量很可能指向 C，而我们无法自动查找并更改所有这些值。

你怎么知道这是一个问题？嗯，最大的迹象是您的程序的虚拟内存大小比您实际使用的内存量大得多。在现实世界的示例中，您将拥有超过 10 个字节的内存，因此 D 将从字节 9 开始分配，而字节 3-5 将保持未使用状态，除非您后来分配了长度为 3 个字节或更小的内容。

在这个例子中，3个字节并不算太多浪费，但考虑一个更病态的情况，例如，两次分配几个字节在内存中相距10兆字节，并且您需要分配一个大小为10兆字节的块+ 1 字节。你必须向操作系统请求多十兆字节以上的虚拟内存才能做到这一点，即使你只差一个字节就已经拥有足够的空间了。

你如何预防它？当您频繁创建和销毁小对象时，往往会出现最糟糕的情况，因为这往往会产生“瑞士奶酪”效应，许多小对象被许多小孔分隔开，从而无法在这些孔中分配更大的对象。当您知道要这样做时，一个有效的策略是预先分配一大块内存作为小对象的池，然后手动管理该块内小对象的创建，而不是让默认分配器处理它。

一般来说，分配的次数越少，内存碎片的可能性就越小。然而，STL 相当有效地处理了这个问题。如果您有一个字符串正在使用其当前分配的全部空间，并且您向其附加一个字符，那么它不会简单地重新分配其当前长度加一，而是将其长度加倍。这是“频繁小额分配池”策略的变体。该字符串正在占用一大块内存，以便它可以有效地处理大小的重复小幅增加，而无需进行重复的小幅重新分配。事实上，所有 STL 容器都会执行此类操作，因此通常您无需太担心自动重新分配 STL 容器所导致的碎片。

当然，STL 容器不会在彼此之间池化内存，因此如果您要创建许多小型容器（而不是一些经常调整大小的容器），您可能需要担心防止碎片的方式与防止任何频繁创建的小对象（无论是否为 STL）的方式相同。

Answer 4

• 什么是内存碎片？

内存碎片是指内存在理论上可用的情况下变得不可用的问题。有两种碎片：内部碎片是已分配但无法使用的内存（例如，当内存以 8 字节块分配，但程序在只需要 4 字节时重复执行单个分配）。 外部碎片是空闲内存被分成许多小块的问题，因此尽管总体空闲内存足够，但仍无法满足大的分配请求。

• 如何判断内存碎片是否是我的应用程序的问题？什么样的程序最有可能受到影响？

如果您的程序使用的系统内存比其实际有效数据所需的多得多（并且您已经排除了内存泄漏），那么内存碎片就是一个问题。

• 处理内存碎片的常用方法有哪些？

使用好的内存分配器。 IIRC，那些使用“最适合”策略的人通常在避免碎片化方面要优越得多，尽管速度稍慢一些。然而，也有研究表明，对于任何分配策略，都存在病态的最坏情况。幸运的是，大多数应用程序的典型分配模式实际上对于分配器来说是相对良性的。如果您对细节感兴趣，可以参考很多论文：

• Paul R. Wilson、Mark S. Johnstone、Michael Neely 和 David Boles。动态存储分配：调查和批判性评论。 1995 年会议论文集
  国际内存管理研讨会，Springer Verlag LNCS，1995 年
• Mark S.Johnstone、Paul R. Wilson。内存碎片问题：解决了吗？
  摘自 ACM SIG-PLAN 公告，第 34 卷第 3 期，第 26-36 页，1999 年
• M.R. Garey、RL Graham 和 JD Ullman。内存分配算法的最坏情况分析。第四届 ACM 计算理论年度研讨会，1972 年

Answer 5

更新：
Google TCMalloc：线程缓存 Malloc
人们发现它非常擅长处理长时间运行的进程中的碎片。

---

我一直在开发一个服务器应用程序，该应用程序在 HP-UX 11.23/11.31 ia64 上存在内存碎片问题。

看起来像这样。有一个进程进行内存分配和释放并运行了数天。即使没有内存泄漏，进程的内存消耗仍然在增加。

关于我的经历。在 HP-UX 上，使用 HP-UX gdb 很容易找到内存碎片。您设置一个断点，当您点击它时，您运行此命令：info heap 并查看进程的所有内存分配和堆的总大小。然后你继续你的程序，然后一段时间后你再次遇到断点。您再次执行信息堆。如果堆的总大小较大，但单独分配的数量和大小相同，则可能存在内存分配问题。如有必要，请多次检查。

我改善这种情况的方法是这样的。在使用 HP-UX gdb 进行一些分析后，我发现内存问题是由于我使用 std::vector 存储数据库中某些类型的信息而引起的。 std::vector 要求其数据必须保存在一个块中。我有一些基于 std::vector 的容器。这些容器会定期重新创建。经常会出现这样的情况：将新记录添加到数据库中，然后重新创建容器。由于重新创建的容器更大，因此它们不适合可用的空闲内存块，并且运行时要求操作系统提供一个新的更大的块。因此，即使没有内存泄漏，进程的内存消耗也会增加。当我更换容器时，情况得到了改善。我开始使用 std::deque 而不是 std::vector，它具有不同的数据分配内存方式。

我知道在 HP-UX 上避免内存碎片的方法之一是使用 Small Block Allocator 或使用 MallocNextGen。在 RedHat Linux 上，默认分配器似乎可以很好地处理大量小块的分配。 Windows 上有低碎片堆，它解决了大量小分配的问题。

我的理解是，在大量使用 STL 的应用程序中，您首先必须发现问题。内存分配器（如 libc 中的）实际上处理大量小分配的问题，这对于 std::string 来说是典型的（例如，在我的服务器应用程序中，有很多 STL 字符串，但正如我所见）从运行 info heap 来看，它们不会造成任何问题）。我的印象是，您需要避免频繁的大量分配。不幸的是，在某些情况下您无法避免它们并且必须更改代码。正如我在我的例子中所说的，当切换到 std::deque 时，我改善了情况。如果你确定了你的记忆碎片，也许可以更准确地谈论它。

Answer 6

当您分配和释放许多不同大小的对象时，最有可能发生内存碎片。假设您的内存布局如下：

obj1 (10kb) | obj2(20kb) | obj3(5kb) | unused space (100kb)

现在，当 obj2 被释放时，您有 120kb 未使用的内存，但您无法分配完整的 120kb 块，因为内存是碎片化的。

避免这种影响的常见技术包括环形缓冲区和对象池。在 STL 的上下文中，类似 std::vector::reserve 的方法() 可以提供帮助。

Answer 7

关于内存碎片的非常详细的答案可以在这里找到。

http://library.softwareverify.com/memory-fragmentation-your-worst- 。

这是 11 年来我一直在 softwareverify.com 上为向我询问有关内存碎片问题的人们提供的内存碎片答案的巅峰之作

Answer 8

什么是内存碎片？

当您的应用程序使用动态内存时，它会分配和释放内存块。一开始，应用程序的整个内存空间是一个连续的可用内存块。但是，当您分配和释放不同大小的块时，内存开始变得碎片化，即不再是一个大的连续空闲块和许多连续的已分配块，而是会出现一个已分配和空闲块混淆了。由于空闲块的大小有限，因此很难重用它们。例如，您可能有 1000 字节的空闲内存，但无法为 100 字节的块分配内存，因为所有空闲块的长度最多为 50 字节。

另一个不可避免但问题较少的碎片来源是，在大多数体系结构中，内存地址必须与 2、4、8 等字节边界对齐（即地址必须是 2、4、 8 等）这意味着，即使您有一个包含 3 个 char 字段的结构，您的结构的大小也可能为 12 而不是 3，因为每个字段都与 4 对齐- 字节边界。

如何判断内存碎片是否是我的应用程序的问题？什么样的程序最有可能受到影响？

显而易见的答案是您会遇到内存不足异常。

显然，没有好的可移植方法来检测 C++ 应用程序中的内存碎片。有关更多详细信息，请参阅此答案。

处理内存碎片的常用方法有哪些？

这在 C++ 中很困难，因为您在指针中使用直接内存地址，并且无法控制谁引用特定内存地址。因此，重新排列分配的内存块（Java 垃圾收集器的方式）并不是一种选择。

自定义分配器可以帮助管理较大内存块中小对象的分配，并重用该块中的空闲槽。

Answer 9

这是针对傻瓜的超级简化版本。

当对象在内存中创建时，它们会被添加到内存中已使用部分的末尾。

如果删除了不在已用内存部分末尾的对象，这意味着该对象位于其他两个对象之间，它将创建一个“洞”。

这就是所谓的碎片化。

Answer 10

当您想在堆上添加一个项目时，计算机必须搜索空间来容纳该项目。这就是为什么动态分配如果不在内存池上或使用池化分配器完成会“减慢”速度。对于重型 STL 应用程序，如果您正在进行多线程处理，可以使用 Hoard 分配器 或 TBB Intel 版本。

现在，当内存碎片化时，可能会发生两种情况：

1. 必须进行更多搜索才能找到合适的空间来粘贴“大”对象。也就是说，由于许多小对象分散在各处，因此在某些条件下寻找一块漂亮的连续内存块可能会很困难（这些都是极端的）。
2. 内存不是一些容易读取的实体。处理器的容量和存储位置受到限制。如果他们需要的项目在一个地方但当前地址在另一个地方，他们会通过交换页面来实现这一点。如果您经常需要交换页面，处理速度可能会变慢（这又会影响性能的极端情况。）请参阅 虚拟内存。

Answer 11

内存碎片的产生是因为请求了不同大小的内存块。考虑 100 字节的缓冲区。您请求两个字符，然后请求一个整数。现在您释放这两个字符，然后请求一个新的整数，但该整数无法容纳这两个字符的空间。该内存无法重新使用，因为它不在足够大的连续块中以进行重新分配。最重要的是，您为字符调用了大量分配器开销。

本质上，在大多数系统上，内存仅以一定大小的块的形式存在。一旦您分割了这些块，它们就无法重新连接，直到整个块被释放为止。这可能会导致整个块都在使用，而实际上只有块的一小部分在使用。

减少堆碎片的主要方法是进行更大、频率更低的分配。在极端情况下，您可以使用能够移动对象的托管堆，至少可以在您自己的代码中移动对象。无论如何，从内存的角度来看，这完全消除了问题。显然移动物体等是有成本的。实际上，只有当您经常从堆中分配非常少量的资源时，才会真正遇到问题。使用连续的容器（向量、字符串等）并尽可能多地在堆栈上分配（对于性能来说总是一个好主意）是减少它的最佳方法。这还提高了缓存一致性，从而使您的应用程序运行得更快。

您应该记住的是，在 32 位 x86 桌面系统上，您拥有整个 2GB 内存，它被分成 4KB“页面”（可以肯定页面大小在所有 x86 系统上都是相同的）。您必须调用一些 omgwtfbbq 碎片才会出现问题。碎片确实是一个过去的问题，因为现代堆对于绝大多数应用程序来说都太大了，而且有很多系统能够承受碎片，例如托管堆。

Answer 12

哪种程序最有可能受到影响？

与内存碎片相关的问题的一个很好的（=可怕的）例子是“Elemental: War of Magic”的开发和发布 >，Stardock 开发的一款电脑游戏。

该游戏是为 32 位/2GB 内存构建的，必须在内存管理方面进行大量优化才能使游戏在 2GB 内存内运行。由于“优化”导致不断的分配和取消分配，随着时间的推移，堆内存碎片会发生，并导致游戏每次一次崩溃。

YouTube 上有一个“战争故事”采访。