VmHWM是Linux下/proc/self/status中记录的进程自启动以来RSS峰值（单位KB），最轻量可靠；仅Linux有效，需进程退出前读取，不等价于VmPeak或跨平台API。
Linux 下用 /proc/self/status 读取 VmHWM
Linux 内核会在进程的 /proc/self/status 文件中记录当前进程的内存使用快照，其中 VmHWM（Virtual memory High Water Mark）字段就是自启动以来达到过的峰值物理内存（RSS），单位是 KB。这是最轻量、最可靠的方式，不需要额外依赖。
注意：该值只在 Linux 上有效，且需在程序退出前读取（因为进程结束后 /proc/self/ 就不可访问了）；VmHWM 统计的是 RSS 峰值，不是虚拟地址空间大小（VmPeak）。
实操建议：
- 用
std::ifstream打开/proc/self/status，逐行读取直到匹配以VmHWM:开头的行 - 用
std::stoi提取数值后乘以 1024 得到字节数（或保留 KB 单位更直观） - 别在 fork 子进程后读 —— 子进程会重置自己的
VmHWM，父进程的值不会被继承 - 如果程序运行时间极短（毫秒级），可能因内核统计延迟而读到 0；可加微小延时或重复读两次取较大值（但非常规需求）
macOS 和 Windows 没有等价的 VmHWM
macOS 不提供进程级实时 RSS 峰值接口；task_info() 只能拿到当前 RSS（phys_footprint），无法回溯历史最大值。Windows 的 GetProcessMemoryInfo() 同样只返回当前 PeakWorkingSetSize，但该值在某些版本中存在统计偏差（尤其启用 AWE 或大页时）。
立即学习“C++免费学习笔记（深入）”；
这意味着跨平台代码里不能假设 VmHWM 存在。若必须支持多平台，要么接受“仅 Linux 可靠”，要么引入采样轮询 + 自维护峰值变量（见下一条）。
常见错误现象：
- 直接在 macOS 上 fopen
/proc/self/status—— 返回空指针，不报错但读不到数据 - 在 Windows 上调用
GetProcessMemoryInfo()后误以为它等价于VmHWM，结果发现数值跳变不规律，其实是工作集压缩/交换导致的瞬时抖动 - 用
mallinfo()或malloc_stats()替代 —— 它们只统计堆内存，漏掉 mmap 区域、共享库、线程栈等，严重低估
手动采样 + 记录峰值（便携但有开销）
当需要跨平台或对精度要求不高时，可在关键路径（如主循环、大计算块前后）调用系统 API 获取当前 RSS，并更新全局最大值。虽然不是内核级精确峰值，但能反映应用逻辑层的内存压力趋势。
使用场景：
- 调试长期运行服务的内存缓慢增长问题
- CI 中做回归测试，对比不同 commit 的内存使用拐点
- 嵌入式环境无
/proc时的降级方案
性能影响要注意：
- Linux 上每次读
/proc/self/status是轻量系统调用，但频繁读（如每毫秒）会导致 I/O 开销上升；建议间隔 ≥100ms - macOS 的
task_info()开销略高，Windows 的GetProcessMemoryInfo()相对便宜，但仍应避免在 tight loop 中调用 - 记得用
std::atomic<size_t></size_t>或加锁保护峰值变量，尤其多线程环境下
VmHWM 和 VmPeak 别混淆
VmHWM 是物理内存（RSS）峰值，VmPeak 是虚拟地址空间（VMA）峰值，二者语义完全不同。一个程序可能 VmPeak 很大（比如 mmap 了几个 GB 的文件但只访问几页），而 VmHWM 很小；反之，密集分配小对象导致大量 page fault，VmHWM 飙升但 VmPeak 变化不大。
容易踩的坑：
- 监控脚本误把
VmPeak当作内存瓶颈依据，结果优化无效 —— 真正要压的是 RSS，不是虚拟地址用量 - 容器环境（如 Docker）中
VmHWM仍有效，但受 cgroup memory limit 影响：到达限制时 OOM killer 触发前，VmHWM可能已卡在 limit 值附近，此时它反映的是配额而非真实需求 -
VmHWM不包含 swap 使用量；如果系统开启 swap 且内存紧张，RSS 可能被换出，VmHWM不会下降，但实际物理占用已减少 —— 这点常被忽略
