VS2019中new/delete[]重载与数组内存分配的技术疑问

观测到的现象 #

在VS2019（x86/x64，编译器版本192930147）中重载new和delete运算符时，发现以下行为：

• 分配单个对象new T()与分配单元素数组new T[1]()时，内存块大小相差sizeof(size_t)；
• 数组分配的内存块首元素前会存储元素个数，但仅当类拥有析构函数时可提取该值；无析构函数的类或int等原生类型无法提取；
• 针对无析构函数的类型，重载的delete[]显示的内存块大小存在偏差，但不会引发内存泄漏；
• 上述内存大小差异仅在VS2019中出现，在线编译器无此行为，但原生类型无法提取元素个数的问题普遍存在。

疑问解答 #

1. 为何析构函数对数组分配及delete[]的大小显示至关重要？ #

C++标准未强制要求数组分配必须存储元素个数，但编译器为了正确调用数组中每个对象的析构函数，会为带析构函数的类数组额外在内存块头部存储元素计数——这样delete[]才能明确需要调用多少次析构函数。

对于无析构函数的类型（原生类型、无自定义析构的类），编译器无需逐个调用析构逻辑，因此会优化掉额外的计数存储：

• 带析构的类数组：分配内存 = 元素总大小 + sizeof(size_t)（计数占用空间），因此new T[1]()比new T()多sizeof(size_t)；
• 无析构的类型数组：直接分配元素总大小，无需额外计数，delete[]无需知晓元素个数，直接释放整块内存即可。

你重载的delete[]显示大小不正确，是因为重载逻辑可能默认按带计数的场景计算大小，但实际内存块并无额外头部，导致显示偏差。

2. 为何delete[]显示大小不正确却无内存泄漏？ #

编译器底层通过堆管理的内部元数据，清楚实际分配的内存块大小。

针对无析构的类型数组，delete[]调用时会直接从元素起始地址对应的堆元数据中获取真实分配大小，正确释放整块内存。你重载的delete[]显示的大小只是自定义逻辑的计算错误，不影响编译器的内存释放流程，因此不会产生泄漏。

3. 能否从原生类型或无析构函数的类数组中提取分配的实例数？ #

不能。因为编译器没有为这类数组存储元素个数的必要，内存中不会保留该信息。无论VS还是其他编译器，都不会为无析构的类型数组添加计数头部，自然无法从内存中提取实例数量。

是否为VS编译器的bug？ #

这不是bug，属于VS编译器的合法优化行为。

C++标准仅要求new[]与delete[]配对使用时能正确管理内存，并未规定必须为所有数组分配添加计数头部。VS2019针对无析构类型的优化符合标准，在线编译器未做该优化属于不同实现的差异，并非VS的问题。

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