多线程性能剧降主因是内存分配器争用全局锁，而非锁竞争或cpu满载；几十个线程抢同一把malloc/new锁导致严重串行化，小对象分配也需加锁、查链表、更新元数据，并引发缓存失效和tlb miss。
多线程性能剧降，八成不是锁争用或 CPU 跑满，而是内存分配器在多个线程间抢同一把全局锁——malloc 和 new 默认实现（如 glibc 的 ptmalloc2）在高并发下会严重串行化。
为什么多线程下 new 会变慢十倍？
默认堆分配器为线程安全，内部依赖一个或多个全局互斥锁。当几十个线程同时调用 new，它们实际在排队等同一个锁，而不是并行工作。
- 即使分配的是小对象（如
sizeof(int)），也要进锁、查空闲链表、更新元数据 - 不同线程分配的内存块物理地址往往离散，加剧缓存行失效（False Sharing）和 TLB miss
- 释放时同样要抢锁，且可能触发后台合并操作，进一步拖慢响应
- Valgrind + Callgrind 或 perf record -e 'syscalls:sys_enter_brk' 可直接看到大量时间卡在
brk/mmap系统调用上
用 std::pmr::memory_resource 切换线程本地池
C++17 引入的 std::pmr 是最轻量、零侵入的解法：不改业务逻辑，只替换分配器策略。
- 每个线程初始化一个
std::pmr::monotonic_buffer_resource或std::pmr::synchronized_pool_resource - 容器构造时传入对应资源指针，例如：
std::vector<int std::pmr::polymorphic_allocator>> vec{&thread_local_pool}</int> -
monotonic_buffer_resource适合短生命周期对象（如单次请求处理），分配快、释放零开销（整块归还） -
synchronized_pool_resource内置线程局部缓存，自动管理小块复用，适合长期运行的服务线程
避免隐式分配：检查 STL 容器与字符串行为
你以为没调 new，但 std::string、std::vector、std::function 在拷贝/扩容/绑定时都在默默分配堆内存。
- 对高频路径中的
std::string，优先用std::string_view接收参数；若必须存储，预设容量：str.reserve(256) - 避免在循环内构造
std::vector并反复push_back；改用栈上数组或复用已分配容器 -
std::function存储 lambda 时，若捕获对象小且无动态分配，可考虑用std::function_ref（非标准但广泛实现）避免堆分配 - 禁用
std::shared_ptr的默认分配器：用std::make_shared（一次分配控制块+对象），而非new+shared_ptr构造
别信“编译器优化能解决一切”
-O2 或 -march=native 对内存分配瓶颈几乎无效——问题出在运行时分配器争用，不是代码生成质量。
- ASan / TSan 不检测分配器争用，但
perf record -e 'syscalls:sys_enter_mmap,syscalls:sys_enter_brk'能暴露系统调用频次突增 - 用
malloc_info(0, stdout)定期打印分配器状态，观察<heap></heap>下的<allocated></allocated>与<mmaps></mmaps>是否随线程数线性增长 - 生产环境慎用 jemalloc/tcmalloc 全局替换：它们虽缓解争用，但会掩盖真实分配模式，调试困难；建议先用
std::pmr隔离问题线程
真正卡住性能的，从来不是某一行 new，而是几十个线程在毫秒级内对同一块元数据结构发起上百次原子读写——这种争用不会报错，也不会崩溃，只会让吞吐量掉到预期的 1/5，而且你用 top 看不到任何异常。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
