windows无系统级物理内存占用峰值api，仅能通过性能计数器memoryvailable mbytes谷值间接反映；linux需轮询/proc/meminfo记录memavailable最小值；跨平台应按场景拆解定义。
Windows 上没有直接暴露“系统物理内存占用峰值”的现成 API，GetPerformanceInfo 和 GlobalMemoryStatusEx 都只返回当前值；真正能拿到历史峰值的，只有 Windows Performance Counters（性能计数器）里的 MemoryPeak Commit Charge，但它反映的是“提交峰值”，不是“物理内存（RAM）使用峰值”——这是第一个必须厘清的概念偏差。
为什么 GlobalMemoryStatusEx 拿不到峰值
这个函数返回的 MEMORYSTATUSEX 结构体里只有 ullTotalPhys、ullAvailPhys、ullUsedPhys（需自行计算）等瞬时快照字段，没有任何历史极值记录。它本质是内核 nt!MiGetPhysicalMemoryInformation 的轻量封装，不维护状态历史。
常见误用是反复轮询并自己记最大值，但这只能得到你进程运行期间的局部峰值，且受采样频率和竞争条件影响，无法替代系统级统计。
- 它不感知其他进程释放/分配的瞬时抖动，容易漏掉毫秒级尖峰
- 不同进程各自轮询，结果不可比、不可复现
- 在低优先级线程中采样，可能错过高负载窗口
真正可用的系统级物理内存峰值：用 PdhAddCounter 读 MemoryCommitted Bytes 和 MemoryAvailable MBytes
Windows 性能计数器中没有叫“物理内存使用峰值”的计数器，但可以通过组合推导出最接近的指标：MemoryCommitted Bytes 是内核承诺给所有进程的虚拟内存总量（含页面文件），其历史峰值可通过 PdhCollectQueryData + PdhGetFormattedCounterValue 获取；而物理内存实际压力更直观地体现在 MemoryAvailable MBytes 的谷值上——它的反向峰值（即最低值）对应物理内存最紧张时刻。
实操要点：
- 必须用
PdhOpenQuery创建查询，再用PdhAddCounter添加完整路径，例如\%COMPUTERNAME%\Memory\Committed Bytes - 首次调用
PdhCollectQueryData后需等待至少 1 秒再取值，否则返回PDH_INVALID_DATA -
MemoryAvailable MBytes是实时值，要捕获“历史最低”，需你自己维护一个全局最小变量并持续更新 - 计数器路径中的计算机名不能硬编码为
localhost，要用GetComputerName动态获取，否则远程监控失败
Linux 下直接读 /proc/meminfo 不行，得看 /sys/fs/cgroup/memory.max_usage_in_bytes？
错。那是 cgroup v1 的容器内存峰值，对宿主机无效。Linux 内核本身不持久化记录全系统物理内存使用峰值。唯一可靠来源是 /proc/stat 中的 procs 行（进程总数）和 /proc/meminfo 的瞬时值，但都不含历史极值。
生产环境通用做法是依赖外部监控代理（如 Prometheus + node_exporter），它会定期抓取 /proc/meminfo 并在 TSDB 中存档，再通过 max_over_time(node_memory_MemAvailable_bytes[7d]) 类查询回溯峰值。C++ 程序若需自建能力，只能：
- 用
inotify监听/proc/meminfo变化（开销大、不准） - 定时（如每 5 秒）
fopen("/proc/meminfo", "r")解析MemAvailable:和MemTotal:，算出使用率并更新本地最小MemAvailable值 - 注意：
/proc/meminfo中的MemFree不等于可用内存，必须用MemAvailable（内核 3.14+）
跨平台封装建议：别抽象“系统峰值”，按场景拆解
所谓“系统物理内存占用峰值”在不同场景下含义不同：运维关注过去 24 小时最低 MemAvailable，安全分析需要对比进程 WorkingSetSize 峰值与系统总内存比例，而性能测试只关心本进程生命周期内的物理内存波动。强行统一接口只会掩盖差异。
推荐分三路实现：
- Windows：用 PDH 查询
MemoryAvailable MBytes谷值 +Process(*)Working Set - Private做进程级归因 - Linux：轮询
/proc/meminfo记录MemAvailable最小值，同时读/proc/self/status的MMUPageSize和RssAnon辅助判断 - macOS：用
host_statistics64+HOST_VM_INFO64获取当前free_count，但无历史峰值，只能靠自己采样
真正的难点不在读数据，而在定义“什么是峰值”——是内核视角的提交峰值？是用户可见的可用内存谷值？还是某次 GC 触发前的瞬时 RSS 尖峰？没明确上下文，代码写得再全也解决不了问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
