new分配的内存必须用delete/delete[]释放,malloc分配的必须用free释放,混用会导致未定义行为;new[]/delete[]必须严格配对;placement new不分配内存,不应调用delete或free,而应手动析构后按原方式释放。
用 new 分配的内存必须用 delete(或 delete[])释放,用 malloc 分配的必须用 free。混用会导致未定义行为——程序可能当场崩溃、静默损坏堆结构、或在后续某次 malloc/free 调用时才暴露问题。
根本原因在于:两者底层管理机制不同。new 不仅调用 malloc-like 内存申请,还会调用构造函数,并记录额外元数据(如数组长度、类型信息);delete 则负责析构和清理这些元数据。free 完全不知道这些,直接归还原始内存块,跳过析构,也破坏分配器内部链表。
int* p = new int(42); free(p); → 析构函数不执行(虽是 POD 类型无影响),但堆管理器可能因元数据错位而后续崩溃std::string* s = new std::string("hello"); delete s; → 正常;但若写成 free(s) → 字符串内部缓冲区未释放,std::string 对象未析构,内存泄漏 + 堆损坏char* buf = (char*)malloc(100); delete buf; → 可能触发断言(如 MSVC Debug 模式报 HEAP CORRUPTION DETECTED),或静默失败new[] 分配的是对象数组,编译器会在内存前插入隐藏字段记录元素个数,供 delete[] 正确调用每个元素的析构函数。delete(无方括号)只会调用第一个对象的析构函数,其余对象资源泄漏,且元数据读取错误会破坏堆。
即使数组元素是 int 这类无析构函数的类型,也不能用 delete 替代 delete[] —— 标准明确禁止,实际行为依赖编译器实现,不可移植。
MyClass* arr = new MyClass[10]; delete arr; → 仅 arr[0] 被析构,arr[1]~arr[9] 的资源未释放,堆元数据错乱int* a = new int[5]; delete a; → 未定义行为,Clang/GCC 在某些优化级别下可能“凑巧”不崩,但绝不应依赖 mismatched delete / delete[]
operator n(placement new)只是在已提供地址上调用构造函数,不申请新内存,因此**没有对应的 “placement delete”**,也不该对它调用 
delete 或 free。
正确做法是:手动调用析构函数,然后按原始方式释放内存(比如当初用 malloc 分配的,就用 free;用 new 分配的,就用 delete)。
void* buf = malloc(sizeof(MyClass)); MyClass* p = new(buf) MyClass(); → 后续应写 p->~MyClass(); free(buf);
delete p; 或 free(p); 都错:前者尝试释放未知地址,后者跳过析构调用 C 库(如 OpenSSL、libpng)时,常需用 malloc 分配缓冲区传入,再用 free 释放;而 C++ 代码主体用 new。此时必须划清边界,避免指针跨域传递。
典型陷阱:把 malloc 来的内存赋给智能指针(如 std::unique_ptr),却没指定自定义删除器,导致析构时调用 delete 而非 free。
std::unique_ptr ptr((char*)malloc(100)); → 错!析构时调用 delete,应写 std::unique_ptr ptr((char*)malloc(100), free);
free,而非 delete
new 分配,另一方用 free 释放,若两模块链接不同 CRT(如 MSVCRT vs UCRT),堆句柄不共享,必然崩溃最易被忽略的一点:调试器或 ASan 报的堆错误,往往不是出错行本身的问题,而是更早一次混用破坏了堆结构。查这类问题,优先检查所有 malloc/free 和 new/delete 的配对位置,而不是盯着崩溃点的代码。