C/C 内存分配块

给定情况不足以确定"最佳"方法。

(1(在给定时间点，已知一组对象的总大小。因此，可以将所需的内存一次分配。

如果所有分配发生在程序的初始部分，则此事实无济于事(除非至关重要，否则速度加快了启动时间(。如果程序经常破坏并创建新对象，这也无济于事，因为内存分配器永远不会将其堆内存释放回操作系统。它只是为将来的自己的使用。

此信息有用的唯一情况是，在程序生命周期中发生的所有分配和交易对象的所有分配和交易是相同的对象类型的。在这种情况下，内存池实现将提高性能，因为找到下一个用于分配的可用插槽始终是O(1)。这是一个障碍(来源(。

如果您也知道每种对象类型的对象的总大小，则多个内存池也将非常有用。如果不是这种情况，那么您始终可以将所有对象汇总到最大对象大小，并在浪费内存的帐户上提高性能(使用内存池(。

(2(需要将内存所有权分发给每个对象，并且未定的自由度(DealLocation(的时间(DealLocation(的时间。

处理对象生命周期很难，最好的方法取决于这3个问题：

• 单个对象有多少个参考？
• 这个对象从手到手转传递了几次？
• 您的对象的图是否包含周期？

如果这些问题的答案是"一对，不多，没有太多"，那么std::shared_ptr<>可能会非常有帮助。但是，如果参考的数量不是很小，或者对象不断地从手到手转移，则参考计数可能会在每个手的转移时会引起沉重的开销。如果您的对象图中有周期，则内存泄漏将发生。在这种情况下，垃圾收集解决方案很可能具有更好的性能，并且更容易管理(请参阅Boeham的C和C 实施。

我的临时方法将是对分配的内存块的某种参考计数。每当对象自由编辑时，参考计数都会减少。当它为零时，大块被释放了。

鉴于free()并没有真正将内存回到操作系统的事实，因此我认为该方法没有任何好处。您只会拥有更多的管理开销而不会获得任何性能。您没有在问题中提到需要将背部记忆释放到操作系统的需要，所以我想这不是问题。

是否有任何更合适的模式或常见练习？

您可以实现的最重大改进是消除了在内存管理中使用构建的需求，因为它是为通用而设计的。它考虑到一切，因此相对较差。例如，管理线程之间的同步。

如果您不使用多个线程，并且内存池解决方案适用于您，请使用它们；他们可能的表现可能会最好，而且非常简单。如果内存池不适用，/或您正在使用程序中的许多线程，那么我将选择其中的许多替代内存分配器之一。我知道的一个好的多线程内存分配器是ho积。