std::bad_alloc只是内存分配失败的信号而非解决方案，无法自动恢复内存；应优先使用new(std::nothrow)主动检测，结合资源生命周期管理与峰值控制来预防。
std::bad_alloc 是什么，它真能帮你“处理”内存不足吗
不能。它只是个信号，不是解决方案。std::bad_alloc 是 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 次分配，而不是只盯着崩溃那一行。
