最可靠方式是Windows用GetProcessMemoryInfo获取WorkingSetSize，Linux用/proc/self/statm第二列×页大小；勿混淆当前值与峰值，禁用GetProcessWorkingSetSize。
Windows 下用 GetProcessMemoryInfo 获取工作集大小
在 Windows 平台，C++ 获取当前进程工作集（Working Set）最可靠的方式是调用 psapi.h 中的 GetProcessMemoryInfo。它返回的 PROCESS_MEMORY_COUNTERS 结构体里，WorkingSetSize 字段就是当前工作集字节数（注意：不是页面数，是实际字节数）。
常见错误是直接用 GetCurrentProcess 返回的伪句柄传给该函数——这可行，但必须确保链接 psapi.lib，且在较新系统（如 Win10/11）上可能需启用 Psapi.lib 的“旧版”链接方式（即不勾选“使用 Windows 10 SDK 的最新 Psapi”），否则部分字段（如 PageFaultCount）可能为 0，但 WorkingSetSize 通常仍有效。
示例关键代码：
#include <windows.h>
#include <psapi.h>
#pragma comment(lib, "psapi.lib")
SIZE_T GetWorkingSetSize() {
PROCESS_MEMORY_COUNTERS pmc;
if (GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc))) {
return pmc.WorkingSetSize;
}
return 0;
}
Linux 下读取 /proc/self/statm 或 /proc/self/status
Linux 没有“工作集”的精确等价概念，但 /proc/self/statm 的第二列（即 resident 字段）表示当前驻留物理内存页数（单位是页面大小，通常是 4096 字节），可近似看作工作集的下界；而 /proc/self/status 中的 MMUPageSize 和 RssAnon 等字段更细，但 RSS（Resident Set Size）字段最常用，它对应 /proc/self/statm 第二列 × getpagesize()。
立即学习“C++免费学习笔记（深入）”；
注意点：
-
/proc/self/statm读取快、开销小，但只提供整数页数，无锁，适合高频采样 -
/proc/self/status解析稍重（需字符串匹配），但字段更全（如VmRSS:行含单位 KB），且不受 ASLR 或内核页合并影响 - 某些容器环境（如 runC）中，
RSS可能被 cgroup 限制，值会突然截断，不能简单当成“可用物理内存”
跨平台封装时别混淆 WorkingSetSize 和 PeakWorkingSetSize
Windows 的 PROCESS_MEMORY_COUNTERS 同时提供 WorkingSetSize（当前）和 PeakWorkingSetSize（历史峰值）。两者单位一致，但后者不会自动下降——它只增不减，直到进程退出。误把后者当实时值，会导致监控曲线长期持平甚至误导扩容决策。
Linux 的 RSS 是瞬时值，没有内置峰值统计；若需类似功能，得自己维护一个最大值变量，配合定时采样更新。
跨平台抽象时建议：
- 接口命名明确区分，例如
GetCurrentWorkingSetBytes()vsGetPeakWorkingSetBytes() - Linux 实现中，
GetPeakWorkingSetBytes()应由调用方自行缓存，而非从 proc 文件读取 - 避免在性能敏感路径（如游戏主循环）里反复打开/解析
/proc/self/status，优先用statm+getpagesize()
为什么 GetProcessWorkingSetSize 不推荐用
Windows 还有个 GetProcessWorkingSetSize（在 winbase.h 中），但它返回的是进程工作集的软边界（minimum/maximum 值），不是当前实际大小。这个 API 主要用于 SetProcessWorkingSetSize 配合调整，单独调用意义不大，且在低权限进程或某些沙箱环境下可能失败并返回 0。
典型误用场景：
- 以为
GetProcessWorkingSetSize(GetCurrentProcess(), &min, &max)的min就是当前工作集 —— 实际上它只是建议下限，OS 可以随时低于它（通过页面交换） - 在 UWP 或 Windows Store 应用中调用该函数会直接失败，因为工作集管理被系统接管
- 返回值不包含单位说明，容易和
GetProcessMemoryInfo的WorkingSetSize混淆
真正需要控制工作集行为时，应先用 GetProcessMemoryInfo 观察趋势，再谨慎调用 SetProcessWorkingSetSize，而不是依赖它的“查询”接口。
工作集本身是个动态、启发式概念，不同系统定义松散，同一系统下还受 NUMA 节点、内存压力、驱动锁定页等干扰。拿它做精确资源判断前，务必确认你的使用场景是否真的需要这个指标——比如内存泄漏排查适合用它，但服务扩缩容更适合看 RSS + cgroup usage + major page fault rate。
