/proc/meminfo不提供系统级物理内存占用峰值，仅含瞬时值；峰值需用户态持续采样MemTotal−MemFree−Buffers−Cached−SReclaimable并维护最大值。
Linux下用/proc/meminfo解析物理内存峰值
Linux没有直接暴露“历史最高物理内存占用”的单一字段，/proc/meminfo 里 MemTotal、MemAvailable 都是瞬时值，而真正能反映“峰值”的只有内核为每个进程维护的 peak_rss（单位 KB），它记录该进程生命周期中 RSS 的最大值。系统级全局峰值需自行采样跟踪。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 定期读取
/proc/meminfo中的MemTotal和MemFree，再结合Buffers、Cached、Slab等字段估算当前已用内存（注意：不同内核版本字段含义有差异，如Cached不含 page cache 的部分） - 若目标是监控整个系统的“历史最高已用物理内存”，必须在用户态持续记录：
MemTotal - MemFree - Buffers - Cached - SReclaimable（适用于较新内核），并维护一个运行时最大值变量 - 避免依赖
MemAvailable计算峰值——它是内核估算的可分配内存，不是已用内存的反向推导值，且不具历史累积性
Windows用GetProcessMemoryInfo获取进程级RSS峰值
Windows 没有系统级物理内存占用峰值 API，但每个进程可通过 GetProcessMemoryInfo 获取其 PeakWorkingSetSize 字段，即该进程工作集大小的历史最大值（单位字节）。系统级峰值只能靠主进程（如监控服务）自身采样 + 全局聚合实现。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 调用前需
#include <psapi.h>并链接Psapi.lib；Win10 1703+ 推荐用K32GetProcessMemoryInfo替代旧版（兼容 WOW64） -
PeakWorkingSetSize是进程视角的峰值，不等于物理内存真实占用（受共享页、写时复制等影响），但对大多数监控场景足够稳定 - 若想近似系统级峰值，可在监控程序中每秒调用一次
GlobalMemoryStatusEx，提取ullTotalPhys - ullAvailPhys，再维护一个全局最大值——注意该值含内核非分页池等不可见部分，会略高于用户空间总和
C++跨平台采样封装的关键陷阱
用 C++ 写跨平台内存峰值监控时，最常踩的坑不是逻辑，而是采样时机与精度错配。比如在 Linux 下用 std::chrono::steady_clock 定时读 /proc/meminfo，若间隔小于 100ms，可能因内核统计延迟导致连续读到相同值；在 Windows 下频繁调用 GlobalMemoryStatusEx 则可能触发内核锁争用，反而拖慢目标进程。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 采样间隔设为 500ms–2s，既避开抖动又保证趋势可观测；不要用
sleep_for精确卡点，改用wait_until防止 drift 累积 - Linux 下读
/proc/meminfo必须用std::ifstream每次重新打开文件，不能复用流对象——内核不支持seekg，且文件内容每次读取都是新快照 - Windows 下
PROCESS_QUERY_INFORMATION权限不足会导致GetProcessMemoryInfo返回 false 且GetLastError()为ERROR_ACCESS_DENIED，需确保监控进程以足够权限启动（尤其服务场景）
为什么不能直接用top或free -h的输出做峰值判断
top 和 free 显示的是瞬时快照，且它们内部计算逻辑与内核统计存在偏差。例如 free -h 的 used 列 = total - free - buffers - cache，但现代内核中 cache 包含可快速回收的 page cache 和不可回收的 dentry/inode slab，而 /proc/meminfo 的 Cached 字段并不完全对应。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 监控程序绝不能解析
top -b -n1的 stdout——输出格式随终端宽度、locale、版本变化，极易崩溃 - 同理，避免用
system("free -b | awk ...")，fork+exec 开销大，且子进程退出状态不可靠 - 真正稳定的路径只有一条：直接读
/proc/meminfo（Linux）或调用GlobalMemoryStatusEx/GetProcessMemoryInfo（Windows），自己解析关键字段
实际部署时最容易被忽略的是内存统计的“归属延迟”：Linux 内核更新 /proc/meminfo 中的 MemFree 等字段，并非实时，而是按内存页回收周期批量更新；Windows 的 ullAvailPhys 同样存在几十毫秒级滞后。这意味着你看到的“峰值”，本质是采样窗口内的上界估计，而非精确到字节的历史极值。
