C++中内存分配失败怎么处理 set_new_handler异常处理机制-C++-PHP中文网

set_new_handler在c++++内存管理中如此重要，是因为它提供了一种全局性、前置性的内存分配失败处理机制。1. 它作为“最后机会”处理器，在new操作符抛出std::bad_alloc之前被调用；2. 允许程序尝试释放资源、降级服务或终止程序，以应对内存危机；3. 相比局部的try-catch，它实现了集中化、主动式的错误干预策略；4. 支持统一的内存危机管理，适用于大型复杂系统。这种机制让开发者能在内存不足时进行全局自救，而不是被动等待异常发生。

C++中内存分配失败怎么处理 set_new_handler异常处理机制

在C++中处理内存分配失败，尤其是当

new

登录后复制

操作符无法获取所需内存时，它默认会抛出

std::bad_alloc

登录后复制

异常。然而，在异常被抛出之前，C++标准库提供了一个非常重要的机制来让我们介入：

set_new_handler

登录后复制

。这个函数允许我们注册一个“新内存分配失败处理器”，它会在

new

登录后复制

操作符即将抛出

std::bad_alloc

登录后复制

之前被调用，为我们提供最后一次挽救或优雅退出的机会。

解决方案

利用

std::set_new_handler

登录后复制

来注册一个自定义的函数。当

new

登录后复制

操作符无法分配内存时，它会反复调用这个注册的函数，直到该函数成功释放了足够的内存让

new

登录后复制

操作继续，或者该函数选择抛出异常（通常是

std::bad_alloc

登录后复制

自身），或者终止程序（例如调用

abort()

登录后复制

或

exit()

登录后复制

）。

一个典型的

new_handler

登录后复制

函数签名是

void (*)(void)

登录后复制

，即一个不接受任何参数、不返回任何值的函数指针。你可以在这个函数里尝试清理一些缓存、释放非关键资源，或者记录日志，然后决定是让

new

登录后复制

重试，还是直接终止程序。

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

#include <iostream>
#include <new>      // For std::set_new_handler, std::bad_alloc
#include <vector>   // For a large allocation example
#include <cstdlib>  // For abort()

// 自定义的内存分配失败处理器
void my_new_handler() {
    std::cerr << "错误：内存分配失败！尝试释放一些资源..." << std::endl;
    // 在这里可以尝试释放一些缓存、清理不必要的内存。
    // 比如，如果是游戏，可以卸载一些不常用的纹理或模型。
    // 如果是服务器，可以清理一些不活跃的会话数据。

    // 简单示例：直接终止程序，因为我们没有可释放的资源
    // 实际应用中，你可能需要更复杂的逻辑来判断是否能继续。
    std::cerr << "无法恢复，程序即将终止。" << std::endl;
    abort(); // 终止程序
    // 或者，如果你想让原始的new操作继续抛出std::bad_alloc，可以这样做：
    // throw std::bad_alloc();
}

int main() {
    // 设置自定义的new handler
    std::set_new_handler(my_new_handler);

    try {
        std::cout << "尝试分配一个巨大的内存块..." << std::endl;
        // 尝试分配一个非常大的内存块，这很可能会失败
        // 注意：这里的内存大小需要根据你的系统实际情况调整，以确保它能失败
        // 例如，一个32位系统可能无法分配4GB，而64位系统可能需要更大
        std::vector<char>* huge_data = new std::vector<char>(1024ULL * 1024 * 1024 * 4); // 尝试分配4GB
        std::cout << "内存分配成功！(这不太可能发生，除非你的系统内存超大)" << std::endl;
        delete huge_data;
    } catch (const std::bad_alloc& e) {
        // 如果new handler选择抛出bad_alloc，那么这里会捕获到
        std::cerr << "在main函数中捕获到std::bad_alloc异常: " << e.what() << std::endl;
    } catch (const std::exception& e) {
        std::cerr << "捕获到其他异常: " << e.what() << std::endl;
    }

    return 0;
}

登录后复制

为什么

set_new_handler

登录后复制

在C++内存管理中如此重要？

在我看来，

set_new_handler

登录后复制

提供了一种“预警”和“最后机会”的机制，这与简单地在

try-catch

登录后复制

块中捕获

std::bad_alloc

登录后复制

有着本质的区别。想象一下，你的程序正在运行，突然需要一大块内存，而系统已经捉襟见肘。如果只是简单地等待

new

登录后复制

抛出异常，那么你可能已经错过了最佳的自救时机。

set_new_handler

登录后复制

的价值在于它的全局性和前置性。它是一个全局的钩子，在任何

new

登录后复制

操作失败之前都会被调用。这意味着你可以在一个中心化的位置处理所有内存分配失败的场景，而不是在每个可能失败的

new

登录后复制

调用点都写一个

try-catch

登录后复制

。这对于大型、复杂的系统尤其重要，因为你不可能为每一个

new

登录后复制

都添加异常处理。它允许你实现一种全局的内存危机管理策略，比如在内存不足时，自动清理一些不常用的缓存数据，或者降级某些服务以释放资源。这种设计哲学，其实挺有意思的，它把“失败”看作是一个可以被提前干预的“状态”，而不是一个已经发生的“事件”。它给了你一个喘息的机会，而不是直接把你推向深渊。

set_new_handler

登录后复制

与

try-catch std::bad_alloc

登录后复制

有何不同，何时选择使用？

这确实是一个常常让人疑惑的问题。表面上看，它们都是处理内存分配失败，但实际用途和设计理念却大相径庭。

try-catch std::bad_alloc

登录后复制

是一种局部、反应式的错误处理机制。它意味着你期望在某个特定的代码块中，

new

登录后复制

操作可能会失败，并且你已经准备好在失败后执行一些恢复逻辑（比如释放已分配的部分资源，或者向用户显示错误信息）。它适用于你能够明确预见到某个

new

登录后复制

操作可能风险较高，并希望在该局部范围内进行精细控制的场景。比如，一个图片编辑器在加载一个超大图片时，如果内存不足，可以捕获异常并提示用户“内存不足，请关闭其他程序”。

而

set_new_handler

登录后复制

则是一种全局、主动式的预警和干预机制。它不关心是哪个具体的

new

登录后复制

操作失败了，它只关心“系统内存不足”这个普遍性问题。它的作用是在

std::bad_alloc

登录后复制

被抛出之前，给程序一个“回光返照”的机会。你可以在这里尝试进行一些全局性的资源回收，例如：

清理全局缓存： 释放所有不再活跃的用户会话数据。
卸载不常用模块： 动态加载的插件或库，如果当前不活跃，可以尝试卸载。
切换到低资源模式： 例如，一个实时渲染程序可以降低渲染质量以减少内存占用。

选择哪种方式，取决于你的设计意图：

钉钉 AI 助理

钉钉AI助理汇集了钉钉AI产品能力，帮助企业迈入智能新时代。

查看详情

如果你想在某个特定操作失败时进行局部恢复，并且该操作的失败是可预期的、可处理的，那么
try-catch std::bad_alloc
登录后复制
是首选。
如果你想在系统级别对内存不足进行统一管理，尝试在程序崩溃前进行全局性的资源释放，或者在无法恢复时优雅地终止程序，那么
set_new_handler
登录后复制
是你的利器。

很多时候，它们甚至可以结合使用。

set_new_handler

登录后复制

作为第一道防线，尝试进行全局自救。如果自救失败，它会选择抛出

std::bad_alloc

登录后复制

（或者直接终止），这时，外层的

try-catch

登录后复制

就能捕获到这个异常，进行更具体的错误报告或局部恢复。

实现

new_handler

登录后复制

时需要注意哪些潜在问题和最佳实践？

实现一个健壮的

new_handler

登录后复制

并非易事，这里有一些我个人在实践中总结出的注意事项：

避免死循环： 这是最关键的一点。当
```
new
```
登录后复制
调用
```
new_handler
```
登录后复制
时，如果
```
new_handler
```
登录后复制
不采取任何措施（不释放内存、不抛异常、不终止程序），那么
```
new
```
登录后复制
会再次尝试分配内存，再次失败，然后再次调用
```
new_handler
```
登录后复制
，如此往复，形成一个无限循环。你的
```
new_handler
```
登录后复制
必须在以下三种方式中选择一种：
- 成功释放了足够的内存，让
```
new
```
  登录后复制
  操作得以继续。
- 抛出
  std::bad_alloc
  登录后复制
  或其派生类异常，让
```
new
```
  登录后复制
  操作正常失败，由上层
```
try-catch
```
  登录后复制
  处理。
- 终止程序，例如调用
```
abort()
```
  登录后复制
  或
```
exit()
```
  登录后复制
  。
异常安全：
```
new_handler
```
登录后复制
本身不应该抛出除
```
std::bad_alloc
```
登录后复制
之外的任何异常。如果它抛出其他类型的异常，行为是未定义的，这通常意味着程序会崩溃。这意味着你在
```
new_handler
```
登录后复制
内部执行的任何操作都必须是异常安全的，或者你必须确保它们不会抛出异常。
可重入性与线程安全： 如果你的程序是多线程的，并且多个线程可能同时进行
```
new
```
登录后复制
操作，那么你的
```
new_handler
```
登录后复制
需要是线程安全的。它可能会被多个线程同时调用。这意味着你不能在
```
new_handler
```
登录后复制
中使用非线程安全的数据结构，或者需要适当的锁机制。然而，在内存极端不足的情况下，使用锁可能会导致死锁，所以设计时要格外小心。通常，一个简单的
```
abort()
```
登录后复制
或
```
throw std::bad_alloc()
```
登录后复制
是更安全的选择。
避免进一步的内存分配： 在
```
new_handler
```
登录后复制
内部，你绝对不应该尝试进行新的内存分配，因为你正处于内存不足的危机中。任何试图分配内存的操作都可能导致递归调用
```
new_handler
```
登录后复制
，最终栈溢出或再次陷入死循环。如果你需要日志记录，请确保日志系统不会在内部进行内存分配（例如，使用预分配的缓冲区或直接写入文件）。
有限的功能：
```
new_handler
```
登录后复制
应该尽可能地简单和快速。它不是一个可以执行复杂业务逻辑的地方。它的核心任务就是尝试释放资源或决定程序的命运。
恢复策略： 你的恢复策略应该基于你程序的特性。例如，一个Web服务器可能会关闭一些不活跃的连接来释放内存；一个图像处理软件可能会清理掉一些缓存的中间结果。关键在于识别那些可以被安全释放，且释放后能显著减少内存压力的资源。