C++ new和malloc混用后果 C++内存分配与释放匹配原则【规范】_网络技术

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 在某些优化级别下可能“凑巧”不崩，但绝不应依赖
检查工具（如 AddressSanitizer）会直接报告 mismatched delete / delete[]

operator new(size_t, void*)（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); 都错：前者尝试释放未知地址，后者跳过析构
placement new 返回的指针，其生命周期和内存归属完全由用户管理，编译器不介入

调用 C 库（如 OpenSSL、libpng）时，常需用 malloc 分配缓冲区传入，再用 free 释放；而 C++ 代码主体用 new。此时必须划清边界，避免指针跨域传递。

典型陷阱：把 malloc 来的内存赋给智能指针（如 std::unique_ptr），却没指定自定义删除器，导致析构时调用 delete 而非 free。

std::unique_ptr ptr((char*)mall oc(100)); → 错！析构时调用 delete，应写 std::unique_ptr ptr((char*)malloc(100), free);
C++ 类中缓存 C 风格内存时，务必在析构函数里用 free，而非 delete
跨语言 ABI 边界（如 DLL 导出函数）尤其危险：一方用 new 分配，另一方用 free 释放，若两模块链接不同 CRT（如 MSVCRT vs UCRT），堆句柄不共享，必然崩溃

最易被忽略的一点：调试器或 ASan 报的堆错误，往往不是出错行本身的问题，而是更早一次混用破坏了堆结构。查这类问题，优先检查所有 malloc/free 和 new/delete 的配对位置，而不是盯着崩溃点的代码。