C++内存管理基础中内存分配失败异常处理-C++-PHP中文网

C++中处理内存分配失败有两种核心策略：默认new操作符在失败时抛出std::bad_alloc异常，需用try-catch捕获；而new(std::nothrow)或malloc则返回空指针，需手动检查。选择取决于错误处理哲学和运行环境。

c++内存管理基础中内存分配失败异常处理

C++中处理内存分配失败，核心策略无非两种：对于默认的

new

登录后复制

操作符，我们期待它抛出

std::bad_alloc

登录后复制

异常；而对于

new (std::nothrow)

登录后复制

或 C 风格的

malloc

登录后复制

，则需要主动检查返回的空指针。选择哪种方式，取决于你的程序对错误处理的哲学以及所处的运行环境。

解决方案

在C++的世界里，内存分配失败是个不得不面对的现实。想象一下，你的程序正兴高采烈地运行着，突然系统告诉你“对不起，没内存了！”。这时候，我们得有预案。

首先，也是最C++惯用的方式，就是通过异常来处理。当我们直接使用

new

登录后复制

操作符来分配内存时，如果系统无法满足请求，它会抛出

std::bad_alloc

登录后复制

异常。这是标准库为我们提供的优雅错误处理机制。

#include <iostream>
#include <vector> // 只是为了模拟一个可能需要大量内存的场景

void allocate_large_memory_with_exception() {
    try {
        // 尝试分配一个非常大的内存块，例如一个巨大数组
        // 在32位系统上，或者内存不足时，这很可能失败
        std::vector<int> *big_vec_ptr = new std::vector<int>(1024 * 1024 * 1024 / sizeof(int)); // 1GB
        std::cout << "Successfully allocated a large vector (probably not 1GB in reality if it failed)." << std::endl;
        // 如果成功，做一些操作
        // ...
        delete big_vec_ptr; // 别忘了释放
    } catch (const std::bad_alloc& e) {
        std::cerr << "Memory allocation failed: " << e.what() << std::endl;
        // 在这里，我们可以选择：
        // 1. 记录日志并尝试恢复（如果可能的话，比如释放其他缓存）
        // 2. 优雅地退出程序，例如：exit(EXIT_FAILURE);
        // 3. 向上层抛出更具体的自定义异常
        std::cerr << "Attempting to gracefully exit or recover..." << std::endl;
        // 实际应用中，这里可能包含更复杂的清理逻辑
    } catch (const std::exception& e) {
        std::cerr << "An unexpected error occurred: " << e.what() << std::endl;
    }
}

登录后复制

我个人倾向于在大多数现代C++应用中使用

new

登录后复制

和

try-catch

登录后复制

。它让错误处理路径变得清晰，并且与C++的异常安全机制天然契合。当内存分配失败被视为一种“异常情况”时，这种模式非常有效。

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

然而，在某些特定场景下，比如嵌入式系统、对性能极度敏感或不希望使用异常的场合，我们可能更倾向于显式地检查空指针。C++为此提供了

new (std::nothrow)

登录后复制

语法，而C语言的

malloc

登录后复制

系列函数本身就通过返回

NULL

登录后复制

来指示失败。

#include <iostream>
#include <new> // for std::nothrow
#include <cstdlib> // for malloc, free

void allocate_memory_with_nothrow_and_malloc() {
    // 使用 new (std::nothrow)
    int* data = new (std::nothrow) int[1024 * 1024 * 1024]; // 尝试分配1GB的int数组
    if (data == nullptr) {
        std::cerr << "new (std::nothrow) failed to allocate memory." << std::endl;
        // 在这里处理失败，比如：
        // 1. 尝试使用更小的内存块
        // 2. 记录日志
        // 3. 返回错误码
    } else {
        std::cout << "new (std::nothrow) successfully allocated memory." << std::endl;
        delete[] data;
    }

    std::cout << "---" << std::endl;

    // 使用 malloc
    char* buffer = (char*)malloc(1024 * 1024 * 1024); // 尝试分配1GB
    if (buffer == nullptr) {
        std::cerr << "malloc failed to allocate memory." << std::endl;
        // 类似地处理失败
    } else {
        std::cout << "malloc successfully allocated memory." << std::endl;
        free(buffer);
    }
}

登录后复制

在我看来，

new (std::nothrow)

登录后复制

和

malloc

登录后复制

的这种显式检查方式，让程序流程更线性，没有异常栈展开的开销。但缺点是，你必须在每次分配后都进行检查，这很容易遗漏，导致空指针解引用。所以，如果你选择了这种方式，务必确保检查无处不在。

在C++中，

new

登录后复制

操作符和

new (std::nothrow)

登录后复制

在内存分配失败时行为有何不同？我该如何选择？

new

登录后复制

操作符和

new (std::nothrow)

登录后复制

在内存分配失败时的行为差异是C++内存管理中的一个核心知识点，也是我们做设计决策时需要深思熟虑的地方。简单来说，它们处理错误的方式截然不同。

默认的

new

登录后复制

操作符，也就是我们日常最常使用的那种，在无法分配所需内存时，会抛出一个

std::bad_alloc

登录后复制

类型的异常。这个行为是符合C++异常处理哲学的：内存不足被视为一种“异常情况”，它会中断正常的程序流程，并将控制权转移到最近的

try-catch

登录后复制

块。这种方式的好处在于，它强制你处理这种潜在的致命错误。如果你不捕获这个异常，程序会直接终止，这通常是可接受的，因为它避免了程序在内存不足的模糊状态下继续运行，可能导致更难以诊断的问题。对我而言，这种“要么成功要么抛异常”的语义，让代码的错误路径更加集中和明确。

而

new (std::nothrow)

登录后复制

则是

new

登录后复制

操作符的一个特殊版本，它在内存分配失败时不会抛出异常，而是返回一个空指针（

nullptr

登录后复制

）。这里的

std::nothrow

登录后复制

是一个特殊的标签，告诉编译器和运行时环境，这次分配操作是“不抛异常的”。选择这种方式，意味着你必须在每次使用

new (std::nothrow)

登录后复制

之后，显式地检查返回的指针是否为

nullptr

登录后复制

。如果忘记检查，并且尝试解引用一个空指针，那么你的程序将面临未定义行为，通常表现为段错误或崩溃。

存了个图

视频图片解析/字幕/剪辑，视频高清保存/图片源图提取

查看详情

那么，该如何选择呢？

这真的取决于你的应用场景和对错误处理的偏好：

使用默认
```
new
```
登录后复制
(抛出
std::bad_alloc
登录后复制
)：
- 推荐场景： 大多数通用应用、服务器端程序、桌面应用等。在这些环境中，内存分配失败通常被认为是程序无法继续运行的严重错误。
- 优点： 异常机制可以集中处理错误，避免了在代码中散布大量的
```
if (ptr == nullptr)
```
  登录后复制
  检查。它与C++的RAII（Resource Acquisition Is Initialization）机制配合得很好，确保即使在异常发生时，已分配的资源也能被正确释放。
- 缺点： 异常处理本身有轻微的性能开销（尽管通常不显著），并且在某些对性能和资源限制极度敏感的嵌入式系统中，可能不希望使用异常。
使用
```
new (std::nothrow)
```
登录后复制
(返回
nullptr
登录后复制
)：
- 推荐场景： 嵌入式系统、对异常处理开销敏感的实时系统、或者你希望程序在内存不足时能优雅降级而不是直接崩溃的场景。例如，一个图像处理程序可能在内存不足时选择处理更小的图像，而不是直接退出。
- 优点： 避免了异常的开销。允许程序在内存分配失败时有更精细的控制，可以尝试恢复或执行替代操作。
- 缺点： 必须手动检查每个分配的结果，这很容易遗漏，导致代码变得冗长且容易出错。如果错误处理逻辑散布在各处，维护起来会很麻烦。

在我看来，除非有非常明确的理由（比如严格的性能要求或不使用异常的编码规范），否则我通常会倾向于使用默认的

new

登录后复制

。它让代码更简洁，错误处理更统一。如果需要更细粒度的控制，我可能会考虑

new (std::nothrow)

登录后复制

，但会辅以严格的代码审查和测试，确保所有空指针检查都到位。

处理内存分配失败时，除了捕获异常或检查空指针，还有哪些高级策略可以考虑？

除了基本的

try-catch

登录后复制

或

nullptr

登录后复制

检查，C++还提供了一些更高级的机制来应对内存分配失败，它们通常用于构建更健壮、更灵活的内存管理系统。这些策略让我觉得C++在底层控制力上确实强大，但也需要我们更深入地理解其工作原理。

自定义分配器（Custom Allocators） 这是最强大也最灵活的策略之一。你可以通过重载全局的
```
operator new
```
登录后复制
和
```
operator delete
```
登录后复制
，或者为
```
std::vector
```
登录后复制
、
```
std::map
```
登录后复制
等标准容器提供自定义的
```
Allocator
```
登录后复制
类，来完全掌控内存的分配和释放过程。
- 应用场景：
  - 内存池（Memory Pool）： 预先分配一大块内存，然后从这块内存中快速分配小块内存，避免频繁的系统调用，减少内存碎片。当程序需要大量小对象时，这种方式能显著提升性能。
  - 固定大小分配器： 对于特定类型或固定大小的对象，可以实现一个专门的分配器，优化其分配速度和内存利用率。
  - 错误报告/调试： 在自定义分配器中加入额外的日志记录、内存泄漏检测或边界检查功能，有助于调试内存相关问题。
  - 特定硬件/操作系统接口： 直接与底层操作系统或硬件的内存管理API交互，实现更高效或符合特定需求的内存分配。
- 如何处理失败： 在自定义分配器内部，你可以决定当内存池耗尽或底层系统分配失败时，是抛出
```
std::bad_alloc
```
  登录后复制
  ，还是返回
```
nullptr
```
  登录后复制
  ，或者执行一些自定义的恢复逻辑。这种控制力是无与伦比的。
```
std::set_new_handler
```
登录后复制
这是一个非常有趣的机制，它允许你注册一个全局函数，当
```
new
```
登录后复制
操作符（非
```
nothrow
```
登录后复制
版本）在分配内存失败、即将抛出
```
std::bad_alloc
```
登录后复制
之前被调用。这个处理器函数可以做一些“垂死挣扎”的事情。
- 工作原理： 当
```
new
```
  登录后复制
  无法分配内存时，它会反复调用你注册的
```
new_handler
```
  登录后复制
  函数，直到
```
new_handler
```
  登录后复制
  执行以下操作之一：
  - 释放一些内存，然后返回： 期望下一次
```
new
```
    登录后复制
    尝试能成功。这通常意味着你的程序需要有一些可丢弃的缓存或资源。
  - 抛出另一个异常： 比如
```
std::bad_alloc
```
    登录后复制
    或其他自定义异常。
  - 终止程序： 例如调用
```
std::abort()
```
    登录后复制
    或
```
std::exit()
```
    登录后复制
    。
- 应用场景：
  - 内存回收： 在内存极度紧张时，你可以让
```
new_handler
```
    登录后复制
    清理一些不必要的缓存，或者将一些数据写入磁盘以释放RAM。
  - 日志记录： 在程序崩溃前记录详细的内存状态，有助于事后分析。
- 注意事项：
```
new_handler
```
  登录后复制
  必须是无参数且返回
```
void
```
  登录后复制
  的函数指针。它不能简单地返回而不做任何事情，否则
```
new
```
  登录后复制
  会陷入无限循环。这个机制是全局的，所以需要谨慎使用，确保其行为是整个程序都能接受的。
资源管理（RAII原则）和智能指针 虽然RAII（Resource Acquisition Is Initialization）和智能指针（如
```
std::unique_ptr
```
登录后复制
、
```
std::shared_ptr
```
登录后复制
）本身并不能阻止内存分配失败，但它们在“失败后”的资源管理方面起着至关重要的作用。它们确保了即使在内存分配失败导致异常或程序提前终止时，已经成功获取的资源也能被正确地释放，从而防止内存泄漏。
- 如何帮助： 如果你在一个函数中进行了多个内存分配，其中一个失败并抛出异常，那么之前成功分配的内存如果用裸指针管理，就可能泄漏。而智能指针在栈上，当异常发生导致栈展开时，智能指针的析构函数会被调用，自动释放其管理的内存。这极大地简化了错误处理逻辑，减少了手动清理的负担。
- 个人体会： 我觉得RAII是C++最强大的特性之一。它让我在编写复杂代码时，可以把精力更多地放在业务逻辑上，而不是纠结于各种错误路径下的资源清理。它让内存分配失败的后果变得可控，而不是灾难性的。

这些高级策略，在我看来，都是为了让我们在面对内存分配这个底层且关键的问题时，能够拥有更精细、更鲁棒的控制力。它们不是简单的替代品，而是对基本异常处理和空指针检查的有力补充，尤其是在构建大型、高性能或高可靠性系统时显得尤为重要。

在C++程序中，如何有效地测试和模拟内存分配失败，以确保异常处理机制的健壮性？

测试内存分配失败，听起来有点反直觉，因为我们通常希望它不要发生。但为了确保程序在真实世界中遇到内存耗尽时能够优雅地处理，而不是崩溃，我们必须主动去模拟这些场景。这就像是给程序做一次“压力测试”，看看它在极端情况下表现如何。

重载全局

operator new

登录后复制

(和
operator new[]
登录后复制
) 这是最直接也是最常用的方法。C++允许我们重载全局的

operator new

登录后复制

和

operator new[]

登录后复制

函数。通过提供我们自己的实现，我们可以控制内存分配的行为，包括在特定条件下模拟失败。

实现方式： 你可以编写一个
```
operator new
```
登录后复制
的版本，它在分配了N次之后，或者当请求分配的内存大小超过某个阈值时，抛出
```
std::bad_alloc
```
登录后复制
或返回
```
nullptr
```
登录后复制
（如果你也重载了
```
operator new(size_t, std::nothrow_t)
```
登录后复制
）。
代码示例（简化版）：

#include <new> // For std::bad_alloc
#include <cstdlib> // For malloc, free
#include <iostream>

static int allocation_count = 0;
static int fail_after_n_allocations = -1; // -1 means never fail

void* operator new(std::size_t size) {
    if (fail_after_n_allocations != -1 && allocation_count >= fail_after_n_allocations) {
        std::cerr << "Simulating memory allocation failure for size " << size << std::endl;
        allocation_count = 0; // Reset for next test run if needed
        throw std::bad_alloc();
    }
    allocation_count++;
    // 实际的内存分配
    void* ptr = malloc(size);
    if (ptr == nullptr) {
        throw std::bad_alloc(); // If malloc itself fails
    }
    return ptr;
}

void operator delete(void* ptr) noexcept {
    free(ptr);
}

// 重载 new[] 也是类似的
void* operator new[](std::size_t size) {
    return operator new(size);
}

void operator delete[](void* ptr) noexcept {
    operator delete(ptr);
}

// 在你的测试代码中：
void test_memory_failure_scenario() {
    fail_after_n_allocations = 3; // 让第3次分配失败
    try {
        int* p1 = new int; // 1st
        int* p2 = new int; // 2nd
        int* p3 = new int; // 3rd, will fail
        std::cout << "Should not reach here." << std::endl;
        delete p1; delete p2; delete p3; // If somehow succeeded
    } catch (const std::bad_alloc& e) {
        std::cout << "Caught expected std::bad_alloc: " << e.what() << std::endl;
        // 验证程序是否正确处理了异常
    }
    fail_after_n_allocations = -1; // Reset for other tests
}

登录后复制

优点： 精确控制失败的时机，可以针对特定代码路径进行测试。
缺点： 这种全局重载会影响整个程序，包括测试框架本身，需要小心管理其生命周期和状态。

使用自定义分配器进行测试 如果你的程序已经在使用自定义分配器（例如，为了性能或内存池），那么测试内存分配失败就变得非常简单。你可以在自定义分配器内部添加一个“故障注入”机制。
- 实现方式： 在你的
```
allocate
```
  登录后复制
  方法中，加入一个计数器或一个标志位，当满足特定条件时，直接返回
```
nullptr
```
  登录后复制
  或抛出
```
std::bad_alloc
```
  登录后复制
  。
- 优点： 影响