C++中处理动态内存分配异常主要有两种策略：一是使用try-catch捕获std::bad_alloc异常，二是采用new (std::nothrow)返回nullptr而非抛出异常。前者符合C++异常安全和RAII原则，适合需强健错误处理的场景；后者避免异常开销，适用于禁用异常或可预期失败的环境。选择取决于程序对错误处理的设计哲学与性能需求。
在C++中，处理动态内存分配异常的核心策略主要有两种：一是利用
try-catch
std::bad_alloc
new (std::nothrow)
当我们谈论C++的动态内存分配，通常指的是使用
new
new
std::bad_alloc
我的经验是，对于大多数关键的、预期不会频繁失败的内存分配，
try-catch
std::bad_alloc
#include <iostream>
#include <vector>
#include <new> // For std::bad_alloc and std::set_new_handler
void customNewHandler() {
std::cerr << "自定义new handler被调用：内存分配失败，尝试清理或退出..." << std::endl;
// 这里可以尝试释放一些缓存，或者强制退出
// 例如：
// delete some_global_cache;
// std::exit(EXIT_FAILURE);
throw std::bad_alloc(); // 重新抛出，或者抛出其他异常
}
int main() {
// 设置自定义new handler，在bad_alloc抛出前被调用
std::set_new_handler(customNewHandler);
try {
// 尝试分配一个非常大的数组，模拟内存耗尽
// 在32位系统上，这可能更容易触发；在64位系统上，你可能需要更大的值
long long* veryLargeArray = new long long[1024LL * 1024 * 1024 * 10]; // 10GB，可能失败
// 如果分配成功，继续使用
std::cout << "内存分配成功！" << std::endl;
delete[] veryLargeArray;
} catch (const std::bad_alloc& e) {
std::cerr << "捕获到内存分配异常: " << e.what() << std::endl;
// 在这里执行错误恢复逻辑，例如：
// 1. 记录日志
// 2. 释放其他已分配资源
// 3. 告知用户并优雅退出
// 4. 如果有可能，尝试用更小的内存量重试操作
std::cerr << "程序因内存不足而终止。" << std::endl;
return 1; // 异常退出码
}
// 另一种处理方式是使用 new (std::nothrow)
// 这种方式不会抛出异常，而是在失败时返回 nullptr
std::cout << "\n尝试使用 new (std::nothrow):" << std::endl;
long long* anotherArray = new (std::nothrow) long long[1024LL * 1024 * 1024 * 10];
if (anotherArray == nullptr) {
std::cerr << "new (std::nothrow) 内存分配失败，返回 nullptr。" << std::endl;
// 同样需要在这里处理失败情况
} else {
std::cout << "new (std::nothrow) 内存分配成功！" << std::endl;
delete[] anotherArray;
}
return 0;
}代码中还展示了
std::set_new_handler
std::bad_alloc
new handler
std::bad_alloc
std::abort()
立即学习“C++免费学习笔记（深入）”；
内存分配失败，这事儿听起来好像很“高级”，但实际上它背后的原因往往很基础，也很让人头疼。我见过不少程序，在开发阶段跑得好好的，一到生产环境，处理大数据量或者长时间运行后，突然就“内存不足”了。这可不是偶然，通常有那么几个“惯犯”：
理解这些原因，能帮助我们更好地设计和调试程序。很多时候，内存分配失败不是一瞬间的事，而是长期“不健康”的内存管理习惯累积的结果。
new
“优雅”这个词，在编程里挺有意思的。对我来说，它意味着代码不仅能工作，而且在面对问题时，能以一种可预测、可维护且不那么突兀的方式处理。对于
new
std::bad_alloc
确实捕获，而不是忽略： 这是最基本的一步。用
try-catch (const std::bad_alloc& e)
try {
// 尝试分配一个对象或数组
MyClass* obj = new MyClass();
// ... 使用 obj ...
delete obj;
} catch (const std::bad_alloc& e) {
std::cerr << "内存分配失败： " << e.what() << std::endl;
// 这里是处理异常的地方
}有意义的恢复或终止策略： 捕获异常不是目的，处理异常才是。当你捕获到
std::bad_alloc
std::exit()
std::terminate()
std::unique_ptr
std::shared_ptr
// 更好的做法：使用智能指针
try {
std::unique_ptr<MyClass> obj_ptr = std::make_unique<MyClass>();
// ... 使用 obj_ptr ...
// 即使抛出异常，obj_ptr也会自动释放内存
} catch (const std::bad_alloc& e) {
std::cerr << "内存分配失败： " << e.what() << std::endl;
// 依然需要处理这个致命错误
std::exit(EXIT_FAILURE);
}考虑std::set_new_handler
std::bad_alloc
new handler
总之，优雅地处理内存分配异常，就是要有预见性，有计划，而不是等到问题发生时才手忙脚乱。它要求我们对程序的生命周期和资源管理有清晰的认识。
std::nothrow
try-catch
这两种方法，在我看来，代表了C++中两种不同的错误处理哲学。它们各有优缺点，适用场景也不同。
try-catch (std::bad_alloc)
new
std::bad_alloc
catch
std::bad_alloc
new (std::nothrow)
malloc
nullptr
new (std::nothrow)
nullptr
if (ptr == nullptr)
malloc
nullptr
何时选择？
我的个人倾向是，在大多数现代C++项目中，尤其是在需要高可靠性和异常安全性的代码中，我会优先使用默认的
new
try-catch (std::bad_alloc)
而
new (std::nothrow)
但即使使用
new (std::nothrow)
nullptr
预防总是胜于治疗。在C++中，内存管理是把双刃剑，它赋予了你强大的控制力，也带来了巨大的责任。要避免内存泄漏和过度分配，我认为有几个核心的策略和工具：
拥抱RAII（Resource Acquisition Is Initialization）： 这是C++内存管理的第一原则，也是最重要的一条。简单来说，就是将资源的生命周期绑定到对象的生命周期上。当对象被创建时获取资源，当对象被销毁时释放资源。
std::unique_ptr
std::shared_ptr
std::unique_ptr
std::shared_ptr
// 避免内存泄漏
void func() {
std::unique_ptr<int> p(new int(10)); // 自动管理内存
// ...
// 函数结束时，p会自动释放内存，即使发生异常
}std::vector
std::string
std::map
避免裸指针和手动new
delete
new
delete
new
delete
使用内存分析工具： 这就像给你的程序做体检。
审慎的内存分配策略（预防过度分配）：
std::vector
reserve
std::vector
std::list
代码审查和测试：
总的来说，预防内存问题需要一种全面的策略，从编码习惯（RAII、智能指针）到工具使用（内存分析器），再到设计哲学（按需分配）。这绝非一蹴而就，而是一个持续学习和改进的过程。
以上就是C++如何处理动态内存分配异常的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
807
收藏
