VC++多线程堆争用根源在于默认堆共享全局锁，非加锁不当；应改用线程局部堆或内存池，避免伪共享与双重阻塞，禁跨线程释放内存池内存。
VC++ 多线程下堆内存争用不是“锁没加好”的问题，而是运行库默认堆（_heap）在多处理器上共享一个全局锁，所有 new/malloc 都排队——哪怕申请的是完全不相干的内存块。直接加 std::mutex 拦在 new 前面只会让性能更差。
为什么 std::mutex 包裹 new/delete 无效
加锁保护 new 调用本身看似合理，但掩盖了底层冲突点：VC++ 运行库的堆管理器（如 HeapAlloc）内部使用的是单个 critical section，且未启用 spin count。这意味着：
- 即使你用
std::lock_guard包住new int[1024]，线程仍要抢同一个全局堆锁，只是多套了一层用户态锁 - 高并发时大量线程在用户态锁和运行库堆锁之间双重阻塞，上下文切换飙升
- 无法缓解缓存行伪共享（false sharing），因为堆元数据（如空闲链表头）被多个 CPU 核频繁修改同一缓存行
换用线程局部堆：_get_heap_handle + HeapCreate
VC++ 提供了绕过默认堆的路径：每个线程用独立堆，彻底消除争用。关键不是“自己实现堆”，而是复用 Windows 原生堆 API 并绑定到线程生命周期：
- 在线程入口调用
HeapCreate(0, 1024*1024, 0)创建私有堆，保存句柄到线程局部存储（__declspec(thread)或thread_local） - 重载该线程内的
operator new，内部调用HeapAlloc(hThreadHeap, 0, size) - 线程退出前调用
HeapDestroy(hThreadHeap)，避免泄漏 - 注意：不要在主线程或 DLL 的 DllMain 中创建/销毁堆，易触发 loader lock
用内存池替代动态分配（推荐优先级最高）
对固定大小对象（如网络包、事件结构体），内存池能同时解决争用、碎片、延迟三重问题。VC++ 下最简可行方案是基于 VirtualAlloc 预留大块地址空间，再用自由链表管理：
立即学习“C++免费学习笔记（深入）”；
- 预分配 64MB 连续虚拟内存（
MEM_RESERVE），按 256 字节切块，初始化为单向空闲链表 -
allocate()仅原子读写链表头指针（InterlockedPopEntrySList更优），无锁 - 避免用
new[] char[]做底层数组——它仍走默认堆；改用VirtualAlloc(MEM_COMMIT)按需提交物理页 - 若对象需构造函数，在
allocate()返回的内存上调用 placement new，析构时显式调用
启用 VC++ 运行库的堆锁优化（仅限旧项目救急）
如果你无法修改代码结构，又必须用默认堆，可尝试启用 NT 内核已支持但 VC++ 未默认开启的 spin lock：
- 在进程启动早期（main() 第一行）调用
HeapSetInformation(GetProcessHeap(), HeapEnableTerminationOnCorruption, nullptr, 0)确保堆安全 - 紧接着调用
HeapSetInformation(GetProcessHeap(), HeapCompatibilityInformation, &heapCompatInfo, sizeof(heapCompatInfo))，其中heapCompatInfo设为2（对应HEAP_COMPATIBILITY_MODE的 spin lock 启用位） - 该设置需配合 Windows NT 4 SP3+ 或 Win2000+，且只对
HeapAlloc生效，malloc可能绕过 - 效果有限：spin lock 在高争用下仍会退化为内核等待，不如前两种方案治本
真正棘手的从来不是“怎么加锁”，而是默认堆设计本身就不适配现代多核——它把所有线程往一个窄门里赶。线程局部堆和内存池不是高级技巧，是面对 VC++ 运行库现实时不得不做的底层对齐。尤其要注意：内存池的 deallocate() 必须在同一线程调用，跨线程释放会直接破坏链表结构，这种错误在压力测试中才暴露，但崩溃时毫无征兆。
