Linux下可通过/proc/meminfo的MemAvailable与SwapFree之和估算系统剩余可用内存，并结合getrlimit(RLIMIT_AS)检查虚拟地址空间限制，以此预判OOM风险；mallinfo等glibc内部指标不可靠。
Linux下用/proc/meminfo估算可用内存是否接近OOM临界点
C++标准库本身不暴露OOM临界值——它甚至不定义“临界值”这个概念。真正触发std::bad_alloc的，是new或malloc底层调用brk/mmap失败时内核返回的ENOMEM。所以得从系统层面反推：当前还有多少物理内存+交换空间能被分配，且未被其他进程锁死。
关键不是“程序自己用了多少”，而是“系统还能给这个进程分多少”。最直接的线索在/proc/meminfo：
MemAvailable: 123456 kB SwapFree: 789012 kB
MemAvailable是内核估算的、可立即分配给新进程的内存（已扣除page cache中可回收部分、预留页等），比MemFree更可靠；SwapFree是交换空间剩余量。两者之和是粗略的“还能撑多久”的上限。
-
MemAvailable在Linux 3.14+才稳定提供，旧系统只能用MemFree + Buffers + Cached - Shmem近似（但误差大） - 该值是全局的，不考虑当前进程的
rlimit（如ulimit -v）限制，实际可用可能更低 - 读取
/proc/meminfo本身不耗资源，但需注意文件IO失败（如容器环境/proc被挂载为只读）
用getrlimit(RLIMIT_AS)检查进程虚拟地址空间硬限制
即使物理内存充足，malloc也可能因超出RLIMIT_AS（address space limit）而失败。这是更常被忽略的OOM前置条件。
立即学习“C++免费学习笔记（深入）”；
调用getrlimit(RLIMIT_AS, &rlim)获取当前限制：
struct rlimit rlim;
if (getrlimit(RLIMIT_AS, &rlim) == 0) {
if (rlim.rlim_cur != RLIM_INFINITY) {
// 当前软限制为 rlim.rlim_cur 字节（通常等于硬限制）
// 若已接近此值，后续分配大概率失败
}
}-
rlim.rlim_cur是当前生效的软限制，rlim.rlim_max是硬限制（普通进程无法自行提升） - 默认值通常是
RLIM_INFINITY（无限制），但在容器（Docker/K8s）或ulimit -v设限后会变成具体数值 - 该限制针对虚拟地址空间总量，包括堆、mmap映射、栈等，不是仅指堆内存
为什么不能靠mallinfo或malloc_stats预测OOM
mallinfo（已废弃）和malloc_stats只反映glibc malloc管理器内部状态，比如当前brk顶、mmap区域数、已分配但未归还的字节数。它们完全不感知系统级内存压力。
- 即使
mallinfo.uordblks显示已用堆很大，只要MemAvailable充足，malloc仍可能成功（通过mmap分配） - 反之，
MemAvailable极低时，哪怕mallinfo显示空闲内存很多，malloc也会因mmap失败而抛std::bad_alloc -
malloc_stats输出是stderr文本，无法结构化解析，不适合自动化判断
实际监控建议：组合检查 + 主动降级
没有单一指标能精确给出“还剩XX字节就OOM”，但组合以下检查可显著提前预警：
- 每N次关键分配后，读
/proc/self/status里的VmRSS（实际物理内存占用）和/proc/meminfo的MemAvailable，若MemAvailable < VmRSS * 2，说明系统已吃紧 - 检查
getrlimit(RLIMIT_AS)，若rlim.rlim_cur != RLIM_INFINITY且当前VmSize已超其70%，应触发缓存清理或拒绝新任务 - 捕获
std::bad_alloc后，不要立即退出——先尝试释放非关键缓存（如LRU淘汰）、关闭后台线程，再重试一次分配
真正的难点不在读取这些值，而在确定“多早预警才合适”：太早会误判（比如MemAvailable短暂抖动），太晚则来不及降级。需要结合业务负载模式做灰度阈值调优。
