64位土地中的堆碎片

Question

过去，当我在长时间运行C++守护进程时，我不得不处理堆碎片问题。像保留大量分配池这样的技巧是为了防止连续堆空间耗尽所必需的。

这仍然是一个64位地址空间的问题？ Perf对我来说不是一个问题，所以我宁愿简化我的代码，不再处理缓冲池等事情。有没有人有任何关于这个问题的经验或故事？我正在使用Linux，但我想象许多相同的问题适用于Windows。

Answer 1

如果您的进程真正需要千兆字节的虚拟地址空间，那么升级到64位确实会立即消除对解决方法的需求。

但值得研究你期望你的过程使用多少内存。如果它只有一个GB或更少的区域，那么即使疯狂的碎片也不会让你用完32位地址空间 - 内存泄漏可能是问题所在。 （顺便说一下，Windows更具有限制性，因为它在操作系统的每个进程中都保留了不重要的地址空间量）。

Answer 2

堆碎片在32位以下的64位下是一样的问题。如果您以不同的生命周期提出大量请求，那么您将得到一个零碎的堆。不幸的是，64位操作系统并没有真正帮助解决这个问题，因为它们仍然无法真正地将小部分空闲内存移动到更大的连续块。

如果你想处理堆碎片，你仍然必须使用相同的旧技巧。

64位操作系统在这里可以提供帮助的唯一方法是，如果存在足够大的内存量以至于您永远不会分割它。

Answer 3

这仍然是64位地址空间的问题吗？

不，这不是问题。

这是32位系统上的问题，但这不再是64位系统上的问题。

64位系统上的虚拟地址空间非常大（当前x86_64处理器上的时间为2^48个字节，并且随着新的x86_64处理器出现，设置逐渐增加到2^64）由于碎片导致的连续的虚拟地址空间实际上是不可能的（对于除了一些高度臆造的角落情况以外的所有其他地方）。 （这是由于64是“唯一”双32而引起的直觉的常见错误，这导致人们认为64位地址空间大约是32位地址空间的两倍。事实上，完整的64位地址空间是32位地址空间的40亿倍）。

换句话说，如果它把你的32位守护进程一周分段到一个阶段，它不能分配一个x字节块，比将要花至少一千年来分割今天的x86_64处理器48位地址空间，并且需要八千万年来分割未来计划的完整64-b它的地址空间。