Linux下用/proc/self/status读取VmHWM可获取进程自启动以来RSS物理内存峰值（单位KB），该值由内核精确维护、只增不减，需用std::ifstream逐行匹配“VmHWM:”后提取整数并乘以1024换算为字节。
Linux 下用 /proc/self/status 读取 VmHWM
Linux 内核会在进程的 /proc/self/status 文件里记录当前进程的内存使用快照，其中 VmHWM（Virtual Memory High Water Mark）字段就是自启动以来虚拟内存使用的峰值（单位：kB）。这个值在进程生命周期内只增不减，且是内核精确统计的，比用户态估算可靠得多。
实操建议：
- 用
std::ifstream打开/proc/self/status，逐行读取，匹配以VmHWM:开头的行 - 注意行尾可能有空格或制表符，
std::istringstream或std::stoi前建议先std::string::find_first_of("0123456789")定位数字起始位置 - 该文件在容器环境（如 Docker）中同样有效，但若挂载了
procfs的只读版本，需确认是否包含VmHWM（极少数精简内核可能裁剪） - 不要用
VmPeak替代 —— 它是虚拟地址空间上限（含未分配的 gap），不是实际使用峰值
macOS 和 Windows 没有直接等价接口
macOS 不提供类似 VmHWM 的单一字段。task_info() 中的 task_basic_info_data_t.resident_size 是物理内存常驻大小，而虚拟内存用量需组合 task_events_info 和 vm_region 迭代遍历所有映射区域并累加 size，但无法反映历史峰值 —— 它只返回当前值。
Windows 上 GetProcessMemoryInfo() 返回的 PROCESS_MEMORY_COUNTERS_EX.PeakPagefileUsage 接近（页文件峰值，单位字节），但它反映的是“提交内存”（committed virtual memory）峰值，和 Linux 的 VmHWM 语义最接近；而 PeakWorkingSetSize 是物理内存峰值，不等价。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
关键差异：
- macOS 无内核维护的虚拟内存历史峰值，必须自行采样 + 记录最大值
- Windows 的
PeakPagefileUsage在启用“大页面”或某些驱动行为下可能略低于真实虚拟内存峰值，因部分内存提交不经过页文件 - 跨平台封装时，别试图抽象出统一函数名 —— 行为本质不同，强行统一反而掩盖差异
采样时机影响结果准确性
VmHWM 是单调递增的，但它的更新并非实时：内核只在某些内存管理路径（如 mm_update_next_owner、do_mmap、__alloc_pages_slowpath 等）中触发更新。这意味着：
- 短时、小量的
mmap或brk可能不会立刻抬高VmHWM，尤其在内存充足时 - 频繁分配释放小块内存（如
malloc(1)循环）通常不改变VmHWM，因为 glibc 使用sbrk或mmap批量申请，再内部管理 - 想捕获某段逻辑的峰值，应在逻辑结束后立即读取，而不是在程序退出前 —— 后续其他模块可能干扰数值
- 多线程下无需额外同步：
VmHWM是进程级统计，内核保证其一致性
别把 VmHWM 当作内存泄漏判定依据
很多开发者看到 VmHWM 持续上涨就怀疑泄漏，但这是常见误判。虚拟内存峰值升高，未必代表内存没释放：
-
std::vector或std::string的容量增长后即使清空内容，底层分配的虚拟地址空间仍保留（capacity()不降），VmHWM就不会回落 - glibc 的
malloc在高负载下会保留fastbins和unsorted bin中的大块内存供复用，这些仍是已提交的虚拟内存 - 动态库加载、JIT 编译、线程栈预留都会一次性拉高
VmHWM，但属于合法行为 - 真正要定位泄漏，应结合
heap profiler（如valgrind --tool=massif或google-perftools）看实际堆分配趋势
最易被忽略的一点：VmHWM 统计的是虚拟地址空间用量，它不区分“已提交”和“仅保留”，也不反映物理内存压力。拿它去调优或设告警阈值前，务必先确认你真正关心的是什么。
