free()阻塞其他线程，导致系统变慢

Question

我正在开发一个多线程插件。当我对非常大的内存块（> 10 MB）进行free（）操作时，我的插件所在的应用程序暂时变得过慢。（这是一个音频应用程序，音频线程得到的时间太少了）。我不确定free（）是否使用了很多CPU或者它是否阻塞了其他线程太久。似乎madvice（）的调用做了很多工作。我习惯于free（）不会占用太多时间（在32位模式下运行时确实如此）。

一些信息： OSX 10.8 64位插件和程序 C++

非常欢迎任何关于如何继续的建议。

- jankoen

---

也许 free 函数执行缓慢是因为它会清除内存以进行调试。获取一个不会这样做的 free 函数版本。 - bert-jan

你能为程序添加仪器吗？在OS X上使用Instruments非常容易，它会告诉你程序花费大部分时间的具体位置。 - parry

你应该避免在任何实时优先级音频回调线程上进行内存分配或释放。请查看技术问答QA1467：CoreAudio超载警告中的建议。malloc实现需要获取锁来保证线程安全。 - Ken Thomases

Answer 1

显而易见的建议当然是停止使用free()（在C++中应该是某种形式的delete，顺便说一下）。

只要您的插件仍在加载和活动状态（或者可能是“运行”状态），就不要释放内存，当插件不再需要时释放资源。

如果您需要在释放旧缓冲区后重新分配新缓冲区，请想出一种重用已分配内存的方法。

- unwind

---

+1 这就是我在一个同步实时视频播放器中最终采用的方式。 - Nikolai Ruhe

我希望我能做到这一点，我的内存需求很大程度上取决于所选择的预设。 - jankoen

Answer 2

对于大内存分配，我现在使用vm_allocate()，它似乎不会调用冗长的madvice()。

自从我使用vm_allocate()及其对应的vm_deallocate()后，所有释放内存的调用都变得很快。

- jankoen

Answer 3

如果您重复使用内存，可能使用放置new，那么您可以完全摆脱对free/delete的调用。

- Paul Evans

Answer 4

如果缓冲区大小相同或接近，则延迟释放并使用realloc()可能会更有益。这可能会更加棘手。

- Grady Player