为什么我们有一个缓慢的'malloc`？

Question

据我所知，自定义内存管理器用于多个中型和大型项目。 security.se上的这个recent answer讨论了由于性能原因而包含OpenSSL中的自定义内存分配器这一事实，并最终导致Heartbleed漏洞更糟。这里old thread讨论了内存分配器，特别是学术论文的答案链接之一，它表明人们因性能原因而编写自定义内存分配器，因为malloc很慢，一般用途状态 - 最先进的分配器可以轻松击败它们，并且比开发人员在每个项目中重新发明轮子所引起的问题更少。

作为一个没有专业编程的人，我很好奇我们是如何结束这种状态的，以及为什么我们似乎被困在那里---假设我的观点是正确的，这不一定是真的。我想必须有一些更微妙的问题，比如线程安全。如果我错误地陈述情况，请道歉。

为什么系统malloc没有开发和优化以匹配这些“通用最先进的分配器”的性能？在我看来，它应该是操作系统和标准库编写者关注的一个非常重要的特性。例如，我听过很多关于Linux内核中调度程序实现的讨论，天真的我希望看到对内存分配器的兴趣大致相同。为什么标准malloc如此糟糕以至于很多人觉得需要推出自定义分配器？如果有更好的替代实现，为什么系统程序员不能将它们包含在Linux和Windows中，无论是默认选项还是链接时选项？

Answer 1

有两个问题：

1. 没有单一的分配方案适合所有应用需求。

2. C库设计不合理（或未设计）。一些非太监操作系统具有可配置的存储器管理器，可以允许应用程序选择分配方案。在eunuchs-land中，解决方案是将您自己的malloc / free实现链接到您的应用程序中。

没有真正标准的malloc实现（GNU LIBC可能是最接近标准的）。 OS附带的malloc实现往往适用于更多应用程序。