Windows下用GetProcessMemoryInfo获取WorkingSetSize（字节）最接近RSS，需链接psapi.lib并包含psapi.h；Linux下读/proc/self/statm第二列乘页大小或/proc/self/status的VmRSS字段。
Windows 下用 GetProcessMemoryInfo 获取工作集大小
Windows 没有直接叫 “RSS” 的概念，但 PROCESS_MEMORY_COUNTERS 结构里的 WorkingSetSize 字段最接近你想要的“当前驻留在物理内存中的进程内存用量”。它包含进程当前映射到物理 RAM 的所有页（包括共享页），单位是字节。
注意：这个值不是实时刷新的，内核只在调度器或内存管理器触发时更新，所以两次调用间隔太短可能看到相同结果。
- 必须链接
psapi.lib，并在代码开头#include <psapi.h> - 需要
PROCESS_QUERY_INFORMATION权限，通常打开当前进程用GetCurrentProcess()就够了 -
WorkingSetSize是近似值，不等于实际物理页帧数（比如部分页可能被锁定但未计入） - 示例片段：
PROCESS_MEMORY_COUNTERS pmc = {};<br>if (GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc))) {<br> size_t rss_kb = pmc.WorkingSetSize / 1024;<br>}
Linux 下读取 /proc/self/statm 或 /proc/self/status
Linux 的 RSS 在 /proc/[pid]/statm 第二列（单位是页），或 /proc/[pid]/status 中的 rss: 行（单位是页）。两者都反映当前进程已分配且驻留在物理内存中的页数（不含 swap）。
/proc/self/statm 更轻量、解析快；/proc/self/status 更易读但需字符串匹配，开销略高。
立即学习“C++免费学习笔记（深入）”；
-
statm各字段顺序固定：size resident share text lib data dt，第二项就是 RSS 页数 - 记得乘以
getpagesize()得到字节数，不要硬编码 4096 —— 某些 ARM 或大页环境页大小不同 - 如果进程被 ptrace 或处于 zombie 状态，
/proc/self/可能不可读，需加错误检查 - 示例（C++）：
std::ifstream f("/proc/self/statm");<br>long size, rss;<br>f >> size >> rss;<br>size_t rss_bytes = static_cast<size_t>(rss) * getpagesize();
跨平台封装要注意的三个陷阱
没有标准 C++ API 能直接拿到 RSS，任何跨平台封装都得条件编译 + 系统调用，容易出错的点集中在权限、单位和时效性上。
- Windows 下若用
CreateToolhelp32Snapshot替代GetProcessMemoryInfo，得到的是th32.dwWSSize，单位是 KB，不是字节 —— 容易和WorkingSetSize混淆 - Linux 下误读
/proc/self/stat的第 24 字段（rss）是错误的：那是rsslim（RSS soft limit），不是当前 RSS - 某些容器环境（如 Docker）中，
/proc/self/status的RssAnon:和RssFile:分项加起来才接近真实 RSS，而总Rss:可能被 cgroup 限制截断
为什么不用 mallinfo 或 malloc_stats
这两个接口只反映堆（heap）内存的分配状态，完全不涉及栈、代码段、共享库、mmap 区域或内核为进程维护的页表等 —— 加起来可能不到真实 RSS 的一半，尤其对 Qt、Python 或 Java 嵌入场景完全失真。
-
mallinfo已被标记为废弃，glibc 2.34+ 默认不返回准确值 -
malloc_stats()输出到 stderr，无法直接提取数值，且无原子性，多线程下输出可能交错 - 它们对
mmap(MAP_ANONYMOUS)分配的大块内存（如 Eigen 或 OpenCV 的 buffer）完全不可见
实际用的时候，别指望毫秒级精度。RSS 是操作系统在页粒度上维护的统计值，两次读取差几百 KB 很正常 —— 关键是看趋势，不是单点数字。
