如何通过std::bad_alloc处理内存不足异常并实现有效监控？

本文共计1149个文字，预计阅读时间需要5分钟。

plaintext不能。它只是一个信号，不是解决方案。是 new 表达式在无法分配请求的内存时抛出的异常，但它不告诉你缺少多少、哪一块没释放、能否降低级别——只说明当前 malloc 失败了。你 catch 它，不代表问题消失；不 catch，程序直接终止（默认 terminate）。

常见错误现象：terminate called after throwing an instance of 'std::bad_alloc'，但堆栈里看不到 new 调用，因为异常可能被层层上抛后才崩溃；或者 catch 住后继续运行，结果后续 operator new 又崩，陷入重复失败。

• 别指望靠 catch std::bad_alloc 自动恢复内存——C++ 不提供内存回收魔法
• 它不区分“临时性OOM”和“彻底耗尽”，也不触发 GC（C++ 没 GC）
• 在嵌入式或实时系统中，抛异常本身可能不可用（编译器禁用异常），此时 new(std::nothrow) 才是实际入口

怎么安全地检测并响应内存分配失败

核心原则：主动防御，而非被动捕获。优先用 new(std::nothrow) 替代裸 new，把异常路径转为显式判空。

使用场景：构造关键对象前、加载大资源（如图像帧、模型权重）、容器扩容（std::vector::reserve）。

立即学习“C++免费学习笔记（深入）”；

<pre class="brush:php;toolbar:false;">auto ptr = new(std::nothrow) int[1000000]; if (!ptr) { log_error("failed to allocate 1M ints"); fallback_to_disk_buffer(); // 或降级逻辑 return; } // 正常使用 ptr...

• std::nothrow 是唯一标准方式绕过异常机制，返回 <code>nullptr 而非抛 std::bad_alloc
• std::vector::reserve 可能抛 std::bad_alloc，但 push_back 不会——它内部用 new(std::nothrow) + 重试或 throw，行为取决于实现
• 自定义分配器（如池式分配器）可完全屏蔽 std::bad_alloc，但需确保其 allocate 方法不抛异常（否则违反 Allocator 要求）

全局 new-handler 能做什么，为什么多数人不该碰

std::set_new_handler 允许注册一个函数，在每次 new 失败前被调用一次。但它不是“重试钩子”，而是“最后通牒”：你必须在这函数里做三件事之一——抛异常、std::abort、或让后续 new 成功（比如释放缓存）。

容易踩的坑：new-handler 被调用时，堆很可能已处于碎片化临界状态，任何额外分配（包括 std::string 构造、日志输出）都可能再次触发 handler，导致无限递归崩溃。

• handler 函数必须是 noexcept，且不能调用任何可能分配内存的标准库函数
• 典型可用操作：调用 std::malloc（不走 operator new）、清空 LRU 缓存、std::quick_exit
• 多线程下 handler 是全局的，不同线程的 new 失败都会进同一个函数，需自己加锁或避免共享状态

真正有效的内存不足应对策略

异常监控只是表象，根因在资源生命周期管理。与其等 std::bad_alloc，不如从源头控制峰值内存。

性能影响：频繁触发 std::bad_alloc 意味着设计缺陷——比如未限制 std::vector 的最大容量、读取文件不流式处理、缓存无淘汰策略。

• 对大对象，优先用 std::unique_ptr + make_unique，避免栈溢出或中间状态泄漏
• 用 std::pmr::polymorphic_allocator 隔离高风险模块的内存域，防止一个模块吃光全部堆
• Linux 下可检查 /proc/self/status 的 VmRSS，结合 mmap(MAP_NORESERVE) 预留地址空间但延迟物理页分配

最常被忽略的一点：std::bad_alloc 往往不是突然发生的，而是某次 vector::resize 或 string::append 触发的连锁反应——查日志时要倒着看前 10 次分配，而不是只盯着崩溃那一行。