不能。GetProcessMemoryInfo返回的是当前WorkingSetSize等瞬时值，不记录历史峰值；进程物理内存峰值需定期调用该函数采样WorkingSetSize并在用户态维护最大值变量，注意权限、单位及初始化。
Windows 上用 GetProcessMemoryInfo 拿不到物理内存峰值？
不能。这个函数返回的是当前时刻的 WorkingSetSize 或 PagefileUsage，不记录历史最大值。物理内存占用峰值（即进程生命周期内驻留内存（RSS）的最高水位）在 Windows 上没有单次调用 API 可直接获取——必须自己采样+比对。
正确路径是：定期调用 GetProcessMemoryInfo 读取 PERFORMACE_INFORMATION 中的 WorkingSetSize，并在用户态维护一个最大值变量。注意：WorkingSetSize 是当前驻留在物理内存中的字节数，接近通常说的“物理内存占用”，但不含共享页重复计算，也受系统回收策略影响，不是绝对精确，但已是用户态最贴近的指标。
- 采样间隔建议 ≥100ms，太密会增加开销且无实际意义
- 务必使用
PROCESS_QUERY_LIMITED_INFORMATION权限打开进程句柄（Win8+），旧版PROCESS_QUERY_INFORMATION在低完整性进程下可能失败 - 首次调用前要初始化峰值为 0，否则可能因结构体未清零导致误读高位垃圾值
Linux 下 /proc/[pid]/statm 和 /proc/[pid]/status 哪个更准？
/proc/[pid]/status 更可靠。它提供 VmHWM（High Water Mark）字段，单位 KB，明确表示自进程启动以来 RSS 的峰值，内核直接维护，无需用户采样。
/proc/[pid]/statm 只有当前值（第 1 列是 total pages，第 2 列是 RSS pages），没有历史峰值；而 /proc/[pid]/stat 虽含 rss 字段，但也只是瞬时值。所以真要物理内存峰值，只看 VmHWM 就够了。
立即学习“C++免费学习笔记（深入）”；
- 读取
/proc/[pid]/status需要目标进程未被ptraceattach 或处于 dumpable=0 状态，否则可能返回 0 或权限拒绝 -
VmHWM单位是 KB，不是字节，别漏换算 - 该值在进程退出后即失效，需在生命周期内主动读取，不能等 crash 后再查
C++ 跨平台封装时，为什么不能简单用 std::chrono + 循环轮询？
因为轮询本身会干扰测量结果。尤其在 Linux 上，频繁读 /proc/[pid]/status 会触发内核 procfs 节点重建和字符串格式化，带来额外 CPU 和内存开销，反过来抬高 RSS，形成正反馈偏差。Windows 上高频调用 GetProcessMemoryInfo 同样引入可观的系统调用开销。
真正实用的做法是：只在关键节点手动快照（如函数入口/出口、大内存分配后、GC 完成后），或由外部信号（如 SIGUSR1）触发读取，而非后台常驻线程持续 polling。
- 避免在性能敏感路径（如 tight loop）里嵌入监控逻辑
- 若必须周期性采集，改用
timerfd_create（Linux）或 Waitable Timer（Windows）实现异步唤醒，减少线程抢占 - 所有读取操作应加 try-catch 或 errno 检查——
/proc文件可能瞬间消失，GetProcessMemoryInfo可能返回 FALSE 且GetLastError()为ERROR_INVALID_HANDLE
为什么 GetProcessMemoryInfo 返回的 PagefileUsage 不等于物理内存峰值？
因为它是进程提交的虚拟内存总量（含已换出页），和物理内存占用无直接关系。一个进程可能 PagefileUsage 很大但 WorkingSetSize 很小（大部分页被换出），也可能两者接近（内存压力小、没换页）。混淆这两者是常见误区。
真正反映“物理内存吃紧程度”的，是 WorkingSetSize（Windows）或 VmHWM（Linux），它们都指向物理页帧的实际占用峰值。
-
PagefileUsage对排查“提交内存泄漏”有用，但和“机器卡顿”“OOM killer 触发”基本无关 - Linux 的
VmPeak是虚拟地址空间峰值，也不是物理内存，别误用 - 容器环境（如 Docker）中，
VmHWM仍有效，但需注意 cgroup memory limit 会截断其增长上限
