Linux下进程虚拟内存使用量需解析/proc/self/status的VmSize字段（单位KB），其值实时统计而非固定阈值，受ulimit -v、cgroup或OOM killer动态影响。
Linux下用/proc/self/status读取虚拟内存使用量
Linux进程的虚拟内存使用情况不靠C++标准库提供，得直接解析/proc/self/status。这个文件里VmSize字段就是当前进程的总虚拟内存（单位KB），VmPeak是历史峰值。注意：这不是“阈值”，而是实时统计值——所谓“临界阈值”在内核层面并不存在一个可查询的固定数值，它由ulimit -v、cgroup memory.limit_in_bytes或OOM killer触发逻辑动态决定。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream打开/proc/self/status，逐行匹配以VmSize:或VmPeak:开头的行 - 避免用
system("cat /proc/self/status")，开销大且不可控 - 字段值后可能带单位（如
KB），需跳过空白后提取数字部分 - 该文件在容器中同样有效，但若容器设置了
memory.limit_in_bytes，VmSize仍可超限（因为虚拟内存分配不立即分配物理页）
getrlimit(RLIMIT_AS)获取地址空间软硬限制
RLIMIT_AS是POSIX定义的进程虚拟地址空间上限（单位字节），对应ulimit -v设置。它不是“系统阈值”，而是每个进程独立的资源限制。调用失败时返回-1，errno为EPERM表示无权限读取硬限制。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须包含
<sys/resource.h>和<unistd.h> - 用
struct rlimit rl;接收结果，rl.rlim_cur是软限制（可被进程自行降低），rl.rlim_max是硬限制（需root权限提升） - 若
rl.rlim_cur == RLIM_INFINITY，说明未设限，此时VmSize增长只受物理内存+swap+内核参数vm.overcommit_memory约束 - 注意：Windows没有等价接口，
getrlimit仅Linux/macOS可用
为什么malloc成功不代表虚拟内存真够用
Linux默认启用延迟分配（overcommit），malloc只预留虚拟地址空间，直到首次写入才真正分配物理页。所以VmSize可能远大于实际物理占用，且malloc返回非NULL也不保证后续能成功访问——触发Segmentation fault或被OOM killer干掉。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 检查
/proc/sys/vm/overcommit_memory：0=启发式判断，1=总是允许，2=严格按overcommit_ratio计算 - 若需强可靠性，分配后立刻
memset(ptr, 0, size)触发缺页，再检查errno是否为ENOMEM -
mmap(MAP_ANONYMOUS | MAP_NORESERVE)会绕过overcommit检查，但MAP_NORESERVE已被标记为废弃，慎用
分析时别混淆VmSize和VmRSS
VmSize是虚拟内存总量（含未映射、共享库、mmap区域），VmRSS是常驻物理内存（Resident Set Size）。两者差值常达数倍——尤其加载大共享库或使用mmap大量文件时。VmPeak可能比当前VmSize高，说明有内存释放但虚拟地址未归还（如glibc malloc的arena未trim）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 监控应同时采集
VmSize、VmRSS、VmData（数据段）、VmStk（栈），才能定位膨胀来源 - 用
cat /proc/self/maps | awk '{sum += $3-$2} END {print sum}'验证VmSize是否与各映射区总和一致 -
mallinfo()或malloc_stats()只反映glibc堆管理器状态，不包括mmap分配、共享库等，不能替代/proc/self/status
真正关键的不是“当前阈值”，而是理解RLIMIT_AS、overcommit策略、OOM score三者如何共同作用——它们分散在不同层级，没有统一API能一键读出“临界点”。多数崩溃发生在write()或memcpy()这类访存操作时，而非malloc()调用点。
