C++内存管理基础中new[]和delete[]使用规范-C++-PHP中文网

C++内存管理基础中new[]和delete[]使用规范

P粉602998670

发布： 2025-09-10 09:36:02

原创

326人浏览过

new[]必须与delete[]配对使用，因为new[]分配数组时会存储元素数量等元数据，delete[]据此调用每个对象的析构函数并释放全部内存；若误用delete，仅首个对象可能被析构，导致内存泄漏或程序崩溃；推荐使用std::unique_ptr<T[]>等智能指针自动管理数组内存，避免手动配对错误。

c++内存管理基础中new[]和delete[]使用规范

C++中，分配数组内存用

new[]

登录后复制

，释放数组内存就必须用

delete[]

登录后复制

。这是个铁律，没什么可商量的。如果你用

new

登录后复制

分配单个对象，那就用

delete

登录后复制

释放。简单来说，

[]

登录后复制

来，

[]

登录后复制

去；无

[]

登录后复制

来，无

[]

登录后复制

去。这不仅仅是语法上的对称，更是深层机制的必然要求，否则，等着你的就是各种内存问题。

深入一点讲，

new[]

登录后复制

和

delete[]

登录后复制

这对搭档，处理的不仅仅是原始内存的分配和回收。当涉及到类类型对象数组时，

new[]

登录后复制

会为数组中的每个对象调用其构造函数，而

delete[]

登录后复制

则负责为每个对象调用其析构函数，然后才释放整块内存。这个过程，编译器在幕后做了很多工作，比如存储数组的大小信息，以便

delete[]

登录后复制

知道要调用多少次析构函数。如果你用

new

登录后复制

去释放

new[]

登录后复制

分配的内存，那编译器就傻眼了，它只会认为你分配了一个单个对象，尝试调用一次析构函数（如果有的话），然后释放一块可能比实际数组小得多的内存，或者根本不知道如何正确处理。结果往往是内存泄漏、堆损坏，甚至程序崩溃。这就像你买了一整盒巧克力，却只打开了一个包装就想把整个盒子扔掉，或者更糟，你只知道盒子里有巧克力，却不知道有几块，结果扔掉的时候只清理了一块，剩下的烂在里面。

为什么C++中的

new[]

登录后复制

和

delete[]

登录后复制

必须成对使用？

这问题其实挺核心的，理解了它，很多内存管理的坑就能避开。简单来说，

new[]

登录后复制

在分配内存时，除了我们请求的字节数，还会悄悄地在分配的内存块头部（或者其他隐蔽的地方）存储一些元数据，其中最重要的就是数组元素的数量。这个数量信息对于

delete[]

登录后复制

来说至关重要，因为它需要知道要对多少个对象调用析构函数。你想想，如果是一个

std::string

登录后复制

的数组，每个

string

登录后复制

都有自己的动态内存需要释放，

delete[]

登录后复制

必须遍历数组中的每个

string

登录后复制

对象，逐一调用它们的析构函数，确保它们内部管理的资源都被妥善清理。如果这个过程被跳过，或者只执行了一次（因为你用了

delete

登录后复制

而不是

delete[]

登录后复制

），那么那些没有被析构的

string

登录后复制

对象内部的动态内存就永远不会被释放，这就是典型的内存泄漏。更糟糕的是，如果

delete

登录后复制

试图去释放一个被

new[]

登录后复制

分配的内存块，它可能无法正确解析

new[]

登录后复制

存储的元数据，导致释放操作本身出错，进而引发堆损坏，这可是调试的噩梦。

硅基智能

基于Web3.0的元宇宙，去中心化的互联网，高质量、沉浸式元宇宙直播平台，用数字化重新定义直播

查看详情

使用

new

登录后复制

而非

new[]

登录后复制

释放数组会发生什么？

嗯，这是一个非常常见的错误，后果也相当严重。当你用

new

登录后复制

去释放

new[]

登录后复制

分配的数组时，编译器会把它当作释放单个对象。对于基本类型（如

int

登录后复制

char

登录后复制

double

登录后复制

等）的数组，这可能看起来没那么糟糕，因为它们没有析构函数需要调用。但即便如此，行为也是未定义的。最常见的情况是，你可能只释放了数组中第一个元素所占用的内存，或者说，只是释放了分配给单个对象的那部分内存，而整个数组的剩余部分仍然处于已分配但不可访问的状态，造成内存泄漏。更致命的是，对于包含自定义类型对象（比如，我们前面提到的

std::string

登录后复制

数组）的数组，

new

登录后复制

只会尝试调用一次析构函数（如果存在的话），而不是数组中所有对象的析构函数。这意味着数组中除了第一个对象之外的所有对象的析构函数都不会被调用，它们内部持有的资源（例如

std::string

登录后复制

内部的字符缓冲区）将永远不会被释放，这绝对是内存泄漏的温床。而且，由于

new

登录后复制

和

new[]

登录后复制

在内存布局上可能存在差异，尝试用

delete

登录后复制

去释放

new[]

登录后复制

分配的内存，可能会导致运行时错误，比如内存访问越界、堆损坏，程序直接崩溃。这就像你把一叠书放在书架上，然后只抽走了最上面一本，就觉得整个书架都空了，实际上剩下的书还都在那儿，而且可能因为你错误的抽书方式，导致书架结构都出了问题。

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

如何避免

new[]

登录后复制

和

delete[]

登录后复制

使用不当带来的问题？

避免这种低级错误，最有效的方法就是少用甚至不用裸指针和手动内存管理。C++11及以后版本引入的智能指针（Smart Pointers）是解决这类问题的银弹。具体来说，对于动态分配的数组，你应该优先考虑使用

std::unique_ptr<T[]>

登录后复制

。它是一个独占所有权的智能指针，当

unique_ptr

登录后复制

超出作用域时，它会自动调用

delete[]

登录后复制

来释放内存，完美地解决了手动释放的烦恼和配对错误的问题。例如：

#include <memory>
#include <iostream>

class MyClass {
public:
    MyClass() { std::cout << "MyClass constructed\n"; }
    ~MyClass() { std::cout << "MyClass destructed\n"; }
};

void func() {
    // 使用 std::unique_ptr<MyClass[]> 自动管理数组内存
    std::unique_ptr<MyClass[]> arr = std::make_unique<MyClass[]>(3);
    // arr[0], arr[1], arr[2] 可以正常使用
    // ...
    // 当 func 结束时，arr 会自动调用 delete[] 释放内存，并调用每个 MyClass 对象的析构函数
} // arr 在这里自动析构并释放内存

int main() {
    func();
    // 输出会显示 MyClass constructed 3次，然后 MyClass destructed 3次
    return 0;
}

登录后复制

如果你需要共享数组的所有权，

std::shared_ptr<T[]>

登录后复制

也是一个选项，但通常情况下，

unique_ptr

登录后复制

更适合数组。此外，遵循RAII（Resource Acquisition Is Initialization）原则，将资源的生命周期绑定到对象的生命周期上，是C++内存管理的核心思想。这意味着，只要有可能，就让对象自己管理其内部资源。如果实在无法避免使用裸指针，那么就必须在代码审查时格外小心，确保每次