delete[]无法释放函数返回的二维数组内存问题求助

我来帮你拆解这个问题——其实你的代码有个小疏漏，再加上Linux内存管理的特性，才让你误以为内存没释放。

首先看代码里的直接问题：你漏了释放最外层的指针数组！

你的getsquares函数里，先用new long long int*[bruh]创建了一个存储指针的数组，再给每个指针分配一维数组。但在main函数里，你只循环释放了每个一维数组（delete[] list[i]），却没释放最外层的那个指针数组本身。这会导致这部分内存永远泄漏（虽然count=10000时，64位系统下这部分只有80KB，和0.8GB比不算大，但这是明确的泄漏点）。

修正方法很简单，在释放完所有一维数组后，加上这一行：

delete[] list;

接下来说说系统监视器显示内存没降下来的另一个核心原因：Linux的内存管理策略。

当你用delete（底层调用free）释放内存时，C++标准库（比如glibc）并不会立刻把内存还给操作系统，而是把这些内存缓存成进程内部的"空闲内存池"。下次你再调用new分配内存时，就能直接从这个池子里取，不用再向内核申请，以此提升内存分配效率。

所以你在系统监视器里看到的内存占用（比如RSS驻留集大小）不会立刻下降，但这些内存其实已经被标记为进程内部的空闲内存，进程可以复用；当系统内存紧张时，内核也会自动回收这部分内存。

怎么验证内存是否真的被释放了？ #

• 用valgrind工具检查内存泄漏：运行valgrind --leak-check=full ./your_program，如果修正后的代码没有泄漏，valgrind会明确显示"All heap blocks were freed -- no leaks are possible"。
• 用top命令观察进程内存：程序运行时，留意RES（驻留实际内存）和VIRT（虚拟内存）的变化，释放内存后VIRT通常会下降，RES可能不会立刻降低，但后续如果进程不再使用这些内存，系统会逐步回收。

修正后的完整代码 #

#include <iostream>
long long int** getsquares(long long int bruh) {
    long long int **alist = new long long int*[bruh];
    for (long long int i = 0; i < bruh; i++) {
        alist[i] = (new long long int[bruh]);
        for (long long int j = 0; j < bruh; j++) {
            alist[i][j] = (i * j);
        }
    }
    return alist;
}
int main() {
    const long long int count = 10000;
    long long int** list = getsquares(count);
    char bru;
    std::cin >> bru;
    // 释放每一行的一维数组
    for (long long int i = (count - 1); i >= 0; i--) {
        delete[] list[i];
    }
    // 释放外层的指针数组
    delete[] list;
    std::cin >> bru;
    return 0;
}

总结一下：你的代码漏了释放外层数组，这是明确的内存泄漏；另外Linux的内存缓存机制让系统监视器的内存显示不会立刻变化，用valgrind可以准确验证内存是否被正确释放。

内容的提问来源于stack exchange，提问作者StealthyPanda