Linux下最可靠方式是解析/proc/self/status获取VmPeak（历史峰值）和VmSize（当前值），单位KB；Windows需用GetProcessMemoryInfo获取PeakPagefileUsage（单位字节），二者均非精确临界阈值，应结合setrlimit或外部监控防控OOM。
Linux下用/proc/self/status读取VmPeak和VmSize最可靠
没有跨平台的“虚拟内存分配临界阈值”API——C++标准库不暴露这类信息，Windows和Linux机制完全不同。Linux上最接近你需求的是解析/proc/self/status，它提供进程当前和历史最大虚拟内存用量（单位KB）。其中VmPeak是自启动以来峰值，VmSize是当前值，这两个数比任何用户态估算都准。
实操建议：
- 用
std::ifstream打开/proc/self/status，逐行读取并匹配以VmPeak:或VmSize:开头的行 - 注意字段后有单位（
KB），需跳过空格并提取数字部分，别直接atoi整行 - 该文件实时更新，但读取本身无锁，两次读取间可能有微小偏差，不用做并发保护
- 如果程序被
ptrace或在容器里运行，/proc/self/status仍有效，但VmPeak可能受cgroup限制影响
Windows上只能靠GetProcessMemoryInfo查PeakPagefileUsage
Windows没有等价于VmPeak的虚拟地址空间峰值指标。GetProcessMemoryInfo返回的PROCESS_MEMORY_COUNTERS结构里，PeakPagefileUsage最接近——它表示进程曾占用的最大分页文件字节数，间接反映虚拟内存压力，但不等于地址空间上限。
关键点：
立即学习“C++免费学习笔记（深入）”；
- 必须链接
psapi.lib，头文件是<psapi.h> -
PeakPagefileUsage单位是字节，不是KB，别和Linux搞混 - 这个值不包含映射但未提交的内存（比如
VirtualAlloc只保留没提交的区域），所以会偏低 - UWP或低完整性进程可能返回0或访问拒绝，需检查
GetLastError()是否为ERROR_ACCESS_DENIED
别用mallinfo或malloc_stats当虚拟内存阈值
这两个glibc接口只反映堆（heap）内部状态，和虚拟地址空间完全不是一回事。mallinfo的arena字段是brk段大小，hblkhd是mmap分配的块，加起来远小于VmSize（含栈、共享库、内存映射等）。依赖它们判断“快爆内存”会严重误判。
典型错误现象：
- 程序
VmSize已达2GB，但mallinfo.arena + mallinfo.hblkhd才200MB，误以为还有很大余量 - 大量
mmap(MAP_ANONYMOUS)分配后，mallinfo完全不体现，VmSize却猛涨 -
malloc_stats()输出到stderr，无法捕获，不适合自动化监控
所谓“临界阈值”其实是系统级软限制，应用层没法精确预知
真正决定程序何时被OOM killer干掉的，是/proc/sys/vm/overcommit_ratio、/proc/sys/vm/overcommit_memory和cgroup的memory.limit_in_bytes组合结果，不是某个固定数值。用户态代码既不能读这些全局配置，也无法预测内核下一步是否允许brk或mmap成功。
务实做法：
- 把
VmPeak（Linux）或PeakPagefileUsage（Windows）作为历史参考，而非触发阈值 - 真正要防OOM，得结合
setrlimit(RLIMIT_AS, ...)主动设虚拟内存上限，让malloc/mmap失败时明确报ENOMEM - 监控应放在外部（如systemd的
MemoryAccounting=true+journalctl），而不是让每个进程自己算“还剩多少”
越想在代码里算出那个“临界点”，越容易掉进地址空间碎片、ASLR偏移、内核overcommit策略变化这些坑里。
