为何C++多线程程序完成vector写入任务后仍占用375M虚拟内存

你观测到的局部vector析构完成后仍有虚拟内存占用的现象，是glibc默认内存分配器ptmalloc的正常设计行为，不属于内存泄漏，具体原因如下：

• 首先需要明确htop中两个核心内存指标的区别：
  • VSZ：即虚拟内存大小，统计的是进程映射的全部虚拟地址空间总和，和实际占用的物理内存没有直接等价关系
  • RSS：即常驻内存大小，才是进程真正占用的物理RAM。实际测试中可以发现，所有vector析构完成后，RSS会快速回落至很低的水平，并不会长期占用大量物理内存。
• 多线程场景下的ptmalloc Arena机制是残留的核心来源：
  为了避免多线程并发申请内存时的全局锁竞争，ptmalloc会为高并发场景创建多个独立的内存分配域（Arena），每个Arena拥有独立的虚拟地址映射，互不干扰。你代码中每个线程的vector需要存储5亿个int，对应单线程约2GB的内存需求，远大于ptmalloc默认的128KB的MMAP_THRESHOLD阈值——这类大块内存申请会直接通过mmap系统调用向内核映射地址空间；当局部作用域结束、vector调用析构函数释放内存时，这块2GB的大块内存会被直接munmap系统调用回收给内核，但Arena自身的管理结构、vector动态扩容过程中产生的零碎空闲块，会作为缓存保留在Arena的空闲链表中，供后续同线程的内存申请直接复用，不会立刻把对应的虚拟地址空间归还给内核。
• 你观测到的约375M虚拟内存残留，正是5个工作线程的Arena缓存累计的结果，和ptmalloc默认的Arena大小上限、线程数量的匹配关系完全吻合。

• 该现象不构成内存泄漏：vector是局部块内的栈对象，作用域结束时必然会正确执行析构逻辑，释放所有申请的堆内存，不存在无法回收的内存资源。
• 虚拟内存残留不代表实际资源浪费：保留在Arena中的空闲虚拟页如果没有被实际读写访问，内核根本不会为其分配对应的物理内存，不会造成系统RAM的额外消耗。

• 在线程内vector析构完成后、进入sleep逻辑前，调用malloc_trim(0)，可以强制ptmalloc遍历所有Arena，将尽可能多的空闲内存归还给内核，调用后即可观测到VSZ数值快速下降。
• 启动程序时通过环境变量调整ptmalloc参数，例如设置MALLOC_TRIM_THRESHOLD_=131072（128KB），降低空闲内存的即时回收阈值。
• 替换内存分配器为jemalloc或tcmalloc，这类分配器的多线程内存回收策略更激进，长期运行下的虚拟内存残留会远小于glibc的默认实现。

内容的提问来源于stack exchange，提问作者user1688690