多维数组内存分配失败的异常处理

多维数组内存分配失败，说到底，还是动态内存不够用。处理思路和一维数组一脉相承，但关键在于维度展开后那海量的、还必须连续的内存请求。问题不在“多维”二字本身，而在于它背后隐含的内存规模和连续性要求。

先看一个最常见的陷阱：声明 int*** arr = new int**[1000];，表面上看似乎没什么。但如果每层分配都往千级规模走，比如 arr[i] = new int*[1000]; arr[i][j] = new int[1000];，总内存轻松突破数 GB，而且每一段都要求连续。编译器才不管这些，它只会老老实实去申请。多数时候，分配失败不是因为总量不够，而是堆上找不到那么大的连续内存块。

那该怎么办？三个关键动作。

拆解内存的真实需求

首先要做到心中有数。用 sizeof(int) * dim1 * dim2 * dim3 算一遍总字节数，再对比一下系统可用内存，尤其是虚拟内存的上限。别等分配出错了才手忙脚乱。其次，尽量避免用嵌套 new 来构建不规则的多维结构。更好的做法是：单块平铺，加上索引计算。比如直接用 int* flat = new int[N*M*K];，既省去了逐层分配的开销，也避免了连续性问题。如果遇到超大维度，比如图像宽高超过 8K，提前做容量校验比直接尝试分配要稳妥得多。

用 nothrow + 空指针检查，稳扎稳打

跨平台项目里，依赖 std::bad_alloc 异常并不总可靠——旧编译器可能不支持，有些环境甚至会禁用异常。更稳妥的做法是逐层使用 std::nothrow，并老老实实检查返回的指针。第一层这样写：int** mat = new (std::nothrow) int*[rows]; if (!mat) { /* 处理 */ }。进入第二层循环后，每个 mat[i] = new (std::nothrow) int[cols]; 分配完也要检查，一旦失败，立即清理已分配的 i 行之前的部分，然后退出。尤其需要注意的是，不要在构造函数中隐式做这种分配——比如自定义类成员里放了 vector 或 new，那样 nothrow 会失效，你根本拦截不到。

new_handler：最后的兜底

如果多维分配的场景很频繁，而且运行环境受限，比如嵌入式系统或长期运行的服务，可以考虑注册全局的 set_new_handler 函数。每次 new 失败前，系统会先调用这个函数，给你一个干预机会。在里面可以释放缓存、清空临时对象池，甚至触发自定义的 GC 回收。释放后若重试仍失败，再抛出 std::bad_alloc，由外层 try/catch 统一做降级处理，比如切分任务、改用文件暂存。但有一点必须提醒：handler 里绝对不能再调用 new，否则会无限递归，后果你懂的。

真正有效的方案，是避免分配失败

话说回来，真正健壮的程序，不是靠捕获异常来兜底，而是从一开始就尽量避免失败。用 std::vector> 替代裸指针的多维数组，它内部按需增长，即使失败也能保留已成功分配的数据。对于尺寸固定的超大数组，改用 std::array 或栈分配（当然，仅限小规模场景）。还可以用内存池预分配：一次性申请一大块内存，后续的多维结构从里面切分，避免多次系统调用导致碎片。更激进的做法是流式处理：不全量载入，边读边算，像矩阵分块乘法、图像分区域处理，都是实战中行之有效的思路。