是malloc线程安全的吗？
malloc()函数是否可重入？
我读过的地方，如果你用-pthread编译，malloc变成线程安全的。 我很确定它的实现依赖，因为malloc是ANSI C和线程不是。
如果我们在说gcc：
使用-pthread和malloc（）编译并链接在x86和AMD64上将是线程安全的。
另一种看法，更有见地
glibc-2.2 +的{malloc，calloc，realloc，free，posix_memalign}是线程安全的
http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-07/0323.html
问题：“是malloc重入”？
答：不，不是。 这是一个定义什么使例程重入 。
malloc的通用版本都不允许你重新input（例如从信号处理程序）。 请注意，可重入例程可能不使用锁，几乎所有的malloc版本都使用锁（这使得它们是线程安全的）或全局/静态variables（这使得它们是线程不安全和不可重入的）。
到目前为止答案都是“malloc线程安全吗？”，这是完全不同的问题。 对于这个问题，答案取决于你的运行时库，也可能取决于你使用的编译器标志。 在任何现代的UNIX上，默认情况下你都会得到一个线程安全的malloc。 在Windows上，使用/MT ， /MTd ， /MD或/MDd标志来获得线程安全运行时库。
这里是glibc的malloc.c的摘录：
线程安全：线程安全，除非定义了NO_THREADS
假设NO_THREADS没有被默认定义，malloc在Linux上至less是线程安全的。
这是一个相当古老的问题，我想根据目前的状况带来新鲜感。
是的，目前malloc()是线程安全的。
从glibc-2.20 [released 2014-09-07]的GNU C库参考手册 glibc-2.20 [released 2014-09-07] ：
void * malloc (size_t size)初步：MT-Safe | …
… 1.2.2.1 POSIX安全概念：
…在其他线程的情况下，MT安全或线程安全的function是安全的。 在MT-Safe中，MT代表multithreading。
MT安全并不意味着函数是primefaces的，也不意味着它使用POSIX向用户公开的任何内存同步机制。 甚至有可能依次调用MT安全function不会产生MT安全组合。 例如，让一个线程调用两个MT-Safe函数，并不能保证等价于这两个函数的组合的primefaces执行的行为，因为其他线程中的并发调用可能会以破坏性方式干涉。
可以通过库接口内联函数的整个程序优化可能会暴露不安全的重新sorting，因此不推荐在GNU C库接口上执行内联。 在整体程序优化的情况下，不能保证logging的MT-安全状态。 但是，用户可见标头中定义的function被devise为内联安全。
是的，在POSIX.1-2008下， malloc是线程安全的。
2.9.1线程安全
本卷所定义的所有函数都应该是线程安全的，除了以下函数1不必是线程安全的。
[不包含
malloc的函数列表]
这取决于您正在使用的C运行时库的哪个实现。 如果你使用的是MSVC，那么就有一个编译器选项，它允许你指定你想要创build哪个版本的库（即一个运行时库，通过轮胎安全来支持multithreading）。
不，它不是线程安全的。 在C库中可能实际上有一个malloc_lock()和malloc_unlock()函数可用。 我知道这些存在于Newlib库中。 我不得不使用它来为我的处理器实现一个互斥锁，这是一个multithreading的硬件。
malloc和free是不可重入的，因为它们使用静态数据结构来logging哪些内存块是空闲的。 因此，没有分配或释放内存的库函数是可重入的。
如果你正在与GLIBC合作，答案是：是的，但是。
具体来说，是的，但请注意，虽然malloc和free是线程安全的， 但debuggingfunction却不是。
具体来说，非常有用的mtrace（），mcheck（）和mprobe（）函数不是线程安全的 。 从GNU项目中可以看到最短，最直接的答案之一，这里解释如下：
https://sourceware.org/bugzilla/show_bug.cgi?id=9939
您需要考虑替代技术，例如ElectricFence，valgrind，dmalloc等。
所以，如果你的意思是“malloc（）和free（）函数是线程安全的”，答案是肯定的。 但如果你的意思是“整个malloc / free套接字线程安全”，答案是否定的。
