最接近真实物理内存占用的指标是VmRSS，单位KB，反映进程当前驻留RAM的页数，不包含swap页和未映射内存；VmSize表示虚拟地址空间总大小，含未分配页和mmap区域。
Linux下用/proc/[pid]/status查RSS和VMSize
程序运行时的内存占用不是单个数值能概括的，但最接近“分配临界值”的实用指标是RSS（常驻内存集）和VMSize（虚拟内存大小）。Linux进程的/proc/[pid]/status文件直接暴露这些字段，无需侵入式Hook或链接特殊库。
关键字段示例：
RssAnon: 123456 kB VmSize: 2097152 kB VmRSS: 123456 kB
VmRSS更贴近物理内存实际占用，VMSize包含所有映射（含未分配页、mmap区域等）。注意：它反映的是快照值，不是峰值；若需监控增长趋势，得定期轮询并记录极值。
- 用
getpid()获取当前PID，拼出路径：/proc/getpid()/status - 逐行读取，匹配以
"VmRSS:"或"Rss:"开头的行，用sscanf提取kB单位数值 - 别依赖
RssAnon——它只统计匿名页，漏掉共享库、堆外mmap等 - 该方式无额外性能开销，但频繁读取（如每毫秒）会触发内核procfs遍历，建议最小间隔≥10ms
Windows下用GetProcessMemoryInfo取WorkingSetSize
Windows没有统一的procfs，但GetProcessMemoryInfo（需psapi.h）能拿到PROCESS_MEMORY_COUNTERS::WorkingSetSize，这是最接近Linux VMRSS的指标——即当前被锁定在物理内存中的字节数。
立即学习“C++免费学习笔记（深入）”；
常见误用点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须先调用
OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId())，否则函数返回失败 -
WorkingSetSize包含共享页（如DLL代码段），不能简单等同于本进程独占内存 - 该值受系统内存压力影响剧烈：当内存紧张时，OS可能主动trim工作集，导致数值骤降，不代表程序释放了内存
- 若需跟踪堆分配总量，得配合
_CrtMemCheckpoint（仅Debug CRT）或HookHeapAlloc/malloc，但那是另一层复杂度
用mallinfo或malloc_info看glibc堆内部状态
Linux glibc提供mallinfo()（已废弃但广泛可用）和malloc_info()（推荐，输出XML）。它们反映的是malloc管理器视角下的堆使用情况，比如已分配但未归还给系统的“脏”内存、空闲块碎片等——这才是真正影响程序能否继续分配的关键临界点。
mallinfo返回结构体字段易混淆：
-
uordblks：用户请求的已分配字节数（不含malloc元数据） -
fordblks：空闲字节数（含合并后的大块） -
keepcost：最大连续空闲块大小（直接影响后续大内存分配是否失败） - 注意：
mallinfo不统计mmap分配的内存（如大对象直接走mmap），malloc_info则会标记mapped_heap节点
示例片段：
struct mallinfo mi = mallinfo();
printf("allocated: %zu KB, largest free chunk: %zu KB\n",
mi.uordblks / 1024, mi.keepcost / 1024);
为什么不能只看top或htop显示的%MEM？
%MEM是VMRSS / 总物理内存的百分比，它掩盖了两个致命问题：
- 同一台机器上多个进程共用物理内存，
%MEM高≠你的程序吃掉了所有内存，可能是其他进程缓存了文件 - 程序可能已耗尽
mmap地址空间（尤其32位进程），此时malloc失败但VMRSS和%MEM都正常——必须查/proc/[pid]/maps的地址段碎片或sbrk返回值 - 容器环境（如Docker）中
%MEM基于cgroup限制计算，和宿主机总内存无关，直接误判风险极高
真正决定“还能不能分配”的，是malloc返回nullptr那一刻的上下文：要么sbrk失败（堆满），要么mmap失败（地址空间耗尽或RLIMIT_AS触顶），要么malloc_info里keepcost太小无法满足请求尺寸。这些细节，全藏在上述接口返回的具体数值里，而不是一个百分比。
