C++如何获取系统当前的物理内存占用峰值 _ 进程监控接口【实战】-C++-PHP中文网

linux下vmhwm最准，单位kb；windows用process_memory_counters_ex::peakworkingsetsize，单位字节；macos无内核级支持，需用户态轮询维护。

c++如何获取系统当前的物理内存占用峰值 _ 进程监控接口【实战】

Linux 下用 `/proc/[pid]/status` 读取 `VmHWM` 是最准的

进程生命周期内物理内存占用的峰值（即 High Water Mark），在 Linux 上直接对应 /proc/[pid]/status 中的 VmHWM 字段，单位是 KB。它反映的是该进程从启动至今 RSS（Resident Set Size）达到过的最高值，由内核精确维护，无需估算或采样。

实操时注意：
- 必须读取当前进程自己的 /proc/self/status（或替换为具体 [pid]）
- VmHWM 行格式固定为 VmHWM: 123456 kB，需按空格分割并提取第二字段
- 该值只在进程退出或显式调用 mallinfo() 类接口前保持更新，运行中随时可读

#include <fstream>
#include <string>
#include <sstream><p>long get_peak_rss_kb() {
std::ifstream f("/proc/self/status");
std::string line;
while (std::getline(f, line)) {
if (line.rfind("VmHWM:", 0) == 0) {
std::istringstream iss(line.substr(6));
long kb = 0; iss >> kb; return kb;
}
}
return -1;
}</p></sstream></string></fstream>

Windows 上得用 `GetProcessMemoryInfo` + `PERFORMANCE_INFORMATION`

Windows 没有直接等价于 VmHWM 的单字段，必须组合两个 API：GetProcessMemoryInfo 返回当前 WorkingSetSize，而峰值需靠 GetPerformanceInfo 中的 CommitTotal 和 CommitLimit 间接推算——但那不是进程级的。

真正可用的进程级峰值是 PROCESS_MEMORY_COUNTERS_EX::PeakWorkingSetSize，但要注意：
- 必须使用 PROCESS_MEMORY_COUNTERS_EX 结构体，而非旧版 PROCESS_MEMORY_COUNTERS
- 调用前需开启 SE_DEBUG_NAME 权限（仅当查其他进程时必需；查自己不用）
- 返回值单位是字节，不是 KB

#include <windows.h>
#include <psapi.h><p>size_t get_peak_working_set_bytes() {
PROCESS_MEMORY_COUNTERS_EX pmc = {};
if (GetProcessMemoryInfo(GetCurrentProcess(), 
(PPROCESS_MEMORY_COUNTERS)&pmc, sizeof(pmc))) {
return pmc.PeakWorkingSetSize;
}
return 0;
}</p></psapi.h></windows.h>

macOS 没有公开稳定的进程级物理内存峰值接口

macOS 的 task_info 只提供当前 phys_footprint（近似 RSS），不记录历史峰值；host_statistics 返回的是全系统统计，无法下钻到进程粒度。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

目前可行的折中方案只有：
- 周期性轮询 task_info(TASK_PHYS Footprint) 并在用户态自行维护最大值
- 使用 libproc 的 proc_pidinfo + PROC_PIDTASKINFO，但它返回的 pti_virtual_size 和 pti_resident_size 都是瞬时值
- 第三方库如 osx-cpu-monitor 内部也是轮询+缓存，没有内核级 HWM 支持

这意味着在 macOS 上，“获取峰值”本质上是一个带时间窗口的监控行为，不是一次系统调用能解决的事。

跨平台封装时别迷信 `mallinfo` 或 `getrusage`

mallinfo 在 glibc 2.34+ 已被标记为废弃，且它只统计 malloc 系分配的堆内存，完全不包含 mmap、shared memory、code/data segment 等物理内存占用；getrusage(RUSAGE_SELF)->ru_maxrss 在 Linux 上返回的是 VmHWM 的近似值（单位是 KB），但语义模糊、精度低，且在 macOS 上单位是字节、数值还不准确。

所以：
- 不要拿 ru_maxrss 当真峰值用，尤其不能用于资源超限判定
- mallinfo 仅适合粗略观察堆增长趋势，和物理内存峰值无关
- 真正要监控物理内存上限，Linux 必走 /proc/[pid]/status，Windows 必用 PeakWorkingSetSize

不同系统对“物理内存占用峰值”的定义本身就不同，硬套一个接口名去跨平台，反而最容易出错。